From enterprise to building SaaS on my own: what transfers and what does not

For ten years I worked on enterprise and healthcare systems — C++, legacy code, regulated software. Large codebases, long release cycles, other people responsible for the parts I was not.

Over the past year I built several products end to end on my own: architecture, backend, frontend, deployment, the lot. This is an inventory of what carried over, written for engineers considering the same move — and against the two stories usually told about it, both of which are wrong.

The first story: enterprise experience is dead weight, all process and no shipping. The second: it is a superpower, you have seen real systems while everyone else was building CRUD. Neither survives contact with the work.

What transfers almost intact

Reasoning about failure modes. The single most valuable thing a decade on systems that must not fail gives you is the reflex to ask “what happens when this is unavailable / slow / wrong / called twice”. That question is domain-independent, it is the difference between a demo and a product, and it is the habit I see missing most often in code written by people who have only ever built greenfield.

Data integrity as a design input, not a feature. In regulated software you cannot bolt on the audit path afterwards; it changes your schema. Carrying that instinct into a product means you design for “who changed this and when” from the first migration, rather than discovering at month eight that you cannot answer a customer’s question.

Reading unfamiliar code. Enterprise work is largely archaeology. That skill turns out to be exactly what you need when a library behaves unexpectedly and the documentation is silent — you go read it, which most people treat as a last resort rather than a first one.

Writing things down. In a regulated environment you write down the reasoning because you have to. Working alone, you write it down because you will not remember in three months why you rejected the obvious approach — and past-you is now the only architect you have.

Testing discipline where it counts. Not coverage percentages. Knowing which failures are expensive and testing those. That judgement takes years to build and it survives the move completely.

What does not transfer

The safety net, and it is bigger than you think.

In enterprise, someone else	On your own
QA finds what you missed	You find it, or a customer does
DevOps owns the pipeline and the servers	You own the deploy, the TLS renewal, the backups
An architect vetoes the bad idea	Nobody vetoes anything
A PM defines “done”	You define it, and you will define it badly at first
Security review before release	Your own review, with your own blind spots
A specialist knows the frontend	You are now the frontend specialist

The breadth is the real shock, not the workload. Ten years of depth in one area is worth a great deal — and it is worth nothing at all when the problem is that your React state management is a mess or your nginx configuration is leaking a header it should not. You go from being genuinely expert to being competent-at-best across five areas simultaneously, and that is uncomfortable in a way nobody warns you about.

The second shock is that nobody defines “done”. In an enterprise, scope arrives from outside; you may argue with it, but it exists. Alone, “done” is whatever you decide, which means it can expand indefinitely, and it will, because there is always one more thing that would be better.

What actively gets in the way

This is the part enterprise engineers underestimate, myself very much included.

Engineering for scale you do not have. I designed the first version of a product for tenancy patterns and throughput that were never going to be exercised. Not because I was foolish — because in enterprise you are at that scale, so those instincts are correct there. Applied to a product with a handful of customers, they cost weeks and bought nothing. The fix is not “build it badly”; it is to build the seams that let you scale later, and then stop.

Waiting for the specification. There is no specification. There is a customer with a problem and a partly wrong description of it. The enterprise reflex — clarify requirements, then build — becomes paralysis when the requirements can only be discovered by building something and watching someone use it.

Process weight without process benefit. Regulated ceremony exists for a reason and I would not skip it in a regulated product. Applied to a marketing site, it is cosplay. Keep the habits that have a payoff at your scale — version control hygiene, review of anything security-relevant, backups you have actually restored — and drop the ones that only pay off with twenty people and an auditor.

Perfecting the invisible. A beautifully factored domain model that no customer will ever notice, while the onboarding flow is confusing. In enterprise that internal quality is legitimately someone’s job. Alone, every hour spent has an opportunity cost you personally pay.

What was genuinely new

Ops is not a separate discipline you can defer. The first time a certificate expires, or a deploy takes the site down at an inconvenient hour, you learn that “it works on my machine” was a luxury provided by other people. This turned out to be the most enjoyable surprise for me — but it is real work, and it is a whole area you did not have on your CV.

Decision speed is a skill of its own. In a large organisation, decisions are slow and that slowness is distributed — many people, many opinions. Alone, decisions are instant and entirely yours, which is faster and much easier to get wrong. The countermeasure I settled on is the same one that worked when leading a team: decide, write down the reasoning, and name what would change your mind. It makes fast decisions reversible instead of just fast.

The hard part is not the code. Ten years told me the difficulty of a project lives in its technical complexity. It does not. It lives in deciding what not to build, and in the honesty required to abandon something you have already invested in. Enterprise experience gives you no practice at either — scope was always someone else’s problem.

Would I recommend the move?

With one caveat: do not expect the enterprise background to be the advantage. It is an advantage, in the specific places listed above — failure modes, data integrity, the discipline to be precise about why you believe something works. Those are real and they show up in the products.

But the skill that determines whether you ship is scope discipline, and a decade of enterprise engineering will have given you approximately none of it. Knowing that in advance is most of the value of reading this.

The other thing worth saying plainly: the two are not in opposition. The rigour I learned on clinical systems is why I design encryption and audit trails into a product from the beginning rather than retrofitting them. The pace I learned building alone is why those products exist at all. Neither would have been enough on its own.

If you are making a similar move and want to compare notes with someone a year into it, I am happy to talk.