The 5-step day job SaaS escape plan

In this post I explained why I’m obsessed with building SaaS products, and why I think you should be too.

But how do you find a good SaaS (software-as-a-service) idea?

It’s difficult.

At first you’ll probably have no ideas at all. And then once you get started thinking about it, you have a hundred ideas.

But ninety-nine of them will be bad.

So how do you pick the one good one?

Here’s what NOT to do.

Each of these could be a newsletter in itself but in the interests of time, I’m going to give you two hard and fast rules which are worth following at all times.

Don’t try and build a SaaS for your friends or any other “consumers” - consumers are typically reluctant to pay for SaaS products. And no, Netflix is not a SaaS, it’s a content delivery platform.

“There are approximately zero successful B2C SaaS products” - a quote from SaaS guru Rob Walling who seriously knows his stuff.

Don’t come up with ideas for SaaS products if you can’t answer the question “who will your first 5 customers be?” in detail (ideally with actual names). The hardest part of building a SaaS is always marketing/selling, so don’t make it harder by choosing a market you’re not sure how to sell to.

So where does that leave us?

We need a SaaS we can sell to businesses (B2B) in a sector we are familiar with.

Why businesses you ask?

Unlike consumers, businesses are accustomed to spending money in order to make more money. They have budgets set aside to spend on software. They make rational purchasing decisions based on the return on investment they’ll get, either in terms of time/money saved, or revenue increases.

This makes them a good potential customer for your SaaS.

Hmmm. Where can we find such businesses?

The “find a SaaS idea in your day job” approach.

This is just one of many approaches to finding a SaaS idea but it’s also one I see time and again being successful (examples later) because it ticks a lot of the boxes from the outset.

It’s likely your day job involves working for a business or organisation where you have insider knowledge about the industry and, crucially, the inefficiencies and problems.

You may also know what software your employer currently uses, and perhaps even who makes purchasing decisions.

This is all solid gold intel.

Let me tell you about my friend Lisa.

For the last few years she’s worked in property planning here in the UK, either for councils or private companies.

When homeowners want to add an extension onto their house, or commercial developers want to build on a plot of empty land, Lisa’s job is to search for previous planning applications and appeals to find out their result.

The software she used to do this, which she knew her employer paid for, was a basic outdated SaaS product which let her search through planning application documents.

The functionality was slightly better than the government’s own search tool, but still lacked loads of features.

Rather than just sit there and accept the status quo, Lisa began thinking about what improvements could be made.

Knowing I’m a developer, she asked me how difficult it would be to build an improved version and I told her it wouldn’t be too hard.

Together with a friend we were able to figure out the government’s public API and were able to do a proof of concept which pulled all the planning data and made it searchable.

She then asked peers in similar roles at other companies and councils if they would use her tool, and asked them to fill in a survey so she could get the right features and hit the right price point.

She’s not technical so she found a development agency to build it, and got a startup loan to pay for the build.

They spent the past few months building it and it launched yesterday!

Her employer will be her first paying customer.

Lisa’s gone from being an employee to owning her own SaaS business (she’s still an employee too). Hopefully in the not too distant future she’ll be able to leave her job and focus 100% on her SaaS.

What can we learn from her story?

The 5-step day job SaaS escape plan.

Here’s a framework I wish I’d known back when I had a day job!

And remember, you don’t have to apply this to your current day job, it could be previous jobs too (and will be legally simpler if it is).

Step 1

Pay attention to all the tasks at work done with emails, spreadsheets, on paper, or in other inefficient ways. Talk to your colleagues and understand what they do. Seek out the most annoying parts of their jobs.

Step 2

Identify problems or “jobs to be done” which could be significantly improved with software. Try to figure out why they aren’t being solved with software already.

Bonus points if your employer is already paying for software but it’s not solving the problem.

Bonus points if the problem is costing your employer significant time and/or money.

Negative points if your employer is aware software can help but isn’t motivated to pay for any. Find a new problem.

Step 3

Once you’ve found a real problem you think your employer would pay (or is paying) to solve, spend time digging into the issue and come up with a plan for software which could significantly improve the situation. Talk to your colleagues and your manager to get their feedback.

Step 4

Use whatever means you have to get closer to validating this idea.

Research other alternatives. If they don’t exist, it’s a bad sign. If they do exist, try and figure out why your company isn’t using them already.

Draw up wireframes - use paper, Figma, or any other prototyping method you’re comfortable with. Show them to your colleagues. Get feedback. Repeat and refine.

If you can, choose the most important core feature of your product. Build a basic MVP using nocode tools. Test the functionality on your colleagues.

Step 5

Once you’re pretty sure of your feature set, pitch it to your employer and say you’ll build it outside of work time. Check your employment contract to make sure your employer isn’t going to own all your IP (if it says they will, ask them to draft a new contract).

Mega bonus points if you can get your employer to agree to pay for the product once it’s launched. You can offer them a significant discount but make sure they’re willing and ready to pay.

If you make it through these 5 steps, then it’s time to build!

(That’s a whole other topic I’ll cover in later posts).

This all sounds a bit abstract. Nobody really does that do they?

Actually I think it’s more common than one would think because it’s a win-win situation for the employee and the employer.

But even if your employer isn’t interested - perhaps they’re too large to buy software from a solopreneur - you can still cover steps 1 to 4 and then sell to smaller organisations in the same industry.

Some inspiration:

Recently I spoke to someone who’s building a scheduling app for the shipping industry after seeing his wife spend hours doing it all manually. (BTW he’s using my Bullet Launch template to speed up his build).

I also know someone in real estate who’s building a contract templating app based on the money he saw being wasted on lawyers.

Johannes was freelancing on a Salesforce implementation, and saw a business problem that no existing app could solve. So he built smartupload.net in his spare time and his employer became his first customer.

A friend of mine built a profitable SaaS for escape rooms based on his experience working in one, and sold it to his employer.

Kate used the experiences from her time as a lawyer to build a micro-SaaS for that industry after being made redundant.

A teacher friend is in the process of building software to replace his school’s classroom organisation tool.

Milly Barker built a SaaS to handle press outreach based on her experience in her former job, and her ex-employer became her customer.

Andrew Vernon built a photography SaaS while working as a photographer, and his employer became his first user.

So what are you waiting for? Start your five step process today. Let’s go!