What a technical co-founder actually ships in the first ninety days
The founders I work with are not short of a plan. They have a market, customers, often revenue from doing the thing manually, and no one who can build the software. The first ninety days are about turning that into a product without making the four or five decisions that are expensive to undo.
Weeks one and two: watch the manual version
Before any repository exists, watch how the work is done today — the spreadsheet, the group chat, the folder of PDFs, the phone calls. That is the specification, and it is more accurate than anything either of us would write down, because it is what people actually do under time pressure rather than what they say they do.
Two things come out of this. The list of what must exist on day one, which is always shorter than the founder expects. And the list of what looks like a feature but is really a habit worked around a limitation of the spreadsheet, which should not be built at all.
Weeks three and four: the decisions that are expensive to reverse
A small number of choices are cheap now and costly forever after. They deserve the whole of this fortnight.
The identity and tenancy model. Who is a user, what they belong to, and how that is expressed in the data. Retrofitting multi-tenancy into a product that assumed one customer is close to a rewrite.
Key and identifier stability. Plan keys, price identifiers, collection names, document field names. These are data, not code — every existing record refers to them, and renaming one silently breaks history. Choose names you can live with, then stop touching them.
Where authorization lives. In the database, keyed on a signed claim. Decided once, at the start, because moving it later means auditing every path that already exists.
The cost shape. Whether a page view costs anything, and whether the answer stays the same when there are ten thousand of them. This is the decision founders never ask about and the one most likely to produce an unpleasant invoice in year two.
Weeks five to ten: the narrow product
Build the one path that the business already gets paid for, end to end, for real users. Not the admin panel, not the settings screen, not the second role. One path, in production, with real data in it.
What gets deferred, deliberately and out loud: analytics dashboards, bulk import, anything described as "while we are in there", and every feature justified by a customer who does not exist yet. The point of the narrow product is to find out which of the assumptions were wrong while changing them is still cheap.
Weeks eleven and twelve: the unglamorous half
What separates a demo from a product is entirely here. Password reset that works. Deletion that actually deletes, including uploads. Rate limits on every public endpoint. Terms and privacy that name the real entity and disclose what the product does with data. An error path that shows a person something useful. Rules tested against their denials rather than their allowances.
None of it demonstrates well and all of it is the difference between software you can charge for and software you cannot.
What ninety days does not produce
A finished product, and I say so at the start. It produces a live system with real users on the path that makes money, an architecture that will not have to be unwound, and enough evidence to decide what the next ninety days are for. Any engineer promising more than that on a fixed horizon is describing a demo.
Written by Liana Grigory, also written Liana Grigoryan — entrepreneur, technology founder and U.S. Army veteran in Los Angeles. More at Writing.