Sometimes We Don’t Need Another Platform

Disclaimer: I create this content entirely on my own time, and the views expressed here are mine alone (not my employer’s). Because I love leveraging new tech, I use AI tools like Gemini, ChatGPT, Claude, Perplexity and others as a “digital team” to help research and polish these articles so I can share the best possible insights with you!

I keep running into the same problem. I need a small tool, but the available answer is often an entire software platform.

There was a time when you could download a small application, run it on your computer, and simply use it.

• No account.
• No monthly subscription.
• No onboarding sequence asking you to create a workspace, invite your team, choose a plan, and enter a credit card before you have even decided whether the application is useful.

Somewhere along the way, even simple software became complicated. I understand why.

Cloud applications solved real problems. They made software easier to update, allowed us to access information from multiple devices, enabled collaboration, and gave developers a better way to continuously improve their products. But I have started wondering whether we have taken that model too far. Sometimes I just need a tool. Does everything need to become SaaS?

Corporations and enterprise organizations will need to address this citizen developer organizations as they have sprung within the organziations like crazy (talk about shadow IT) See my other blog on this: The Enterprise Challenge of MicroApps

When a small problem becomes a platform

Suppose I want a simple way to keep track of people I meet.

I could subscribe to a CRM. But then I have a CRM.

There are pipelines, dashboards, integrations, automations, workflows, permissions, campaigns, reporting, and dozens of features I may never use.

What I actually wanted was much simpler:

• A person’s name
• Their company
• A few notes from our conversation
• A reminder to follow up
• A simple history of our interactions

The same thing happens with many small problems.

Tracking outreach.

• Preparing a weekly status report.
• Keeping notes about professional relationships.
• Organizing information that currently lives in a spreadsheet.

• Maintaining a small list that has become too awkward for a document but does not require an enterprise platform.

These are not necessarily problems that need a large software system. Sometimes they need a small application that does one thing well.

I do not need everything to be in Excel. Spreadsheets are incredibly useful, but they are often the default answer when there is no lightweight application designed for the specific workflow. Eventually, a simple spreadsheet can become a collection of tabs, formulas, filters, and manual processes that was never really meant to function as an application.

That idea led me to start experimenting with something I am calling MicroApps.

It is not a new concept. Small utility software has existed for decades. What has changed is that AI has revitalized the idea by making these focused applications much faster and less expensive to explore, prototype, and refine.

What I mean by MicroApps

My definition is intentionally simple:

A MicroApp is a small application designed to solve a specific problem without becoming an entire software platform.

The MicroApps I have been building are even more constrained.

They are single-page applications that run directly in the browser. There is no application server required to use them, and the information stays local in the browser unless the user decides to export it or move it somewhere else.

• There are no accounts to create.
• There is no subscription.
• There is no server to maintain.
• You open the application and use it.
• Those constraints are not limitations to work around. They are part of the design.

They force useful questions:

• What problem is this application actually solving?
• What information needs to be stored?
• What features are essential?
• What can be left out?
• Does this really need a cloud service and a user account?

For many small tools, the answer may be no.

Local-first changes the default

One of the things I find appealing about this approach is privacy.

Most modern applications begin with the assumption that your information needs to live somewhere else.

You type something into an application and, behind the scenes, it is often transmitted to a server, stored in a database, and associated with an account.

Sometimes that is absolutely necessary.

Collaboration requires shared access. Synchronization across devices is useful. Teams often need centralized reporting, workflow automation, governance, and controls.

But not always.

If I am keeping a small collection of contact notes, tracking a few outreach activities, or preparing my weekly status update, why does that information automatically need to leave my computer?

With a local-first MicroApp, the default is reversed.

Your information stays with you unless you decide to move it somewhere else.

That also means backup becomes your responsibility. Import and export capabilities matter. Moving to another device may require a deliberate step. Local-first is not automatically better for every situation.

It is simply a different tradeoff.

For many small, personal, or focused work applications, I think it is a tradeoff worth considering.

AI makes small software practical again

There is another reason I started experimenting with this now.

AI has dramatically changed the economics of creating software.

An application that might once have taken days or weeks to prototype can now sometimes be explored in hours.

That does not mean AI magically produces good software.

Someone still needs to define the problem, think through the workflow, test the application, find the edge cases, and decide what should—and perhaps more importantly, should not—be included.

AI does not eliminate product thinking.

But it does reduce the cost of experimentation.

For a long time, the economics of software encouraged builders to think in terms of platforms.

If software is expensive to build and maintain, it makes sense to pursue large markets, broad feature sets, recurring revenue, and products that can scale to many customers.

But if the cost of building and testing smaller applications continues to fall, another question becomes practical:

Can we build a very small tool that solves one annoying problem really well?

I find that question more interesting than I expected.

My first MicroApps

I have been using MicroApps for about 2 years now, but I have now made available four MicroApps to the public, which I have used for many things

That is precisely the point. They solve much smaller problems.

Small is a feature

The more I work with AI, the more I think constraints are becoming important.

AI makes it increasingly easy to add another feature.

And another.

And another.

Eventually, the simple application you started with becomes another complicated platform.

So one of the principles I am trying to maintain with MicroApps is this:

Small is a feature.

If the application solves the problem, perhaps it does not need much more.

That philosophy also extends to the business model.

I do not think every piece of software needs to become another recurring monthly charge. For certain small, stable applications, I am interested in exploring the old-fashioned idea of paying for something once and using it.

That model will not work for every kind of software.

Applications that depend on cloud infrastructure, shared collaboration, continuous synchronization, managed data, or ongoing services have different costs and different business models.

But a focused, local-first utility may not need to follow the same path.

I do not know yet whether that model will work.

This is an experiment.

Building in public

That is also why I am writing about it here. I have about a dozen microapps which I will be publishing.

The MicroApps are products, but the larger experiment is what I find most interesting.

What happens when AI reduces the cost of creating small, specialized software enough that we do not need every application to become a large SaaS business?

Could individuals and very small teams build useful software for increasingly narrow problems?

Could we see more local-first applications where privacy comes from the architecture rather than another paragraph in a privacy policy?

Could capable browsers, local computers, and AI-assisted development bring back a modern version of the small utility software many of us used years ago?

I think it might.

I am going to keep experimenting with the idea.

As I build more of these applications, I will share not only the tools themselves, but also what I learn about where this approach works, where it does not, and how AI is changing the economics of building small pieces of software.

Sometimes we do not need another platform.

Sometimes we just need a tool.