Case study · Cross-border payments
Compete on what the incumbents won't show.
International Orders sells cross-border payments: local acquiring, payment methods, currency conversion and landed cost. Its category leaders publish no prices and put a contact form behind every button. We built a marketing site that does the opposite: it shows the fee, maps the coverage and lets a developer try the API before talking to anyone.
- Client
- International Orders · international-orders.com
- Industry
- Cross-border payments & commerce infrastructure
- Context
- A payments platform preparing its public launch. Front-end marketing site, version one: product, solution, coverage, pricing, developer and company pages, built on mock data ahead of the client's own copy.
The brief
The brief started from a teardown of an incumbent's site. Match its structure, then compete on transparency and interactivity, at a size that would normally take a content team months to keep consistent.
- Parity with the leaders
- A product catalog in five pillars, solution pages by industry, size and goal, a filterable customer library, gated reports and a locale switcher.
- Openings to win on
- Published pricing, a fee and landed-cost calculator, a coverage explorer, a self-serve sandbox path and a developer playground. The incumbent offered none of these.
- One set of numbers
- The incumbent quoted different coverage counts on different pages. Every figure here had to come from one source, so no two pages could disagree.
The starting point
- Site
- A domain and a build brief. No existing site, codebase or content to migrate.
- Data
- No backend yet. The brief called for mock data throughout, structured so real figures could replace it in one place.
- Brand
- A direction rather than a system: route lines and customs stamps, to be turned into tokens, components and motion.
The approach
Build the site as data plus templates. Products, solutions, markets, payment methods and figures each live in one typed source. Pages render from it, and tests fail when a page and its data disagree.
From brief to launch
01
Foundation
The site shell, design tokens, navigation, theming and locale routing, with right-to-left layout for Arabic and no Accept-Language redirects.
02
Templates
One product template drives the whole catalog and one solution template drives every industry, size and goal page. Each page ships only its own interactive demo.
03
Interactive tools
A fee calculator and a landed-cost calculator built on a fee engine that works in integer minor units. A coverage explorer with a hex map and a 3D globe that loads only on capable devices. An API playground and a site-wide command palette.
04
Content and launch
Blog, guides, glossary, events, newsroom, careers and legal pages from MDX collections. Then the domain, DNS, a GitHub repository with protected main, and deploys on merge.
AI in the delivery process
- Eight phases, each closed by checks
- Claude Code built the site phase by phase from the brief. Each phase ended with type checks, unit and browser tests and a production build, then a report before the next one started.
- Parallel authors on separate files
- Data and content for the later phases were written by parallel agents on files that did not overlap, then merged through a locked script so no agent overwrote another's work.
- Automated audits found what review missed
- A layout sweep across every page and width found 266 overflow problems that came down to three root causes. The fixes took the count to zero, and the sweep now runs on every pull request.
The build foundation
- NEXT.JS + REACT
- Application framework, statically generated with long revalidation windows
- TYPESCRIPT
- Typed data sources for products, markets, methods and figures
- TAILWIND
- Design tokens and theming, light and dark
- NEXT-INTL
- Nine locale routes, including right-to-left Arabic
- MDX
- Blog, guides, docs preview, newsroom and legal collections
- REACT THREE FIBER
- The coverage globe, loaded only when the device can carry it
- PLAYWRIGHT + VITEST
- Browser, accessibility, layout and unit tests
- GITHUB ACTIONS + VERCEL
- Required checks on pull requests; production deploys on merge
The live experience
The site is live at international-orders.com. Every page is prerendered and served from Vercel's edge cache, with no backend behind it yet. It still runs on the brief's mock data: the customers, people, figures and announcements are placeholders until International Orders supplies its own, and a launch checklist in the repository tracks each one.
The partner banner
An animated banner for payment-gateway partners to introduce International Orders to their merchants: a euro checkout settling in US dollars, in one eight-second loop. It is shown here as delivered and is not yet placed on a partner site. The figures in it are an example order, not a quote or a rate.
What shipped
A complete version-one marketing site, ready for real copy. These figures are properties of the build, counted from the repository at commit 029d5b8 on 10 October 2026. They are not business results.
- Site
- 256 pages in each of nine locale routes: 2,304 prerendered URLs, all returning 200 in production.
- Data
- 25 product pages, 40 markets and 44 payment methods, each drawn from one typed source that real figures can replace in place.
- Brand
- Route lines and customs stamps turned into design tokens, components and motion, in light and dark themes and right-to-left Arabic.
- Quality
- Lighthouse scores of 98 to 100 on sampled templates, axe accessibility checks in the browser suite, and a 250 KB limit on first-load JavaScript enforced in CI.
- Guardrails
- Lint, types, formatting, unit tests, a build, the script budget, browser tests and a six-width layout sweep must pass before anything reaches main.
Build with DBAI
Need a site that holds up to scrutiny?
Bring us the brief. We'll build it with the checks that keep it right after launch.
Book a Discovery Call