What I check before building a SaaS
A short list I run through before turning a client problem into a product of its own.
1 min read
- saas
- process
Some problems I solve for one client turn out to be problems a lot of businesses have. That's how most of my product ideas start. But "a client needed this" isn't enough to build a SaaS around, so I run through a few questions first.
The questions
| Question | What I'm looking for |
|---|---|
| Have I seen it at three businesses? | Not one client and a hunch |
| Are they already paying to work around it? | Staff time, a tool they hate, an agency |
| Can I explain it in one sentence? | If not, it's probably a service |
| Who signs off on the purchase? | A person I can actually reach |
| Can I build a useful version in a month? | Something people would pay for, not a demo |
If I can't answer at least four of these with something concrete, I keep it as client work. That's fine. Client work pays and teaches me what to build next.
The one I weigh most
Are they already paying to work around it? If a business is spending three hours a week on a manual process, or paying for a tool they only use one feature of, there's a budget. I'm not asking them to spend new money, just to move it.
Problems where nobody is spending anything yet are harder. Sometimes they're the best ideas. Usually they're the ones where people say "that would be nice" and never sign up.
This list will change. It's already different from what I'd have written a year ago, mostly because of products I built that answered "no" to the third question and found out the hard way.