A written specification for a recycling marketplace had to become a genuine live transaction: a supplier offering material, a price agreed, the material moving and the money following it. The commercial team already ran its supplier relationships in its own system, and that system had to stay the record for the relationship. The danger in a transactional first release is spending months on listings, filters and grades, then discovering at launch that the one path which actually earns money does not clear.
A transactional product is proven by the first trade that settles, and by nothing short of it.
A transactional product has one path that matters more than everything else: the one where money changes hands. In recycling, that path starts with a supplier describing material they have, usually by grade, which is the trade's shorthand for what the material is and how clean it is. A price is agreed. The material is collected or delivered, checked on arrival against what was described, and paid for. Several of those steps involve people and places outside the software, a truck, a weighbridge, a bank. Until the whole path has run once with real material and real money, every part of it is a guess about how the others behave.
Engineers have a name for the first thin version of a complete path: a walking skeleton, sometimes called a steel thread. Every layer is present, from the screen to the database to the payment, but each does the minimum. Its value is that it fails early and in a small place. A problem found while one supplier and one trade are moving through a narrow system is cheap to fix. The same problem found after months of breadth is found everywhere at once.
Most trading businesses already run their relationships in a customer-relationship system: who the suppliers are, what was discussed, which deals are open. A new platform starts producing facts that belong there. The usual way to send them is a webhook, a message one system sends another when something happens. Webhooks are normally delivered at least once, which means that if the sender is not sure a message arrived, it sends it again. A receiver that does not recognise a message it has already handled turns every retry into a second record.
The deliverable was the shortest reliable path from specification to one real settled trade, with the relationship system kept informed so the commercial team was never blind to what the platform had done. The marketplace the specification described was real and would come. It was deferred on purpose, and the deferral was written down, which is a different thing from being overlooked.
Marketplace builds fail by running out of time before anything clears.
A specification for a marketplace describes the finished thing: listings, search, every grade, negotiation, ratings, the awkward cases. Built breadth-first, it produces a convincing demo early and a real transaction late. The first trade then becomes the first test of every join in the system at once, and the problems it surfaces, a payment detail missing, a field the commercial team needed, a hand-off nobody owned, arrive together, in a large codebase, under launch pressure.
The second pattern is the side system. The platform starts transacting while the commercial team keeps working in the tool they already know. Nobody told it about the new supplier who signed up on the platform or the deal that just closed there. Before long there are two lists of suppliers, two views of the pipeline, and a reconciliation exercise nobody planned for.
The reflex, and the fix.
Build the marketplace surface first
It is what the specification describes, and it demonstrates the product to everyone who asks.
It puts months between the start and the first real transaction, which is the only event that proves any of it works.
Drive one real transaction end to end
A narrow product that visibly does less than the specification, for longer than is comfortable.
A proven path to a settled trade, commercial visibility from the very first one, and breadth added onto something already known to work.
Clear one real transaction before building breadth, because until one clears, every part of the product is an assumption.
One supplier-to-trade path, built to stay
The minimum route from a supplier's action to a settled transaction, built to production standard. This is the path that every later feature hangs off, so it was never treated as a prototype to be thrown away.
The relationship system connected from day one
Platform activity reaches the system the commercial team already works in through webhook integration. A new supplier or a new deal appears where they look, from the first trade onwards.
Synchronisation that tolerates repeats
The integration expects messages to be redelivered and retried, and recognises one it has already handled. A duplicated contact or a duplicated deal is a commercial problem: two people chasing the same supplier, or a pipeline that overstates itself.
Deferred breadth, named as deferred
The grades and edge cases outside the launch path are listed by name. The gap between the first release and the specification is something the client can read, and nothing they have to discover.
What each choice cost, and what it bought.
ABuilding the narrow path to production standard
A first release is often built as a throwaway, on the reasoning that it will be replaced once the real product is designed. Here the narrow path was the real product, the route every later feature would use. Building it properly cost time that could have gone into visible breadth. It meant that when breadth arrived it attached to something already proven by a settled trade, and nothing had to be rewritten to get there.
BConnecting the relationship system before launch
Integration with the commercial team's own system could have waited until the platform was busy. Doing it first meant integration work before there was anything to integrate. It bought a commercial team that saw the first supplier and the first trade in the place they already looked, and it removed the reconciliation between two pictures of the business that a later integration would have needed.
CDesigning for repeated messages from the start
Duplicates in an integration usually appear only once traffic grows, so they are easy to postpone. Handling redelivery from the first message cost some design on a path that, at launch, carried very little. It meant the relationship system never accumulated duplicates that someone would later have to find and merge by hand, which is the expensive version of the same fix.
DWriting the deferred list down
Every narrow release leaves things out. The choice is whether the client learns what was left out from a document or from a supplier. Naming the deferred grades and edge cases was uncomfortable, because it is a visible list of what the product cannot yet do. It turned an apparent gap into a plan, and made the next phase of work a matter of picking from the list.
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
No measured figures are published for this engagement. Outcomes are described qualitatively.
A broad marketplace surface with every grade and edge case modelled, months before anything has settled, and a commercial team working from a separate picture of the same suppliers.
A narrow path proven by a real settled transaction, with repeat-safe synchronisation into the relationship system so the commercial team sees what the platform did, and the deferred breadth named in writing.
What it owns, and what it hands to a person.
A single-path first release proves the path. It does not prove the full catalogue of grades and commercial edge cases, which were deliberately deferred and not solved. That difference was stated plainly, so the client knew which supplier conversations the platform could carry and which still needed a person.
For any transactional product, make one real transaction clear before building breadth, and keep the commercial system of record in sync from the first one. Reconciling two pictures of the same customers later costs more than integrating early.
In a transactional product, the first settled transaction is the first real test of the whole system. Get to it before building breadth.
A walking skeleton, every layer present and each doing the minimum, finds integration problems while they are small and cheap.
If a business already runs its relationships in one system, a new platform should feed that system from day one, not compete with it.
Webhooks are delivered at least once, so the receiving side must recognise a message it has already handled or every retry becomes a duplicate record.
When a release deliberately leaves things out, write the list down. Deferred and overlooked look identical until someone asks.