Lessons Building SaaS: What I Would Do Differently

Two years into building CyberSygn, the mistakes have finally come into focus, and three of them quietly cost me months of avoidable work that I would gladly hand to you for free.

The most useful lessons building SaaS tend to arrive far too late to use, which is exactly why I am handing mine to you instead of keeping them to myself. After two years building CyberSygn, there are several decisions I would make differently if I started over from scratch, and they fall into two groups worth separating. Some are structural, meaning the big choices about what to build and in what order, while others are tactical, meaning the smaller choices about how to ship the same thing more cleanly. Both lists deserve an honest accounting, because every item on them cost me weeks I never needed to spend. In this post you will get my real indie SaaS retrospective, which comes down to three moves: ship the marketing before the product, charge from day one, and build your eyes before you need them. Skip these three and you land months ahead of where I actually was.

Build the marketing site first, not the product

My biggest structural regret is that I built the detection engine before I built the marketing site, and it is worth sitting with what that actually means. I had a fully working product before a single person could find me, so the thing existed and yet remained completely invisible to the market it was built for. If I started again, the marketing site and the blog would come first, ahead of the engine and ahead of any polish, because the product existing is necessary but nowhere near sufficient on its own. It is the marketing surface that brings in the first hundred customers, not the engineering underneath it, since the code simply does not sell itself and never will. What actually fills the funnel is a page that shows up in search, answers a real question someone is asking, and then asks clearly for the signup. That is the hardest piece of founder hindsight for me to swallow, because I am an engineer by instinct and so I naturally built the engine first, while the market did not care how good it was until it could find it at all. The lesson reduces to something simple: build the door before you build the house behind it.

Charge from day one, not month six

My second structural change is about money, and more precisely about timing. I ran a free preview for the first six months before I added any paid tiers, which felt safe at the time but turned out to be a genuine mistake. The catch is that free users do not give you the same feedback as paying users, and the gap between the two is not small. Paying users tell you what they actually need, because they have skin in the game and therefore tell you the truth about where the product falls short. Free users, by contrast, tell you what would merely be nice to have, which gives you a wish list rather than a roadmap. So six full months of free feedback ended up shaping the product around what was pleasant instead of what people would pay for, when charging from day one would have started the real feedback loop half a year earlier. The price itself does not have to be high to do its job, but it does have to be real, because a real price is what turns vague praise into honest direction, and honest direction is the single most valuable thing you can get early on. This is the lesson I find myself repeating most often whenever other founders ask me what I would change.

The tactical lessons building SaaS taught me: build your eyes first

Now for the tactical change, which is the one I underestimated by the widest margin. I added structured logging, error monitoring, and the metrics dashboard months after I genuinely needed them, which meant that for far too long I was effectively flying blind. Observability is just the collection of tools that let you see what your software is actually doing, meaning the logs, the error alerts, and the dashboards, and without them every bug becomes a guessing game you play in the dark. Here is the trade I had backwards: every minute I spent debugging without observability was worse than the minute I would have spent building it in the first place, because the blind minutes were more expensive every single time. If I started again, the observability layer would come first, ahead of features and ahead of scale, even though it feels like a detour when you are racing to ship. It is not a detour at all, because it is the thing that makes every later fix fast instead of frantic, so you should build your eyes before you ever need to see in the dark.

Write your decisions down as you make them

There is a smaller tactical habit I would add alongside everything above, which is to write things down at the exact moment you decide them. Early on I made dozens of consequential design calls and kept every one of them in my head, and roughly six months later I could no longer reconstruct why I had chosen one approach over another, so I wasted entire afternoons second-guessing work that was already perfectly correct. A plain running log of decisions, even a single sentence apiece, would have spared me hours of relitigating choices I had already settled. The discipline costs almost nothing in the moment, yet it compounds over time, because the version of you debugging a strange edge case next quarter will be grateful the reasoning was written down. Among all the building SaaS lessons I collected, this is the cheapest one to adopt and the easiest one to skip.

The real pattern behind every mistake: sequence, not skill

Notice the thread running through all of these mistakes, because not one of them is genuinely about writing better code. They are fundamentally about order: marketing before product, paid before free, and visibility before features. The hard part of building solo was never the engineering itself but the sequencing, the discipline of arranging the work so that each step paid off as early as it possibly could. That is the throughline behind every one of these solo founder mistakes, and it is the single insight I wish someone had pressed on me before I wrote my first line of production code. If you remember nothing else from this indie SaaS retrospective, remember that the order in which you build determines how quickly anything you build can actually matter.