Indie hacking ·
From Idea to SaaS: What Building Small Products Has Taught Me
Lessons from building independent SaaS products, from validating ideas and shipping quickly to finding users and improving products based on real feedback.
One of the biggest changes in how I approach software is that I no longer want to spend months building something before discovering whether anybody needs it.
I would rather build something small, release it and learn.
That sounds obvious.
It is surprisingly difficult to practise.
Developers naturally enjoy building. Adding another feature feels productive. Reworking a dashboard feels productive. Changing the architecture feels productive.
But none of those things necessarily answer the question that matters:
Does this solve a problem someone cares enough about to use?
Building products such as BankConvert and KitaPhone has changed how I think about that question.
Start With an Annoying Problem
Some of the best product ideas are not revolutionary.
They are annoying.
Converting a bank statement into a usable spreadsheet is annoying.
Making an international phone call can be annoying.
Those problems already have solutions.
That does not mean there is no opportunity.
Sometimes the opportunity is simply making the workflow faster, easier or more understandable.
You do not always need to invent a new category.
You can improve an existing experience.
Build the Smallest Useful Version
There is a big difference between a minimum viable product and an unfinished product.
A useful MVP should complete the main job.
Everything else can come later.
If the product converts documents, make the conversion excellent.
If the product makes calls, make the calling experience excellent.
You can add dashboards, advanced analytics, integrations and countless settings later.
This constraint is especially important for independent developers because time is your most limited resource.
Every secondary feature delays feedback on the primary feature.
Your First Users Change the Product
Before launching, you make assumptions.
After launching, users start correcting them.
They may misunderstand wording you thought was obvious.
They may ask for something you considered unimportant.
They may completely ignore the feature you spent the most time building.
That is useful information.
I increasingly prefer launching something at 80% of my imagined version and allowing actual usage to determine the remaining 20%.
The alternative is designing for an imaginary customer.
Marketing Cannot Wait Until Launch Day
One mistake I made early in my journey was mentally separating development and marketing.
First build.
Then market.
I do not think that way anymore.
Marketing begins while the product is being built.
You can discuss the problem.
Share development progress.
Write educational content.
Ask potential users how they currently solve it.
Join relevant communities.
Study competitor reviews.
Look at the questions people repeatedly search for.
By launch day, you should already have some idea where your first users might come from.
Small Products Are Excellent Teachers
A small SaaS product forces you to learn things a normal development project does not.
Pricing.
Customer support.
Payments.
Analytics.
SEO.
Copywriting.
Product positioning.
Infrastructure.
Email deliverability.
User onboarding.
Conversion optimisation.
Suddenly you are not only writing software.
You are operating a tiny business.
That is one reason I enjoy building independent products.
Every project exposes another part of the system.
Shipping Creates Momentum
There is something powerful about having a real URL you can send somebody.
Not a Figma design.
Not a GitHub repository.
Not an idea written in Notes.
A working product.
Once something exists publicly, the questions become much more concrete.
Why are people leaving this page?
Why did nobody click this button?
Why did this user convert?
Why are people searching for this feature?
Those questions lead to better decisions than endlessly asking:
"What should I build?"
My Current Approach
Today, my product-building process is increasingly simple:
Find an irritating problem.
Understand how people currently solve it.
Build the smallest version that completes the job.
Launch.
Get people to use it.
Measure what happens.
Talk to users.
Improve it.
Repeat.
There is no guarantee that a product will work.
That uncertainty is part of building.
But I would rather discover that through real users than through another six months of development.
The goal is no longer to build the perfect first version.
The goal is to create something useful enough to earn the next iteration.