Back to blog
February 18, 2026Sergei Solod4 min read

Why Getting Customers Felt Harder Than Building a SaaS

A first-hand lesson from building a SaaS: engineering gave me clear, checkable feedback, while distribution, positioning, messaging, and retention required a different and much less predictable loop.

SaaS growthCustomer acquisitionProduct marketingBootstrappingIndie hackingDistribution

One of the most surprising lessons in building a SaaS is that the hardest part often starts after the product works. Writing code, shipping features, fixing bugs, and deploying updates all feel concrete. There is a clear problem, a clear system, and usually a clear next step.

Getting customers is different. Distribution is messier. Positioning is fuzzy. Messaging takes taste. Clicks, CTR, retention, and conversion force you to think less like an engineer and more like a marketer, writer, researcher, and psychologist at the same time.

Shipping is only the beginning

Many developers underestimate this because software gives immediate feedback. A button works or it does not. A deployment passes or fails. Marketing rarely works like that. You can publish something thoughtful and still get ignored. You can build a useful product and still struggle to explain why anyone should care.

That gap can be frustrating, especially when building solo. It feels like learning a second profession from scratch while also trying to keep the first one alive. And that challenge is not talked about enough in honest SaaS conversations.

Distribution has a different feedback loop

That difference matters because marketing metrics are signals, not explanations. A click or a change in CTR can tell me that something changed, but not by itself whether the reason was the audience, the channel, the message, the timing, or the product. Retention and conversion are useful for the same reason: they narrow the question, but they do not answer it for me. The work is in interpreting the signal and deciding what to try next.

Why the creative side feels harder

  • Code rewards logic and structure.
  • Distribution depends on attention, timing, trust, and repetition.
  • Good messaging is often simple, but reaching that simplicity takes a lot of iteration.
  • Even strong AI tools can help with code faster than they help with original positioning or human-sounding creative work.

That last point is especially funny right now. AI can be extremely useful when the task is technical and well defined. But the moment the job becomes creative, nuanced, or voice-driven, the output can become painfully awkward. That contrast says a lot about what still needs human judgment.

I do not take this to mean that AI cannot do creative work. My narrower conclusion is that, in my use, AI is easiest to trust when the task is constrained and the result can be checked. Positioning and voice have no equivalent of a typechecker. I still have to decide whether the result is specific, believable, and right for the audience.

Shipping changed meaning for me

That changed how I think about shipping a SaaS. The product can be live and technically healthy while the distribution problem is still almost untouched. After launch there is another loop: explain who the product is for, help the right people discover it, watch what they do, and adjust both the message and the product. For a solo developer, that work competes for the same limited attention as engineering.

What I would keep in mind before the next launch

  • Can I explain clearly who the product is for and why they should care?
  • Where will the first users actually discover it?
  • Which signals will I watch—clicks, CTR, conversion, retention—and what can each one not tell me?
  • Am I treating AI output as a draft to judge rather than a substitute for judgment?

This is not a universal rule

I am not claiming that customer acquisition is always harder than engineering for every SaaS. Some products have brutal technical constraints; others already have distribution. My point is narrower: for a developer who is comfortable building software, post-launch work can require a different skill set and a much less deterministic feedback loop. In my case, that was the part that surprised me most.

My practical conclusion is simple: shipping is not the finish line. Customer acquisition, positioning, messaging, and retention are real product-building skills. They are slower to learn and harder to debug than code because the feedback is noisier, but ignoring them does not make them disappear.