Clear One Real Transaction Before You Build The Second Feature

Mostafa Dhouib·10 min read

Clear One Real Transaction Before You Build The Second Feature

The short answer. When the product is a transaction, the first milestone that tells you anything is one real transaction settling end to end with real money and real counterparties. Everything built before that rests on assumptions, and the assumptions that break are never the ones in the interface. They are in payment, settlement, identity and what the other side actually does when money is involved. So pick the narrowest path that reaches a cleared transaction, build that path properly, prototype everything beside it, and write down what you deferred rather than letting it look finished.

A marketplace is going to connect sellers of recovered material with buyers, handle the money, and take a cut.

The natural plan is to build the marketplace. Listings, search, buyer accounts, seller accounts, messaging, ratings, dashboards. Then, once the product looks like a marketplace, wire up payments and go live.

That plan fails in a specific way. On the day payments get wired up, four months of decisions turn out to have assumed things about settlement, fees, identity and dispute handling that are not true, and the corrections reach back into almost everything already built.

The first transaction is the only real test

Before one transaction has cleared, what you know about your product is what people told you and what you inferred. After one has cleared, you know some things.

You know whether the payment path works for your actual counterparties, which is different from whether the integration works. A business seller who needs to be paid into a company account, who has to be verified before funds can be released, and who will not sign up without an invoice they can give their accountant, is a different problem from a test card succeeding.

You know how long money takes to arrive, which determines whether you can release goods on payment or must wait for settlement. That single fact can change your whole state model, and it is not knowable from documentation alone, because it depends on the method, the parties and the volumes.

You know what the counterparty does when the money is real. People behave differently. They ask questions they never asked in a demo. They want to change the amount after agreeing. They pay a different figure from the one invoiced. Those behaviours are requirements, and they only appear when the transaction is real.

And you know your own operation can do it. Someone has to reconcile the payment, answer the query, issue the credit note. A platform that transacts but has no operational path to support a transaction has not shipped.

None of that comes from breadth. It comes from depth on one path.

Choosing the narrow path by following the money

The narrow path is not the smallest feature. It is the thinnest complete line from intent to settled money, and you find it by starting at the money and walking backwards.

Pick one transaction type, with one method, in one direction. One material, one unit of measure, one currency, one payment method, one direction of funds. Every variant you add multiplies the state space before you have validated any of it. Variants are cheap to add after the path clears and expensive to carry before.

Pick the counterparties you already have. The first transaction should be between two parties who are known, reachable and willing. Acquisition is a separate problem and mixing it in means a failure tells you nothing, because you cannot distinguish "the mechanism does not work" from "nobody came".

Prefer the path with the fewest parties who can say no. A transaction that needs a verification step, a credit decision and a logistics booking has three places to stall. Choose the route with the fewest external gates for the first clearing, even if it is not the route you expect to be the main one later.

Keep the handover points visible. Where the platform hands off to a human, make that explicit and instrumented. On the first transaction you want to see every place a person intervened, because that list is your real backlog.

Insist that it is genuinely end to end. A transaction that reaches payment and then has settlement done by hand off platform has not cleared, it has been simulated. The value of the exercise is entirely in the parts nobody wants to look at.

Build the spine properly, prototype the rest

The common objection to a narrow path is that it produces throwaway work. It does not, if you are deliberate about which parts are permanent.

Two different standards apply, and the line between them is whether a mistake there can be corrected later without data loss.

Build properly: the record of what happened. Transitions recorded as append-only entries, each with its own identity, so the history of a transaction can be reconstructed. This is the one thing you cannot retrofit. A system that overwrote its own history has lost information that no later rewrite recovers. Entries written badly in month one are entries you can never reconstruct in month six.

Build properly: idempotency on anything that moves money or creates an obligation. Keys checked before the transition is applied. Retries and replays happen immediately, not later, and a duplicated payment on transaction number three is a commercial problem, not a bug report.

Build properly: the money arithmetic. Fixed-point values, explicit rounding, no binary floating point anywhere near an amount. Wrong figures are hard to find and harder to unwind once counterparties have acted on them.

Build properly: object level authorisation. Every read and write scoped to the party that owns the record, enforced at the data layer. Retrofitting this across a surface that was built without it is a rewrite of every handler.

Prototype freely: screens, search, notifications, dashboards, reporting. These are views. They can be crude, hard-coded, or a spreadsheet export, and replacing them later costs only the time to build the real version. If settlement and reporting are derived from the entry log rather than holding their own state, a throwaway report costs nothing to throw away.

Prototype freely: anything a person can do manually at low volume. Onboarding by email, verification by eye, invoicing by hand. At one transaction a day, a human is a perfectly good implementation, and watching them do it tells you what to automate.

The test for which side a thing falls on is one question: if we get this wrong, can we fix it later without losing information or unwinding obligations. If yes, prototype it. If no, build it properly now, even in the first week.

Name the deferred scope

The failure that undoes all of this is not technical. It is that a narrow build looks like a finished product to anyone who was not in the room.

Someone sees a transaction clear and reasonably concludes the platform transacts. They do not know that it handles one material, one currency and one payment method, that disputes are handled by email, and that nothing stops a seller listing material they have already sold.

So the deferred scope has to be written down as a list, with the same seriousness as the delivered scope. Not a vague note about future phases. A specific register: the variant that is not supported, the check that is not implemented, the case that currently requires a person, and what each one depends on.

Two properties make the list useful. Each item says what happens today in its absence, because "disputes not yet supported" is less honest than "a disputed amount is resolved by email and recorded by hand, so it does not appear in reporting". And each item says what triggers building it, usually a volume or a counterparty type, so the register becomes the roadmap rather than a disclaimer.

This list is also the thing that protects the narrow decision. Breadth creeps back in because nobody can see what was left out, so every omission looks like an oversight to be fixed now. A register turns omissions into choices with owners.

The honest limit

One cleared transaction tells you the path works once. It tells you very little about volume. Concurrency, contention on the same listing, settlement at scale and reconciliation across hundreds of payments are different problems, and they will produce their own surprises later.

The approach also assumes a cooperative first counterparty, which is a real constraint. If your market will not transact without the surface that makes it look credible, a two-sided listing experience may genuinely be prerequisite rather than deferrable, and no amount of discipline changes that. The judgement call is whether credibility is actually blocking the first transaction or whether that is an assumption nobody has tested by asking.

And narrow is not the same as sloppy. The failure I see most is a team that uses the narrow path as licence to skip the spine, clears a transaction with overwritten state and no idempotency, and then builds breadth on top of it. That is the worst of both approaches, because it carries the cost of the rebuild and the risk of the shortcut at the same time.

FAQ

Why is one settled transaction worth more than a broad feature set? Because everything built before the first transaction rests on untested assumptions, and the assumptions that break are in payment, settlement, identity and counterparty behaviour rather than in the interface. One cleared transaction tells you how long money takes, what verification the parties need, and what your own operation has to do. Breadth first means months of work resting on guesses.

How do I choose which path to build first? Start at the money and walk backwards. One material, one currency, one payment method, one direction of funds, between two counterparties who are already known and willing. Prefer the route with the fewest external parties who can block it. Acquisition should not be mixed in, because then a failure cannot tell you whether the mechanism or the demand was missing.

What has to be built properly even in a narrow first build? The append-only record of transitions, idempotency on anything that moves money or creates an obligation, fixed-point money arithmetic with explicit rounding, and object level authorisation enforced at the data layer. The test is whether a mistake can be corrected later without losing information or unwinding obligations. If it cannot, it is not a prototype.

What can safely be a prototype? Anything that is a view or that a person can do by hand at low volume. Screens, search, notifications, dashboards and reporting are derived and cheap to replace. Onboarding by email, verification by eye and manual invoicing are fine at one transaction a day, and watching a person do them is how you learn what to automate first.

Does payment working in a sandbox count as clearing a transaction? No. A sandbox proves the integration, not the path. It does not tell you whether a business seller can be verified and paid into a company account, how long funds actually take to settle, what the counterparty asks when the money is real, or whether anyone internally can reconcile it. Simulated settlement removes exactly the part worth testing.

Why write down the deferred scope instead of just planning the next phase? Because a narrow build looks finished to anyone who was not in the room, so omissions get read as oversights and breadth creeps back in. A register that states what happens today in each gap, and what triggers building it, turns omissions into owned decisions. It also doubles as the roadmap, ordered by what volume or counterparty type forces each item.