Part 1 of a 3-part series, "The Economics of a One-Person Platform Company."
I have built a cloud ERP for multiple sprints and shipped zero ERP features. No inventory, no accounting, no sales pipeline. A cloud ERP with no ERP in it, just the layer nobody asks to see: who is allowed to do what, in which company, with which data. That refusal is the strategy, not a delay, and holding the line on it was the hardest founder call I have made.
I wrote the constraint down as a decision record before the temptation could win. The rule is plain: no domain modules until the platform is mature and could stand alone as a multi-tenant product. The gate has ten criteria, and it stays closed until every one is validated.
Is building the platform before the product just procrastination?
No. On a system like an ERP, the foundation is the product. Ship visible modules before the platform has settled and each one bakes in a guess the platform will later overturn: a rewrite priced per module, across every module. Pouring the authorization and tenant layer first is what keeps the modules cheap when they finally arrive.
The feature you can demo is not the feature that wins
Most founders building business software ship a visible feature in week one, something you can put in a deck. I did the opposite, on purpose, and held the line for multiple sprints. The instinct to ship the thing you can show is exactly the instinct that mortgages the foundation.
Why authorization has to come first
An ERP only looks like one app. In practice it is an accountant who serves dozens of separate businesses, a branch manager scoped to one location, a freelancer invoicing three clients from one login, an auditor with read-only reach across an org. Every one of those is an authorization question.
If you build the invoice feature before you have answered those questions properly, the invoice feature assumes an answer. So does the next feature, and the next. Each one hard-codes a guess about who can see what.
Then the platform changes, because early platforms always change, and every feature built on the guess becomes a rewrite candidate. The debt does not add up. It multiplies.
The lesson that set the rule
I did not invent this discipline in the abstract. I learned it the expensive way.
Early on, swapping one identity provider for another consumed an entire sprint, because the coupling to that vendor ran deeper than anyone had tracked. One swap, one sprint, for a dependency I had treated as settled.
That was the cheap version of the lesson. Now imagine that coupling living inside a dozen shipped ERP modules instead of inside the platform. The same mistake, multiplied across every feature that assumed the old shape. I decided I would rather pay the cost once, in the foundation, than a dozen times, in the product.
The hard part is not the engineering
Writing the gate was a paragraph. Living behind it is the discipline.
For multiple sprints there has been nothing flashy to show. No screenshot of an invoice that says "look, it works." The roadmap instinct, and every conversation with someone who wants to see the product, pushes the same direction: build the feature, show the thing, prove it is real.
Holding the gate closed against that pressure, when shipping a module would feel like progress and would photograph better, is the founder decision I have found hardest. Saying no to your own roadmap is harder than saying no to a competitor's.
What "no" actually bought
The platform is now at the point I built it for. Tenancy, identity, fine-grained permissions, audit trails, deployment automation, observability: the unglamorous half of an ERP, built thoroughly while there was time and no customer waiting.
When the gate opens, every future module starts from a position of strength instead of accumulated compromise. The first ERP feature I ship will sit on a foundation that was designed for it, not retrofitted around it. That is the entire bet.
The discipline is not patience for its own sake. It is the refusal to let a demo-able feature buy me a structural problem I would be paying off for years.
Where platform-first is the wrong call
I would not give this advice to every founder, and the honest version names the conditions under which it is wrong.
If you have not validated that anyone wants the product, platform-first is a way to spend a year building load-bearing infrastructure for a building nobody ordered. A pre-customer founder who needs a market signal should ship the thin visible thing, get the rejection or the pull, and only then decide whether the foundation is worth pouring. The gate is a bet that the demand is real and the system is genuinely deep. An ERP is, a single-purpose tool usually is not. On a shallow product, the foundation and the feature are nearly the same thing, and the whole tradeoff collapses.
What earns the right to hold the gate closed is that I already knew the demand and the shape of the system. I was not deferring product discovery behind a wall of plumbing. I was refusing to build the plumbing twice. Those are different decisions that look identical from the outside, and conflating them is how platform-first turns from discipline into avoidance.
The question I would put to any founder building something with real depth: which of your features is quietly assuming an answer your platform has not actually decided yet? Find that assumption, and you have found the thing worth building first. A foundation poured on purpose costs you one slow year; a foundation retrofitted under shipped features costs you every year after.
Series linkage
Part 1 of 3: "The Economics of a One-Person Platform Company". Part 2 takes the same lens to the rest of the record: what multiple sprints solo with AI actually taught me, and where the bottleneck turned out not to be.
- why-i-said-no-to-erp-features-for-multiple-sprints: holding the feature gate closed as the strategy.
- multiple-sprints-solo-what-ai-taught-me: the bottleneck was never velocity; it was decision quality.
- the-economics-of-a-one-person-platform-company: the cost structure that makes a solo platform company possible.
About AmanERP
AmanERP is an AI-native ERP for SMBs, built in public exactly the way this piece argues: platform first, features second. Aman means peace: business software that feels calm instead of chaotic.