What one workflow proves

The foundation build is priced in two parts. A small amount begins the work, and the larger share — €7,500 of a €10,000 build — falls due at one specific moment: when a single workflow runs end to end in your environment. Not when the product is finished. Not when a feature count is hit, or a date arrives. When one path works all the way through.

That trigger is deliberate, and it looks backwards. Most of the money rides on what sounds like the smallest possible deliverable — one workflow, when a product is dozens. The reason it isn't backwards is the whole subject here: one real path is the strongest available proof that the foundation exists, and a finished-looking demo is one of the weakest.

Five screens that work prove less than one that connects

The intuitive measure of progress is coverage — more screens working means more product built. It's the wrong measure, because it counts the wrong thing. A demo can show five screens that each work perfectly on their own and still hide the only fact that matters: whether they connect. A sign-in page that works in isolation, a billing page that works in isolation, an admin that works in isolation — that's five green screens and zero evidence that an account created on the first becomes a charge on the second and a readable row on the third. The wiring between them doesn't show up in a screenshot, and the wiring between them is exactly where real products fail.

One workflow is the opposite trade. It is narrow — a single path — but it crosses every box, so it proves the connections the separate screens conceal. The accepted cost is that building one path properly takes longer than stubbing five screens; that's not a tax on the approach, it's the point of it. Five stubs prove nothing joins up. One real flow proves the foundation is real.

What the one path actually exercises

Take the path that already runs behind both Smallbox products: a visitor signs in by emailed link. Follow it and count what it touches. The website takes the request. The backend drives the sequence. Identity issues the account. The email module templates the link, queues it, and sends it. The click lands back and becomes a session. The admin shows the operator who signed in and what they've done since. And every step leaves a record in one log. A single path, and it has already put weight on identity, email, the backend's composition seam, the admin, the deployment, and the logger.

That is the proof, and it arrives as receipts rather than claims: the account is real, the email is real, the operator can see it, a failure anywhere in the chain would land as a findable record, and the whole thing is deployed where you can click it yourself. Five receipts from one path. A product with fifty screens and none of those receipts is further from done than a product with one screen and all five — because the fifty screens haven't yet been asked the question the one path answers.

What it deliberately does not prove

The honesty about the limit is what makes the claim worth anything, so here it is plainly. One workflow does not prove the product is finished — it is one path of many you'll build. It does not prove the idea sells; that is the market's verdict, and no amount of foundation buys it. The prototype already answered the will-anyone-want-this question, and that is the only question a prototype answers. One workflow doesn't even prove the second workflow is free.

What it proves is narrower and load-bearing: the base is real, operated, and connected — and the next workflow is now a pattern to follow rather than an argument to have again. The first path is expensive precisely because it settles every connection question once. The second is cheap because those questions are already answered: it reuses the seam, the queue, the admin, and the log, and only its own steps are new. The speed is real but conditional, and worth stating with its condition attached — a new workflow goes fast because the connective layer already exists, not because the work was ever trivial.

Why prove it on a path, not a page

The connective layer is the thing under examination, and it's the part a demo structurally cannot show: typed contracts between the surfaces and the seam, one place where rules live, email through a queue with a history, failures that become records instead of vanishing. It is also the exact part a first hire cannot rebuild in a quarter while also shipping your product. A workflow is the cheapest honest test of that layer, because a workflow is the only thing that has to use all of it at once.

It's the same property that decides whether a stranger can operate the system at all — whether someone who didn't build it can read what happened to a customer from a screen rather than from the database. A finished-looking demo and an operable system diverge exactly where the screenshots stop: at the connections. One workflow is the test that reaches them.

The verdict

Building one workflow properly takes longer than stubbing five, and that cost is the entire reason it proves anything — the long way is the only way that crosses every connection. So the money waits for the one path for the same reason the build leads with it: a single real workflow is the moment the foundation stops being a diagram and becomes your running system, checkable by you, before the rest is built on top of it.

That milestone — payment trigger and all — is spelled out on the page for the foundation package built around exactly this path. The first workflow is small on purpose. It's small because it only has to be true.