What a micro-SaaS is
Micro-SaaS is not a technology, it is a decision about scope: a web application that covers a single workflow completely, instead of many workflows halfway. One main screen people work in every day, two or three roles, one export that satisfies somebody outside the system. Everything else is left out.
What separates it from an internal spreadsheet is operations: logins, permissions, backups, a traceable history, updates. What separates it from a large standard system is what is missing – and that the missing part is deliberate.
Because the scope stays small, the decision stays small too. You can build a micro-SaaS, use it for a year and switch it off again without a company depending on it.
When it beats the spreadsheet
As long as one person maintains the file and nobody audits it, the spreadsheet is unbeatable. It costs nothing, does everything and is already there.
It tips over in three places. First, with several editors: from the second person onwards you need permissions and one state everybody refers to. Second, with evidence: when someone wants to know who changed a value and when, a version number in the filename won't help. Third, with retyping: when the same number is moved by hand more than once, you pay for it every month – just never as an invoice.
A workable test: count the minutes per week someone spends moving data from one place to another or correcting it afterwards. Multiply by a year. That number is the budget worth discussing.
When standard software is the better answer
If your process is the same as in a thousand other companies, buy it. Payroll, point of sale, bookkeeping, classic CRM: there are mature products with ten years of regulatory change behind them. Paying for that work a second time is expensive and risky.
Building your own pays off where you deviate from the norm – and the deviation is your business. Usually you notice it because the standard system runs fine, but every month an export ends up in a spreadsheet where the actual work happens.
Often the right answer is both: standard software for the ordinary part, a micro-SaaS for the deviation, and an interface in between.
What running one actually takes
Building is the smaller part. Afterwards comes everything that keeps software alive: updates for runtimes and libraries, backups that can actually be restored, monitoring, fixing what breaks, adapting to rules that change.
Then there are the duties nobody thinks about at the start. Who may see which data? How long is it kept? What happens when an employee leaves? Where does the data sit, and who can hand it over when somebody requests access to it?
That is why operations is a separate, monthly, cancellable item with us instead of a footnote. Whoever leaves operations out of the first quote has only moved it onto your side of the table.
How we go about it
First we cut. Out of everything your process contains, we shape a version that serves one core path completely – plus a list of what deliberately isn't part of it. That list matters as much as the feature list, because it sets the price.
Then we turn it into a clickable prototype, so you can see whether we understood you. Only once that holds do we produce the binding estimate for the build. Code and rights transfer to you on payment; whether we run it afterwards is a separate decision.
You can try the first step right here: describe your process in one sentence and the sketch will show you an interface, a data model and a roadmap for a possible product. A sketch, not an offer – but an honest start.