An AI-built returns portal, from spec to live orders

The situation

Localised is a merchant of record for international e-commerce brands. Most returns portals on the market couldn't handle all the local currencies, local payment methods and languages its markets needed, so returns from European shoppers were handled by hand or through tools that didn't fit. The answer was one in-house portal every client brand could use, each with its own branding, return rules, markets and languages.

There was a second reason. Localised already handled the outbound shipping, so handling the return as well meant it could help clients claim returned goods relief on the duty they'd paid.

The first brand was Callaway Golf Pre-Owned's European store. The spec had three non-negotiables: the portal speaks the shopper's language and currency, it produces a carrier label without anyone touching it, and every return is tied to the order system by one RMA reference.

The customer return portal's first step, fully in German — Fully localised, down to the field hints. This is the same screen in German.

What I did

I wrote the spec, built it myself with AI coding tools — a rapid prototype in Lovable, then Claude Code for the production build — and owned the testing. Localised's developers reviewed the code and pushed it to production on AWS.

01SpecI wrote the whole Product Requirements Spec: journey, rules, fees, DHL, OMS, refunds and admin.
02BuildI built it with Claude Code against my spec, piece by piece. Localised's developers reviewed every change before it went to production.
03Test hardA formal QA and gap analysis against the spec, re-tested after every deploy.
04ShipLive on AWS and taking real customer returns, with DHL labels and OMS sync.

Steps 2 and 3 went round many times. Most of the value came from the testing.

QA across every deploy. I kept a formal QA findings and gap analysis against the spec as a living log for Localised's developers: 30 findings graded Critical to Low. At the last re-test, 14 were fixed and verified, 3 partly fixed and 5 open, each blocker named and owned.
What the spec missed. A second review of what a production returns platform needs: 26 capabilities, each tagged launch-critical, fast-follow or roadmap. The headline gap was customer-service tooling, because CS agents are the daily users.
Who can do what. I designed the roles and permissions: least privilege, server-side tenant isolation so one brand can never see another's data, support agents who can process returns but not issue refunds, and every state-changing action audited.
A return is not a refund. I defined how returns, refunds, cancellations and goodwill gestures flow one way from the OMS to Shopify. A return records the reason and moves no money; a refund moves money.

The customer journey

Customer return portal, step one: email and order number fields — Start with just an email and order number.

Item selection with a golf-specific list of return reasons open — Return reasons written for golf, not borrowed from fashion.

Shipping step with DHL selected and a print-at-home label option — Carrier and label method in one step.

Address step pre-filled from the order — Address pre-filled from the order, so labels go to the right place.

Review step showing the refund total and a return fee paid separately by card — Paid returns handled up front, so the refund stays whole.

From the QA log

The DHL label blocker

Label creation failed with a carrier API error. Through QA I traced it: the label service was sending DHL a placeholder address instead of the shopper's. The fix was a new address step in the customer flow. Labels now come back first time with real tracking, re-issuing doesn't create a duplicate return, and the printer-less QR drop-off works too.

The bug that only showed up in storage

Shoppers saw the right currency on screen, but the saved refund record held the wrong one: the display was localised, the stored data wasn't. I caught it by checking the admin record, not just the customer screen. It's now stored per market.

Rules that protect money live in the backend

"Max returns per order" only worked in the interface, so re-entering an order let a second return through. I raised it as a server-side eligibility and idempotency requirement.

What it does

For shoppers

Country picker sets the language and currency
Order lookup checked live against the OMS
Eligibility badges and brand-specific return reasons
DHL label printed at home, or a QR code for printer-less drop-off
Return fees paid online where a brand charges them

For the team

One admin for every brand, behind single sign-on
Returns list with filters, tracking and CSV export
Re-print label, resend email, cancel, or create a return for a customer
OMS sync status, a full timeline and a platform audit log
Brand set-up without code: branding, countries, rules, reasons, email copy, customs

Admin view of a single return showing customer, status, tracking, label actions, OMS sync and items — Everything CS needs on one screen, including proof the return reached the OMS.

Return rules set per country across 29 country tabs: window, fees, thresholds and options — Return policy set per country, not one-size-fits-all.

What changed

Livetaking real customer returns
29 · 14countries and languages for the first brand
0labels made by hand: DHL labels are automatic

Every order is checked live against the OMS, and every return syncs back into it.
Returns come back through the same route as the outbound shipment, so clients can claim returned goods relief.
CS has the tools it was missing: create return, re-print label, resend email, a timeline and an audit log.
Localised can set up a new brand in the admin, without code.
It proved a pattern for internal tools: the ops person who knows the process writes the spec and owns the testing, and AI speeds up the build — with proper engineering review before anything goes live.

What I'd do next

From the roadmap I wrote:

Drive return status from DHL tracking events, so refunds can start at first scan.
Feed structured return reasons into weekly product and ops reporting.
Add exchanges and store credit.

More screens

Ten languages for the shopper, one portal.
A clear choice of how the shopper is paid back.
One admin, many brands. Each client is configured, not coded.
The CS view: every return, its tracking and its refund at a glance.
Paid returns and a full event timeline, so nobody needs a developer to answer “what happened?”
CS can raise a return for a customer who phones or emails.
Every action logged: who, what, when.
Onboarding a brand is a form, not a project.
Brand-specific return reasons and eligibility rules.
Brands edit their own email copy in every language, with a live preview.
Cross-border returns get a DHL commercial invoice automatically.

All customer, order, tracking and payment details in these screenshots are dummy data.