How to build a micro SaaS, brick by brick
Micro SaaS – kostička ke kostičce. You don’t need investors and a big team to build a software business. You need a narrow problem, a lot of honesty with yourself, and the discipline to build only what matters.
What is a micro SaaS?
I opened with a poster from RocketSpace, a startup campus in San Francisco, bragging about billions raised by its members and companies like Uber and Spotify. That is one end of the startup world. Micro SaaS is the other end:
- Narrow focus. It solves a highly specific problem for a well-defined audience.
- Low costs. Minimal development and operational expenses.
- Small team. Built and maintained by a single developer or a very small team.
- No need for large capital. It can be bootstrapped without external investors.
- Recurring revenue. Usually a subscription.
- High automation. Designed to need as little manual work as possible.
There are many kinds: B2B (invoicing and billing tools), B2C (a meal planning app), e-commerce (a Shopify plugin), community and membership (a puzzle community, which is my MySpeedPuzzling), automation and productivity (e-mail automation), dev tools, analytics and reporting, and AI.
But why?
- It’s fun.
- It’s sustainable next to your day job.
- You learn something new.
- Money, as passive income.
- Total freedom and 100% ownership.
- It’s a challenge.
- The approaches carry over to your day job.
Most of all: find your own, inner motivation. I showed the ikigai diagram here, the overlap of what you love, what you’re good at, what the world needs and what you can be paid for.
A friendly reminder
Building one alone needs a unique set of skills: UX, UI, backend, DevOps, marketing, communication, copywriting, design and sales. That is also the good news. A product built by such a combination is hard to copy one to one, and the chance of failure is lower.
Still, failure is extremely important. Don’t be too optimistic, and be honest with yourself.
The lifecycle
Idea, market fit, proof of concept, prototype, MVP. Then repeat, until your product is awesome.
The idea. Define the vision, the mission and the personas. Do a SWOT analysis and an atmosphere check. Then validate the product–market fit.
Idea validation. Understand what customers need. Do the maths: is it worth it? Estimate the customer lifetime value (CLV) and the return on investment (ROI). Find the first paying customer. Ask: would you pay for it? How much? And try the fake door technique: offer the feature or product before it exists and measure how many people click.
Proof of concept. Can the idea be built technically at all? Build it only for yourself, and make it super stupid.
Prototype. Demonstrate how the problem will be solved. A UI with a stupid, not fully implemented backend is fine. Fake it till you make it. And validate: test it with your customers.
MVP, the minimum viable product. It must solve the user’s main problem, it should be able to earn money, it doesn’t need to be pretty, and it must be deliverable fast.
To show what “doesn’t need to be pretty” means, I showed a real prototype of a warehouse tool: a plain Bootstrap screen with one search field for scanning an EAN code or a position, and an order detail page. Nothing more.
Delivery tips
- YAGNI, you aren’t gonna need it.
- Be creative with solutions. Nothing is too stupid.
- Challenge everything: Is it bringing any value? Do I really need it? Why am I doing this? Will it solve the user’s problem?
- Do things that don’t scale, the Y Combinator tip.
- Move quickly. But don’t make too much of a mess, or the technical debt catches up with you.
Plans and priorities
Have a short-term plan and a long-term plan, plus the steps to get to the long-term one. Those steps will change all the time, based on feedback. Know your customers. Keep to-do lists split into bugs, must-haves and nice-to-haves, and prioritise often, by time to delivery and cash potential.
I showed my own to-do list for MySpeedPuzzling, a very long one, and how a single page grew from feedback: the puzzle detail page got tabs for solo, duo and team times and a “time per puzzler” chart.
“Bloatware”: the Lego bricks
Every SaaS needs the same boring parts. Don’t build them from scratch, assemble them:
- Sign in, sign up, forgotten password: Auth0
- Access control (ACL)
- E-mail, transactional (Gmail) and newsletters: poste.io, listmonk
- Payments: bank transfer, Fakturoid, Buy Me a Coffee, Stripe
- Invoicing and billing
- File storage: MinIO
Technology
- Keep the number of technologies low for as long as possible.
- Simple architecture. KISS. DDD was crossed out on the slide.
- For styling, use Bootstrap or Tailwind, or buy a template.
- Don’t write it yourself if low-code or no-code does the job.
- Watch out for hidden costs, like CI runners and Sentry.
More tips
- Defensive, strictly typed programming. You won’t need that many tests. PHPStan will save your butt.
- Marketing over product!
- Social marketing can be very powerful.
- Open source can open many doors.
- Look for free tiers.
So where to start?
You need an idea to start. Validate the market fit. Build it. And validate all the time.
No idea? No problem: build a modular skeleton, the bricks above, so you’re ready when the idea comes.
All 33 slides
Related talks
- Save $$$ with Dokku · 2020
- Homemade AI chatbot: Symfony, RAG & OCR · 2026
- Continuous Deployment is the best! · 2022