Skip to content

Micro-SaaS: How to Build a Small, Profitable SaaS Solo

Micro SaaS explained by a European developer: what one person can build, run and support, the math behind it, EU VAT basics and seven steps to start.

By

Freelance full-stack developer

Published
Reading time
12 min
In this post9

A micro SaaS is a small software business that one person can build, run and support, usually serving a narrow niche with one specific problem and no investors involved. It turns a profit by keeping scope, support and fixed costs so low that a few hundred paying customers, sometimes far fewer, add up to a solid income. You need less code than you'd expect, and more discipline about what you leave out.

I am a freelance developer based in Denmark. Most micro-SaaS advice is written from a US point of view, so I also cover the European parts it tends to skip, like EU VAT and data processing agreements.

The short answer

A micro SaaS sits somewhere between a side project and a startup. The goal is a profitable business you can run yourself, not growth at any cost.

Micro-SaaS vs. venture-style SaaS
Micro-SaaSVenture-style SaaS
TeamYou, plus occasional paid helpA team that grows with revenue
FundingSavings or income from other workUsually investors
MarketA narrow niche you can reach directlyA broad market
How customers buySelf-serve: sign up and pay onlineOften demos, sales calls and contracts
What success looks likeSteady profit and a few hours a weekFast revenue growth and market share
TechOne codebase, familiar tools, managed servicesSpecialists and more infrastructure

Here's my rule of thumb: if you can't say in one sentence who the customer is and where you'll find the first 20, the idea is too broad for a micro SaaS. The overall path from idea to paying customers is the same as for any software product, and I've laid it out in my complete guide to building a SaaS. This post covers what changes when you're the whole team.

What one person can realistically run

One person can absolutely run a SaaS, but only if it's designed for that from day one. The hard part of going solo is rarely the code. It's everything that keeps going after the code ships:

  • Support: how-to questions, password resets, bug reports and feature requests.
  • Billing: declined cards, refunds, invoices that need a VAT number added.
  • Maintenance: security patches for your framework and packages, and third-party APIs that change under you.
  • Operations: backups, monitoring and the evening your server goes down while you're at dinner.
  • Marketing: nobody finds the product on their own.

Most developers underestimate the last one. A good product nobody hears about earns nothing, and you can't automate marketing the way you automate backups.

The good news is that the rest can stay small. One product with one clear workflow generates fewer support emails. Familiar tools mean fewer surprises when you update. And a payment provider that also handles tax removes a whole category of admin.

Before you start, ask yourself one question: how many hours a week can I give this product for the next two years, including the boring weeks? With a full-time job, it might be 5-10 hours. That means the product has to survive a busy month, a holiday or a week of flu without you touching it.

Do the math before you write any code

Two things decide if the numbers work: how many customers you need at your price, and what selling in Europe adds on top.

Customers, prices and fees

Start with the income you want and work backwards. Say you want the product to bring in €4,000 a month, before fees, fixed costs and tax.

Paying customers needed for €4,000 a month (example, excluding VAT and fees)
€9/month€29/month€79/month
Customers neededabout 445about 138about 51
Typical buyerIndividual or hobbyistFreelancer or small teamBusiness with several users
Support load per euro of revenueHighMediumLow

Payment fees come out of that revenue. Stripe charges 1.5% + €0.25 per standard EEA card payment according to Stripe's pricing page for Ireland, and Stripe Billing adds 0.7% of billing volume on the pay-as-you-go plan. Paddle, a merchant of record that sells on your behalf and handles VAT and sales tax, charges 5% + 50¢ per transaction. On a €9 plan, Stripe's fixed €0.25 alone is close to 3% of every charge.

Then there's churn, the share of customers who cancel each month. Lose 3% a month and, with 100 customers, you need three new ones every month just to stand still. That's why I nearly always suggest selling to businesses rather than consumers. You can charge more, you need fewer customers, and a tool that has become part of a team's weekly routine tends not to get canceled on a whim.

The EU overhead most guides skip

If you sell from the EU, or to EU customers, a few rules kick in early. None of them are hard, but they're cheaper to set up before launch than after.

  • VAT on consumer sales: once your cross-border sales of digital services to consumers in other EU countries pass €10,000 a year, you charge VAT at each customer's local rate, usually reported through the EU One Stop Shop (OSS) in one quarterly return. Business customers with a valid VAT number are normally handled through the reverse charge instead. A merchant of record takes all of this off your plate.
  • Data processing agreements: when companies store their customers' or employees' personal data in your product, you're usually their data processor under GDPR. That means a data processing agreement and an up-to-date list of your own sub-processors, such as hosting, email and error tracking. My GDPR checklist for SaaS covers the technical side.
  • Invoices: business customers in Europe expect proper VAT invoices with their company details. Make sure your billing setup produces them without you editing PDFs by hand.
  • Data location: European buyers often ask where their data is stored. EU hosting won't answer every question, but it makes the conversation shorter.

I compare Stripe, Paddle and the alternatives in more detail in my post on subscription billing for SaaS. None of this is tax or legal advice, so check your setup with an accountant.

How to build a micro SaaS on your own: steps 1-3

The first three steps cost almost nothing and save the most wasted months.

  1. Pick a problem you know from the inside. Good micro-SaaS ideas usually come from an industry or job you know well, where you've watched the same manual task get handled in spreadsheets, on paper or across five tools that don't talk to each other. You understand the problem, and you know where the customers hang out. A narrow niche is an advantage here: it's cheaper to reach and often too small to interest bigger players.
  2. Validate with money, not compliments. Talk to 10-15 potential customers about the problem before you show them a solution. Then ask the most interested ones to pre-pay or sign up for a paid pilot. If nobody will pay, you've just saved yourself months of work. I cover the methods in my guide to validating a SaaS idea before you write code.
  3. Cut version one down to a single workflow. Write down the one job the customer needs done, start to finish, and remove everything that isn't needed to get them the result. No mobile app, no integrations with five systems, no fine-grained permissions yet. My post on scoping an MVP shows how to sort the wish list.

If you can't code it yourself

Once the idea is validated and scoped, the next question is who builds it. The micro-SaaS model assumes you can build and maintain the product yourself. If you can't, you have four realistic options:

  • Learn enough to build it. It takes time, but you keep full control and skip the development bill.
  • Build a prototype with AI or no-code tools. That's fine for validation, but authentication, keeping customers' data separate, billing and security are exactly the parts that tend to go wrong.
  • Hire a freelance developer to build version one at a fixed price. Then the math has to work. If version one costs, say, €15,000 and the product earns €1,500 a month after costs, it takes ten months to earn the build back, and maintenance comes on top. My breakdown of what an MVP costs to build shows what drives that number.
  • Find a technical co-founder. You'll share the profit, but also the work and the responsibility for keeping it running.

My honest advice: if your budget can't cover both version one and a year of maintenance, validate with a prototype first, or deliver the service by hand to your first customers. A developer like me is most useful once you have pre-payments or paying pilots and a clearly defined scope.

Steps 4-7: build it so one person can run it

Even if someone else builds version one, you're the one running it afterwards. These four steps keep the product from needing you every day.

  1. Use tools you already know. When you're alone, your time is the scarcest resource, so this isn't the moment to learn a new framework. One codebase and a framework with authentication, queues and email built in saves you a lot of decisions. I usually reach for Laravel for this kind of product, but the right choice is the one you can debug late at night without looking up the basics. Skip microservices, and pick managed hosting so server maintenance isn't your job.
  2. Let someone else handle payments and tax. Choose between a payment provider like Stripe, where VAT and invoicing are on you, and a merchant of record like Paddle, which costs more per transaction but takes over the tax side. If you sell to consumers across the EU, a merchant of record is usually worth the extra fee.
  3. Automate operations from day one. That means backups you've actually tested restoring, uptime monitoring that alerts you, error tracking so you see bugs before customers report them, and automated deployment so a fix doesn't depend on a checklist in your head. Block out time each month for framework and package updates, because a year of skipped updates is expensive to catch up on.
  4. Design support out of the product. Every question you get twice points to a gap in the product or the help docs. Write short help articles, make error messages say what to do next, and let customers update their card, download invoices and cancel on their own. Promise email replies within one business day rather than live chat. That's a promise you can keep alone.

When to pick a different model

Plenty of ideas fit the micro-SaaS model, but not all of them. Pick a different model if any of these apply:

  • You need a full salary within six months. Small SaaS products usually grow slowly, and there's no guarantee they'll get there.
  • Customers only buy after meetings, tenders or long pilots. Your hours go into selling instead of the product.
  • The product handles sensitive data such as health records, or your customers' operations stop when it goes down. That's too much responsibility for one person with no backup.
  • The product only works with lots of users on both sides, like a marketplace. That typically takes a marketing budget and a lot of patience.
  • Every customer wants their own version. Then you're running a consultancy with a SaaS invoice.
  • You don't enjoy talking to customers. Support doesn't go away, it just gets smaller.

And an honest note about me: if you're a developer with the time to do it, you don't need someone like me. Build it yourself, keep it small and spend the money on finding customers.

Next steps

Run through this checklist before you write the first line of code. If you can't tick off most of it, that's where your time should go right now.

Before you start building your micro SaaS

  • Customer: you can describe them in one sentence and know where to find the first 20.
  • Problem: at least ten potential customers have confirmed it, and some have pre-paid or agreed to a paid pilot.
  • Math: you know the price, customer count and monthly costs needed to hit your income target.
  • Scope: version one covers a single workflow, start to finish.
  • Tools: you're building with a stack you know, on hosting where server maintenance isn't your job.
  • Payments: you've chosen between a payment provider and a merchant of record and know how VAT is handled.
  • EU basics: you have a data processing agreement ready for business customers.
  • Operations: backups, monitoring and error tracking are in place before the first paying customer.
  • Time: you know how many hours a week you can give the product, two years from now too.

If you need a developer for version one, here's how I approach SaaS development for founders: a paid fixed-price discovery phase first, then code you own from day one.

Frequently asked questions

How much money can a micro SaaS make?

Anything from nothing to a full salary or more, and there's no reliable data on what a typical micro SaaS earns. Revenue is price times paying customers, minus payment fees, hosting and tools. Many small products never earn more than they cost to run, and the ones that succeed usually grow over years rather than months. Set a concrete target and work backwards, so you know how many customers it takes.

Can I build a micro SaaS while working a full-time job?

Yes, and it's less risky than quitting first. Read your employment contract before you start, though. Some contracts require approval for side work or give your employer rights to what you build, especially if the product is close to your day job. Build on your own time and your own equipment, and ask an employment lawyer if anything in the contract is unclear.

Is a micro SaaS passive income?

No, not quite. A micro SaaS can get down to a few hours a week, but it always needs support, security updates and attention when a third-party service changes. Leave it alone for a year and you risk security holes, failed payments and customers quietly canceling. Think of it as a low-maintenance business, not money that arrives on its own.

Can I sell to US customers from Europe?

Yes. Stripe and Paddle both let you charge in US dollars, and self-serve products don't care much about time zones. The catch is sales tax: US states set their own rules for digital products, and some apply once you pass a certain level of sales in a state. A merchant of record handles this for you. If you invoice yourself, check the rules with an accountant before US sales grow.