Before You Launch, Do the Job Yourself

This year I finally did something I'd been wanting to do for a while: I started and launched my own SaaS.

The delay was never about skill. I'm a software engineer, I build software for a living, and I've had the tools to build something of my own for years. What I didn't have was a problem I was confident was solving real pain, something people would actually pay for. Finding that took its own process. But the bigger realization came right after: even once you have a problem worth solving, that's still only half the job.

You can find something people clearly need solved and still build the wrong version of it, or worse, actually solve that exact problem while quietly creating new friction for the people who have to use it. If you want to build a genuinely good experience, not just for your customer but for your customer's customers too, you need to use the product yourself, on real people, before you hand it to anyone else. That's the realization that really landed for me this week. I'd spent a couple of months building the first iteration of the core product. I'd tested it myself, and I'd validated the ideas and the process with my friend, but actually using it to solve those problems on real use cases turned out to be a completely different animal.

Where the business idea came from

I found it by listening. I spent time with a friend, watching their regular routine running their business: the manual, tedious stuff piling up at the end of a long working day. Work they couldn't justify hiring someone for, but that was clearly automatable, or at least simplifiable.

That's where the idea started. Not at a whiteboard, but from a real person complaining about real friction. From there I asked two questions: can I actually solve this, and can the solution scale past this one friend's industry to other people doing similar work.

That's half the battle: finding a real pain point and shaping it into something that could plausibly work for more than one person.

Building is the fun part, and the trap

The second half is building it, which for me is the fun part. But being the builder means I already carry a picture in my head of what the end experience should look like. The person actually running the business, and their customers, can have a very different idea of what "works well" means. That gap is normal, but it stays invisible until you go looking for it.

So once I had something I'd call an okay proof of concept, I stopped guessing and stepped into the role myself. I used what I'd built every day, the way the employee my friend couldn't afford to hire would use it, to actually do the job. For two weeks I ran those tasks entirely through the product.

That gave me two kinds of feedback at once: how it felt to use the thing myself under real conditions, and how my friend's actual customers reacted, including situations I hadn't thought to plan for.

Two weeks doesn't make a product flawless. But it smoothed the rough edges, it pushed me to add features the feedback made obvious, it caught real bugs I never would have found testing alone, and it left me with a long list of things worth building next. More than that, it meant I could start taking on beta customers with real confidence, not just because things were fixed, but because I had already watched the product solve the exact problem it claims to solve, plus the side benefits that come with it.

The takeaway

• Find someone with real friction. If you don't have a business idea, or you're not sure what's worth building, find someone in your network who runs a business or works in an industry with obvious room to improve. Ask them about their day. There's a good chance you'll walk away with a list of complaints, and every one of those is a potential product, or a feature for one that already exists.
• Don't underestimate free help. Unless someone is working on something genuinely private or high stakes, almost nobody turns down a free hand with the annoying parts of their job. Volunteer for that, and you get more than goodwill: you get a live feedback machine that shows you exactly where your early product falls short and what to fix next.
• None of this requires anything rare. No special network, no unique insight. Just a willingness to listen, then go do the boring work yourself for a while.

That's the whole process, start to finish: find the real problem, then go prove it works before you ask anyone else to trust it.