Lessons from Launching Our First SaaS Product

I have shipped two products that went nowhere. Not "nowhere" in the dramatic, losing-money sense — more like the quiet kind of failure where you push a product live, share it a couple of times, and then watch the analytics flatline for weeks. No traction. No feedback. No nothing.

For a long time, I told myself the products just needed more time. Then I told myself the SEO needed work. Eventually, I had to be honest with myself: the problem was not the code. The problem was that I had no idea how to get a product in front of people, and I had not validated whether anyone actually needed what I built.

Billtrio — a GST-compliant invoicing tool for Indian freelancers and small agencies — is my third attempt. We are still early, but the way I have approached this one is genuinely different. And the differences have been uncomfortable to learn.

Here is what I have picked up along the way.

Building in a vacuum is a real thing, and it is easy to fall into

When you are a developer, building is the comfortable part. You know the tools. You know how to solve technical problems. There is a satisfying feedback loop — write code, see it work, ship it.

What that loop does not tell you is whether anyone on the outside cares.

With my first two products, I started with a feature idea and worked backward from there. I never really sat with the question of who, specifically, was going to use this, what problem it solved for them on a Tuesday afternoon, and why they would choose my tool over doing nothing at all.

With Billtrio, I started from a different place. I looked at a specific group of people — Indian freelancers billing clients, dealing with GST, trying to export GSTR-1 data without tearing their hair out — and asked whether existing tools were actually built for them. Most of the established invoicing products in the market are either too complex, priced for larger businesses, or simply not designed around Indian compliance requirements.

That gap is real. And building toward a gap you can clearly describe is very different from building a tool and then hoping a gap exists.

Distribution is a skill. It does not come automatically with a good product.

This is the one that took me the longest to accept.

I used to believe, in some fuzzy way, that if a product was genuinely useful, people would find it. Word would spread. Maybe a Reddit post would go somewhere. The quality of the work would speak for itself.

That is not how software discovery works. Nobody is looking for your product by default. There are too many products, too much noise, and not enough time for anyone to go searching for the specific tool you built unless they have a very specific reason to look.

With Billtrio, I have had to build the distribution work alongside the product itself. That has meant thinking about SEO from day one, not as an afterthought. Getting listed on directories. Writing content that answers real questions people type into search engines. Being present on Reddit threads where freelancers complain about invoicing. Posting updates on LinkedIn not to show off, but to stay visible to people who might eventually become users.

None of that comes naturally to someone whose entire professional identity has been wrapped up in writing code. But it is just as important as the product itself — arguably more so in the early days, when you have no organic traffic and no word-of-mouth.

Niche is not a limitation. It is a starting point.

When I was scoping Billtrio, I had a few moments of wanting to make it more general. Why limit it to Indian freelancers? Why not make it work for everyone?

The answer I came to: if you try to serve everyone, you end up serving no one particularly well. More importantly, you end up with messaging that is so broad it does not resonate with anyone specifically.

Building for Indian freelancers and small agencies meant I could make very concrete product decisions. GST invoice formats, GSTR-1 export, Razorpay as the payment processor, WhatsApp invoice delivery because that is how Indian business communication actually happens. Multi-currency support for freelancers billing international clients while staying GST-compliant. These are not generic features. They are features that matter to a specific person dealing with a specific context.

That specificity has also made content and positioning much easier. When you know exactly who you are talking to, you can write for them directly. You can answer the exact questions they are searching for. You are not trying to be all things — you are trying to be the right thing for this group of people.

Starting narrow does not mean staying narrow forever. But it is much easier to expand outward from a focused position than to try to carve out space in a crowded general market.

Your tech stack will not be your competitive advantage

I spent significant time on the Billtrio architecture. Next.js 16 App Router, Prisma, Supabase, proper server actions, clean TypeScript, zero errors. It is a solid codebase. I am glad it is clean.

But here is the thing: no user will ever know or care about any of that.

What they will care about is whether the invoice generates correctly, whether the GST amounts are right, whether the PDF looks professional enough to send to a client, and whether the whole process takes them two minutes instead of twenty.

The technical decisions matter because they affect reliability, speed, and your ability to ship new features without everything breaking. But they are a foundation, not a selling point. The product experience is the selling point.

Early on I caught myself wanting to spend more time refining the architecture when what I should have been doing was testing the product with real users and figuring out where the friction was. These are different activities with very different returns at the early stage.

Validating demand before building saves enormous amounts of time

I did not do this well with my first two products. With Billtrio, I did it better — though still imperfectly.

The question to answer before writing a line of code is not "can I build this?" It is "do enough people want this badly enough to pay for it, or at least actively seek it out?" Those are different questions, and the second one requires actually talking to people or at minimum doing careful research rather than building on assumption.

For Billtrio, I looked at search volume, at the complaints in freelancer communities, at the limitations of existing tools. I found evidence that the problem was real and recurring. That gave me more confidence going into the build.

Even so, there were features I built that turned out to be less important than I thought, and pain points I underestimated that became more central once I was closer to real users. Validation is an ongoing process, not a one-time checkbox before you start coding.

The work does not end at launch

With my earlier products, I treated launch as an endpoint. The product is live — now I wait.

That is the wrong mental model entirely. Launch is just the point where the real work becomes visible. Before launch, you can hide in the build. After launch, you have to be out in the world making noise, collecting feedback, iterating, and finding the people who actually need what you built.

For Billtrio, the weeks after the initial build involved SEO audits, new landing pages, free tools to drive organic traffic, directory listings, content calendars, social posts. Things that have nothing to do with the product code but everything to do with whether the product finds users.

This is ongoing. It does not stop.

What actually changed between the first two products and this one

Looking back, the gap was not effort. I was working hard on WriterDock and EditifyHub. The gap was clarity.

I did not know clearly who I was building for. I did not have a specific, describable customer whose exact problem I was solving. I did not have a distribution plan. I assumed traffic would come.

With Billtrio, I have been far more deliberate about all three. The customer is specific. The problem is concrete. The distribution is something I am actively building rather than passively hoping for.

The build itself has also been cleaner because specificity forces better decisions. When you know exactly who is using your product and what they are trying to do, feature prioritization becomes much clearer.

Conclusion

None of this is especially original advice. Most of it is the kind of thing you can read in any founder essay. But there is a difference between knowing something intellectually and learning it by actually shipping a product and watching what happens.

The lessons above are things I now know in a way that sticks — because they came from doing, not from reading.

If you are building something, the most useful question you can ask yourself right now is probably not a technical one. It is: do I know exactly who is going to use this, why they will choose it, and how they are going to find it?

If those three answers are not clear, that is worth pausing on before writing another line of code.