The End of Default SaaS: Enter MikroSuite

Local-first, fast, secure, and free software is a thing again.

I just released MikroSuite, my response to how we can bring back the good old days of software with fast, secure, usable, free programs which are local-first by design (when the problem space permits).

Today MikroSuite includes tools for writing, planning, drawing, team chat, meetings, analytics, uptime monitoring, logs, and product work — more apps are in the making. Some are local-first browser apps. Some are self-hostable team tools. Some are those tiny developer libraries all of this started with (more on the origin story below).

All the apps are MIT open source, free, and several of the apps can be run directly and securely in your browser (with typical, full transfer sizes of 30–40kb per app), no installation or download needed: All data is local to your devices and never reaches me. When you need to set it up yourself, the MikroSuite apps are meant to be efficient on minimal hardware and very easy to get going with.

Before telling you more, let me take you on a tour why I think this is an important direction in a rapidly changing market dynamic.

Non-productive productivity software

For the past year I’ve been travelling several times a week on high-speed, long-distance trains. I’ve been troubled by seeing many workers with their company-issued thick laptops running applications that look straight out of my adolescence 25 years ago.

Am I trolling? No, actually, this is in fact quite what it looks like. And I do see how they struggle with the train’s flaky internet, cutting them off in their meetings and in their work. I know have these issues! Just loading my web client’s job email inbox is ~20MB of transferred files. The number of times I’ve simply had to relegate reading email to when I am in the office are staggering, given that this is something that is a “given” in a modern workplace.

Isn’t it both amazing and depressing how these basic productivity needs aren’t yet satisfied, 40+ years after computing became a household thing? Certainly, I was thinking that we would be able to compute anywhere, anytime, in 2026.

Can’t we solve typical issues with better, faster, more expensive hardware, or e.g. better internet connectivity? Accepting that we are solving software issues with hardware (itself a bad idea), the answer is “sure”. But this is also what burns up our planet, or if nothing else, leads to stupid things like uglier games needing more hardware to run, compared to 10 years ago. So, no, practically speaking I don’t think it’s a real, workable answer, as there’s plenty of counter-points to make.

Common productivity needs are hardly extreme, nor are they (in absolute terms) that much more demanding generation-over-generation; think of e.g. word processing. The core of this solution space hasn’t changed. Complexity is raised by incredible amounts when you have to support an application across multiple platforms with millions of concurrent users (Slack etc.) versus something that has fewer surfaces, a tighter value prop, and much fewer users — your users, the people you work with. But you don’t need Slack’s engineering team to run something that in all essence is nearly the same thing, but at “your-company-scale”.

That reflection is red-hot today, yet it’s as old as the first computers.

The one-way exit and origin of Mikro

When I began my “big American exit” with the massive Phaset refactor in early 2025, it was — at first — an overwhelming period of negative emotion, as I understood there were no real options out there that satisfied me, in terms of fulfilling the various AWS service-sized holes that littered Phaset.

One of the blind spots I came to truly understand better was the overall dependence on American SaaS for practically everything. And it’s not just me, it is how the market is rigged right now.

The market for open source and/or European tools was, and is, indeed quite sad: insert any combination of ugly design, old legacy code, fat app sizes, poor functionality, etc. For example: in terms of managed “magic link” (email-based authentication) services — like you’d find with Google Firebase Auth or Auth0 — this is practically nowhere to be found in the EU. Interesting, as this is not an extremely hard problem to solve.

I guess the industry just grew lazy? I am well aware of trying to optimize for what an organization is built to do, not for it to rebuild its scaffolding every day. But this is a compounding problem: If no one, ever, adds solutions to reshape the dynamic, then you cannot be surprised that you are effectively locked-in… or locked-out.

Worse, finding a solution would still leave me in the same power dynamic: offloading simple work at a high cost to someone else. The “default SaaS” world is one in which we don’t even consider the price of admission any longer, yet the prices just keep going up.

The right way, the hard way

I didn’t want to destroy Phaset. It was architecturally sound and a solid product, but I understood I had to resort to more extreme ways, replacing a ton of AWS services with self-built alternatives.

Doing that, I inadvertently created the birthplace of the Mikro family of products: extremely small, self-contained pieces of functional libraries for developers. Using these, you could do things like run file-based databases, do event-based communication, or send emails. All at tiny sizes, typically measured in the single kilobytes when imported into your application.

Why go through this immense hassle? Well, quite simply because when the core plumbing is in place I could infinitely reuse it. My bet was that it would pan out as my own infrastructural layer: where managed services existed before, there would now be Mikro-family solutions. And I would have no one to thank or ask for free credits when the bill went up.

Later, this insight would form the core instinct for the overall MikroSuite, but applied to everyday computing.

In my case, the angle I started with last year was team chat. In this space there are quite a few options. At work we use a “more secure” American chat I was mildly dissatisfied with. And the open source options exist but are often more platform-oriented (such as Matrix). However, in short, nothing really stood out as a simple chat application that followed the design criteria I was looking for.

Functional minimalism

So what are those design criteria? The below is not exhaustive, but gives a sense of how I’d approach the core values of building almost anything. My fairly absolute beliefs are:

• What you can do with less is better than doing it with more.
• Small is easier to understand and reason about (doubly more relevant in the tokenmaxxing era).
• There should be minimal reason to keep people waiting, for any reason.
• Software respects the user’s integrity.
• Tools are used by people; let them do their work without wanting to break the screen, for any reason.

We could call this “functional minimalism” if you want to put a name on it. Surprisingly little out there in software follows that design direction.

Make Software Great Again

Let’s recap my arguments and story so far:

• There are exceedingly few good (if any) options to the American SaaS hegemony, depending on the segment you are looking at.
• The mental barrier to leave the “default SaaS” world seems to be very high; I don’t think this is just actual de facto lock-in, it’s also acting as a pacifier in the mouth of needy consumers.
• Most things we are truly dependent on in general computing are somewhere between “trivially” to “moderately” complex, and should not be a cause for concern in terms of rebuilding (if that would be needed).
• A lot of general-purpose tools no longer exists in modern, lightweight, local-first alternatives.
• Small software is, broadly speaking, “better” as it’s auditable, portable, understandable, and works in adverse conditions — more common that many want to accept.

The way we defaulted to SaaS for everything is changing, for e.g. economic reasons (constant price hikes), competition reasons (actors starting to become oligopolies), and for geopolitical reasons (weakening trust and transnational issues with data collection). A lot of our dependency issues ultimately boil down to relatively simple products that all can be moved from cloud-based, massive SaaS environments into something that you run on basically a potato at zero-to-negligible cost.

Caveat emptor: For truly complex, global, domain-specific, “hard” problems I think there will always be a need for specialists providing options — SaaS or otherwise. That’s a whole different game and out of scope for my arguments here.

I understood that this was a concrete, actionable problem space I wanted to provide some input to, if just to some degree. That solution is MikroSuite.

MikroSuite is not nostalgia — in fact, it embraces the web as a fantastic runtime platform to deliver software. It, however, also strongly rejects bloat, lock-in, surveillance, subscription fetishism and “you are the customer” incentives that has damaged this great platform for decades.

The point of all this is to prove that the common 80% of everyday work software can be dramatically smaller, faster, cheaper, more private, and easier to reason about. We can build software that is small enough to understand, fast enough to work in almost any condition, that is private by default, and useful on any conceivable machine. That is my bet.

Feel free to join in on improving the apps in the MikroSuite as well as suggesting new additions to the family.

Let’s make software great again.