What I learned taking a SaaS from 0 to $1M ARR
Over the past few years I helped build a SaaS from scratch — from the first Figma frame to the day annual recurring revenue crossed seven figures. It was not a straight line. It was a sequence of decisions, some right the first time, others fixed in a hurry in production.
This article is a summary of what I would carry into any new product.
1. Perceived value is the product
Users don't buy architecture. They don't see Redis, the queues, the retries with backoff. They see the screen load fast, the message arrive, the report make sense. Engineering exists to sustain an experience — and the experience is what people pay for.
In practice, this changed the order of my decisions: first the journey in Figma, then the API contract, implementation last. When that order flips, the product becomes a mirror of the database — and nobody pays for that.
2. Scale is decided on day one
There's a romantic idea that scale is a good problem for the future. The catch: the decisions that define whether you'll scale without a rewrite are made in the first weeks — multi-tenancy, asynchronous messaging, idempotent webhooks.
None of these are expensive at the start. All of them cost a rewrite if left for later.
3. A lost message is a lost customer
In a customer-service product, the worst bug isn't the one that breaks the screen — it's the one that silently drops an event. An unprocessed WhatsApp webhook is a conversation that never happened and a sale that never closed.
Concurrency here isn't optimization, it's correctness: guaranteed ordering per conversation, parallelism across conversations, queues with reprocessing. The system may slow down for a minute; it can never lose a message.
4. Observability buys sleep
Every system breaks. The difference between a five-minute incident and a lost night is knowing where it broke before the customer feels it.
Metrics, structured logs and alerts are not luxury infrastructure — they are the difference between operating a product and being hostage to it. The best compliment a production system can get is nobody talking about it.
5. Product and engineering need the same brain
Working as PO and developer at the same time taught me that the classic friction between "what the business wants" and "what can be built" is, most of the time, a lack of shared context.
When the same person (or a genuinely integrated team) understands both the sales funnel and the cost of the queue, decisions change: features are born smaller, sharper, with a clear path to value. The ticket stops being a request and becomes a hypothesis.
6. $1M ARR is not a finish line
Seven figures of recurring revenue sounds like the end of a movie, but in practice it's a checkpoint: the customer base grows, volume doubles, and the day-one decisions get tested again — at a bigger scale.
What remains is the method: design before coding, decide scale early, treat every event as money, measure everything, and never forget there's a person on the other side of the screen deciding whether it's worth what it costs.
If you're building a product and want to talk through any of these points, reach out on LinkedIn.