Most products start as something else
A lot of the products in the catalog did not begin as businesses. They started as a script someone wrote for their own work, a weekend experiment, a tool built for a friend, or a way to learn a new framework. Somewhere along the way other people started using it, and the maker wondered whether it could become more.
That transition, from side project to small SaaS, is less about code than about shifting how you think about the thing. A side project only has to work for you. A product has to work for strangers, reliably, and ideally pay for itself.
This post covers how to make that shift without quitting your job or losing your weekends entirely.
Is this the right project to grow?
Not every side project should become a business. A few questions help sort them:
- Do people other than you use it without being asked? Unprompted usage is the strongest early signal.
- Is the problem recurring? Subscriptions fit problems people have every week or month. A one-off need suits a one-time purchase better.
- Can you describe the user in one sentence? "Freelance translators who manage multiple client glossaries" is a market. "Anyone who writes" is not.
- Would you enjoy working on it for years? Small SaaS tends to be slow. Interest in the problem keeps you going when growth is flat.
- Can one person support it? A product that needs 24/7 uptime and phone support is hard to run beside a job.
If most answers are yes, it is worth trying. If they are mostly no, the project may still be worth keeping as a hobby or an open-source tool. That is a fine outcome too.
The pieces a real product needs
A side project can skip many things that a paid product cannot. When you make the switch, these tend to come up:
| Area | Side project | Product |
|---|---|---|
| Accounts | Maybe none, or just you | Signup, login, password reset, account deletion |
| Payments | None | Checkout, receipts, cancellation, failed payment handling |
| Reliability | Fix it when you notice | Monitoring, backups, error alerts |
| Data | Whatever works | Clear privacy policy, secure storage, export |
| Support | None | A contact address and reasonable response times |
| Legal | None | Terms of service, privacy policy, business registration where required |
| Docs | A README | Getting-started help for non-technical users |
None of these is exciting, and all of them take longer than expected. Budget for them. Many makers find that the "product" work takes as long as the original build.
The legal and tax requirements vary a lot by country. It is worth checking what applies to you, and a merchant-of-record payment service can take some of the tax burden off your plate.
Working around a job
Most indie products are built by people with other commitments. Some patterns that help:
- Protect a fixed block of time. Two focused evenings and one weekend morning each week, kept consistently, beat sporadic all-nighters.
- End each session by writing the next step. When you sit down next time, you start immediately instead of reorienting.
- Separate building time from marketing time. Decide in advance which session is for which. Otherwise building always wins.
- Keep scope small. A product that does one thing well is achievable part-time. A platform is not.
- Check your employment contract. Some contracts have clauses about outside work or intellectual property. Know where you stand before you charge money.
It also helps to be honest with yourself about energy. A few months of steady part-time progress is common. Several years without a break is how people burn out.
Choosing what to build next
Once there are users, requests pile up fast. With limited time, choosing well matters more than building quickly.
A simple filter:
- Does it help new users reach value faster? Onboarding improvements often matter most early on.
- Does it stop paying customers from leaving? Retention work compounds.
- Did several unrelated users ask for it? One loud request is not a pattern.
- Can you build it in a week or less? If not, can you build a smaller version first?
Say you have 25 paying users, and requests come in for team accounts, a mobile app, an integration with a popular calendar tool and a dark mode. If six users asked for the calendar integration and it takes a week, while team accounts were asked for by one user and would take a month, the choice is fairly clear.
Money and expectations
Be realistic about the numbers. Many side-project SaaS products end up earning a modest amount: enough to cover their own costs, perhaps a nice monthly bonus. A smaller share grow into a full income, and those usually took years.
That is not a reason to stop. A product that earns a few hundred a month, costs little to run and teaches you how to build and sell software has real value. It is a reason to keep your job until the numbers clearly say otherwise.
Before leaving a job for a product, many makers wait until:
- Revenue covers a meaningful share of living costs and has been stable or growing for several months.
- They have savings for a buffer period in case growth stalls.
- Churn is understood and under control, so the revenue is not a leaky bucket. See Reducing Churn for Small SaaS.
When to reconsider
Sometimes the honest answer is that the project will not become a business. Signs include:
- No one pays after repeated, direct asking.
- Usage stays flat despite months of consistent distribution work.
- You dread working on it.
Options at that point include narrowing to a smaller niche, pivoting to a related problem the users mentioned, open-sourcing the code, selling it to someone who wants to run it, or simply shutting it down cleanly and telling users with plenty of notice. Each can be a good outcome. Plenty of makers credit an earlier, abandoned product for what they learned before the one that worked.
FAQ
Should I open-source my side project or charge for it?
Both are possible, and some makers do both: open-source core with a paid hosted version. Browsing the GitHub entries in the catalog shows several approaches.
Do I need to register a company first?
It depends on your country and circumstances. Many makers start as individuals and register once revenue appears. Check the local rules or ask an accountant.
How long before I know if it will work?
There is no fixed timeline, but a few months of consistent effort on both building and distribution usually gives you enough signal to decide whether to double down, change direction or stop.