Lots of good software businesses start small. One person, or a tiny team, solving one specific problem for one specific group of people, and charging a fair monthly fee for it. That's micro-SaaS. It doesn't need venture capital or a big team. It needs a focused product, built well, and put in front of real users quickly.
I'm Aldrian, an independent developer in the Philippines. I help founders, consultants and business owners turn software ideas into working products.
I ship my own products
I don't just build for clients. I've designed, built and launched my own products:
- Ghostly, an end-to-end encrypted chat app with self-destructing rooms, built entirely on Cloudflare. It's live, free and installable as a PWA, and it scored 99 for performance in Lighthouse when I measured it.
- Jibong Purr-tection, a free WordPress security plugin approved and listed on WordPress.org, with a firewall, malware scanner and two-factor login.
Shipping your own products teaches you what really matters in a first version, and what can wait.
What an MVP should include
A minimum viable product is the smallest version that solves the core problem well enough that people will use it, and ideally pay for it.
The one core feature
The thing your product does better than anything else. Built properly, not half-done.
Sign-up and sign-in
Simple, secure and fast. Email and password, magic links or social login, depending on your users.
Payments
Subscriptions or one-time payments through a payment gateway, with trials and a customer billing page where the gateway supports it. More on payment integration.
A basic dashboard
Where users see their data and settings.
An admin view for you
So you can see users, subscriptions and usage, and help customers when they need it.
A landing page
Explaining the product clearly, with a sign-up button and pricing.
The essentials
Password resets, email notifications, privacy policy and terms pages, error handling and backups. Unglamorous, but they matter.
What can wait
Teams, advanced permissions, integrations, mobile apps, complex analytics, dozens of settings. Most of these should wait until real users ask for them. A smaller first version launches sooner and teaches you more.
My stack for small products
- TypeScript and React for the app
- Cloudflare Workers, D1 and R2 for fast, global hosting with low running costs
- Supabase where its built-in auth and database fit well. See Supabase development.
- Next.js or React Router depending on the product. See Next.js development.
- Stripe, PayPal or local gateways for payments
- Transactional email for notifications
Serverless hosting means you pay mostly for usage, so costs stay low while you find your first customers.
How I work with founders
1. Sharpen the idea
We talk about who it's for, what problem it solves and how people solve it today. I'll ask hard questions, kindly.
2. Define the first version
A short written scope: the core feature, the screens, the must-haves and the list of things that wait.
3. Fixed quote
You know the cost before any work starts.
4. Build in visible steps
Live preview links as features land, so you can show early users and get feedback while it's being built.
5. Launch
Deploy, set up monitoring and backups and stay close as the first users arrive.
6. Iterate
Based on real feedback, we plan the next small version.
You own everything
Code, database, accounts, domain and payment gateway, all in your name. No lock-in. If you hire a team later, they can pick up clean, documented code.
Common mistakes founders make
Building too much before launching. Months of work on features nobody asked for.
Skipping payments. If people won't pay, it's better to learn early.
Choosing obscure tools. Mainstream, well-supported technology makes hiring and maintenance easier.
Ignoring security. User data deserves care from day one.
No plan to reach users. A great product still needs a way to be found.
Good micro-SaaS ideas often come from your own work
Many of the best small software products come from people who know an industry well. A clinic manager who's tired of a scheduling problem. An accountant who wants a better way to collect client documents. A logistics coordinator who built a spreadsheet everyone at the office now depends on. If you've solved a problem for yourself with spreadsheets and workarounds, other people in your industry probably have the same problem. That insight is often worth more than any feature list.
After launch: what to watch
Once your first users arrive, a few simple numbers tell you a lot: how many people sign up, how many come back the next week, how many start paying and why people cancel. I set up simple tracking for these from the start, so your next version is based on evidence rather than guesses.
What it usually costs
It depends on the core feature's complexity. A focused MVP is usually much smaller than founders expect, because we cut everything that can wait. You'll get a fixed quote after we define the first version.
How we'd work
- Tell me your idea and who it's for.
- We talk and sharpen the scope.
- You get a written scope and fixed quote.
- I build with preview links.
- We launch to your first users.
- We plan the next version together.
Let's build your first version
Tell me about your idea. I'll reply with questions and, once it's clear, a fixed quote.
