I do systems work for funded early-stage startups: the architecture decisions that are expensive to reverse, the money path built right the first time, and diligence-readiness before the term sheet — without hiring the platform team you do not need yet.
What is actually worth doing properly at seed?
Almost nothing, and that is the honest starting point. Seed-stage code is supposed to be scrappy, most of it will be deleted, and gold-plating it is the classic way to run out of runway with beautiful infrastructure and no customers. Anyone selling you enterprise architecture at this stage is selling you their own comfort.
But three decisions get expensive precisely when you can least afford the distraction:
How money is recorded. Retrofitting a ledger under a live product with real balances is surgery, not refactoring. The version of this you build in a week at seed is the version that survives; the version you retrofit at Series B costs a quarter and a senior engineer’s sanity.
How the domain is modelled. The wrong core entities calcify into every feature that follows, because each new feature is written against them. Renaming a concept is easy; discovering that your central object was the wrong abstraction is not.
What your data can prove. Diligence asks. Not “is your code good” but “show me revenue by cohort, reconciled to the bank, for the last eighteen months.” Systems that cannot answer that turn a two-week diligence into a six-week one, at exactly the wrong moment.
What does the engagement look like?
- The pre-Series-A architecture review. Two weeks, every major flow traced, a written verdict prioritised by cost-to-undo — with an explicit list of what to leave scrappy. That list is usually longer than the fix list, and founders find it more useful.
- Money-path build. Even a thin double-entry core beats the balance-column debt: the fintech practice, sized for a company that has twelve customers and hopes for twelve hundred.
- Diligence-readiness. The data-room technical section prepared before the term sheet rather than during the scramble — the same read an acquirer’s advisor would do, run on you, for you.
- Fractional senior cover through the raise. Advisory or fractional CTO, for the months when the founder is fundraising and cannot also be the technical adult in every room.
The Bengaluru-specific version of this
Swalpa adjust maadi is a genuinely good engineering instinct at this stage — ship it, patch it, learn, move. I am not here to argue with it, and most of the review’s recommendations are “keep adjusting, this is fine.”
The money path is the one place I will push back, with love. Because that is where adjusting compounds into something you cannot see: a balance column that has been correct-ish for eighteen months, a refund flow that skipped the posting rules, a webhook handler without an idempotency key. None of it breaks visibly. All of it surfaces together, usually during diligence, usually as the ledger-drift story with your company’s name on it.
Two weeks of review before the raise is cheaper than two weeks of explanation during it. And if the verdict is “you are fine, ship” — which happens — that is worth knowing too, in writing, with someone’s name on it.
Related reading
/industries/series-b-onward — the next stage’s version of this · /services/architecture — the review · /blog/why-your-ledger-drifts — what skipping the money path costs · /services/fractional-cto — cover through the raise
Raising in the next twelve months?
The architecture review pays for itself in the diligence meeting alone — and the list of things you are allowed to keep hacking is free. /contact — chalo, selectively future-proof karte hain.
Questions I actually get
We cannot afford senior engineers right now.
You are not hiring one. You are renting the ten per cent of one that prevents a rewrite you cannot afford at Series A. The review is fixed-scope and deliberately short, because the value is in the verdict rather than in a long engagement.
Investors are asking technical questions we cannot answer.
Then run the diligence on yourself first, quietly, before someone else runs it publicly. The delivery service does exactly that — the same read I would do for an acquirer, with the findings going only to you and time to fix them.
Will this slow our shipping down?
The review's main output is a list of what NOT to build properly yet. Half its value is explicit permission to stay scrappy where scrappiness is safe, which is most places. Founders usually leave with fewer things to worry about, not more.
Which decisions are actually expensive to reverse?
Three: how money is recorded, how the domain is modelled, and what your data can prove. Everything else — frameworks, hosting, styling, even most of the API surface — is cheap to change later. Those three calcify.
We are pre-revenue. Is this premature?
Probably, and I will say so. If money is not moving yet, come back when it starts — or read the ledger design article and build the small correct version yourself. There is no point paying for advice you can act on for free.
How long does the review take?
About two weeks, with a written verdict prioritised by cost-to-undo. Fast enough to fit inside a raise timeline, which is usually when founders discover they need it.