Example
Work / Marketplace
Rebuilt around its sellers.
Listing, search and payouts shared one codebase, and a seller's edit waited for the nightly job to notice it.
An illustrative example. No client is named here until we have their written consent.
Case facts
- Client
- An independent marketplace operator
- Sector
- Marketplace
- Team shape
- Two engineers, one designer part-time
- Engagement
- One continuous build, weekly demo
Case study
Challenge
The marketplace had grown the way most of them do: one application that listed items, searched them, took the money and paid it out again. Every one of those jobs had its own release risk, and they all shared the same deploy.
Sellers felt it first. A price change, a new photo or a closed listing went into a queue and appeared in the storefront after the nightly job ran. Support spent its mornings explaining a delay nobody could see a reason for.
Approach
We did not start with a rewrite. We started by drawing the seams that were already there — the places where the code changed subject — and agreeing which of them deserved a contract. Listing, search and payouts came out as three services with typed interfaces between them and the storefront reading from an index it could rebuild on demand.
- A written contract per service before any code moved.
- One seam split at a time, each behind a flag, each demoable.
- The old path kept running until the new one had matched it in production.
Outcome
A seller's change is now written once and read straight from the storefront, so the nightly job no longer decides when a shop looks correct. Search can be reindexed without touching payments, and payments can be released without waiting for search.
The narrative on this page is illustrative. When we publish a real case study it carries the client's own account of the outcome, with their consent, and any figure in it is theirs.
Storefront
One catalogue, read the same way by both sides.
Placeholder frame — storefront listing view.
The problem
Everything waited for the same job.
Listings, search documents and payout records were written by the same application in the same transaction, so a change to any one of them meant a release of all three.
The nightly reindex was the only thing that made the storefront agree with the database. Until it ran, a seller and a buyer were looking at two different shops.
- Seller edits queued until the nightly reindex.
- A payments fix could not ship without a search release.
- Support carried the delay as an unexplained complaint.
The approach
Three services, three contracts.
We split along the seams the domain already had rather than the ones an architecture diagram would like. Listing owns what a seller writes, search owns how it is found, payouts own what is settled — and each publishes a typed contract the others hold it to.
Nothing was cut over in one step. Each seam ran old and new side by side behind a flag until the new path had matched the old one on real traffic, and only then did the old one come out.
- A typed contract per service, written before the split.
- Old and new paths side by side until the new one matched.
- A storefront index that can be rebuilt without a release.
In their words
Sellers see their own changes straight away, so our support inbox lost an entire category of complaint.
An illustrative quote. Real testimonials are published only with the client's consent.
Details
Three surfaces a seller actually uses.
Seller onboarding. Search and filters. Payout statement.
This case study is an illustrative example. The client, the quote and every image on this page are placeholders — we name no real client, and publish no client figure or outcome metric, until we have their written consent.