Personal Apps: When JavaScript and SQLite Are All You Need

The Challenge

AI is changing how professional software gets built, and our industry is still working out what that means. But I think the bigger shift lies elsewhere: not in professional development, and not in vibe-coded apps that try to follow today's software development model, but in a new category I'll call personal apps: software built around one person's needs. They might support a hobby, simplify a daily task, or solve a work problem.

Zoom

What happens when anyone can build software? How do they build their software? What guardrails do they need? How do we run each app without putting other apps or their data at risk? Where does the data live? How do we potentially run hundreds or thousands of these apps, and how do we keep infrastructure costs in check for apps that may have little long-term value?

JavaScript and SQLite Are All You Need

For personal apps, today's software stacks are overkill. Yes, you need a database, but do you need a global database with distributed transactions when you just want to collect information from friends? Yes, you need to run your logic, but do you really need a full Linux environment when you just want to do some calculations and update a work dashboard?

Over the past months, I've been testing how far you can get with just JavaScript/TypeScript and SQLite as a local database. The answer is: surprisingly far. And here are three examples:

Examples

Bonn Tonne

Bonn Tonne (https://bonn-tonne.applet.works/) (source code (https://github.com/applet-one/examples/tree/main/bonn-tonne)) turns Bonn's official waste-collection dates into a personal schedule for your address and bins, which you can also subscribe to in your calendar. It needs no user accounts: preferences stay in the browser's localStorage, while calendar subscriptions are stored in SQLite behind an unguessable feed URL.

Zoom

Daybreak

Daybreak (https://cobaltsparkling-puma.applet.works/) (source code (https://github.com/applet-one/examples/tree/main/daybreak)) helps friends share availability, find overlapping free time and arrange meetings; accepting a request reserves the time for both people. Unlike Bonn Tonne, it implements user authentication itself: registration, login and logout, with salted password hashes and cookie-based sessions whose tokens are stored hashed in SQLite. Users, sessions, friendships and schedules all live in one SQLite-backed Durable Object, without a separate identity service.

Zoom

Quote-Assist

Quote-Assist is an internal prototype for helping a sales representative turn customer inquiries into quotations, bringing relevant information together and highlighting what still needs clarification. The representative stays in control of decisions and customer communication. It illustrates how a personal app can support a focused work process alongside existing business software.

Zoom

As a tinkerer, I like having a full language like TypeScript at my disposal and, with SQLite, a familiar database interface. I grew up with both technologies and am fairly productive with them. Now, this turns out to be true not only for me but for many others. But more importantly, the current generation of LLMs excels at them. They have been trained on millions of lines of TypeScript and have seen SQLite more than enough. With a little back-and-forth, they generated all the examples. And if you provide the right guardrails and context, you can often one-shot them. It's amazing, and I believe this could be the sweet spot for many, many other applications.

But having a simple application model is only half the story. How do we actually run these apps? Do we need to build entirely new infrastructure to support them? Fortunately, much of that infrastructure already exists, both in the cloud and on our own servers.

Durable Objects

A couple of readers will have recognised this stack. Others have been poking around with this model for quite some time. Cloudflare's Durable Objects are the most prominent example.

Cloudflare introduced Durable Objects in 2020, giving its JavaScript Workers durable storage. Their implementation is remarkable and worth a deep dive, but it gives me what I need: a way to run JavaScript or TypeScript on their V8 runtime and store data in SQLite, backed by their object storage R2. They also introduced me to a new constraint: single-threaded access to the database. So far, I am quite happy with this constraint, and I believe this constraint will lead to a simpler operational model.

But what makes the idea behind Durable Objects really interesting is a project by Ryan Dahl (the creator of Node.js) called celld (https://celld.dev/). In essence, it's an open-source implementation of Durable Objects that uses some of the same underlying technologies, like V8 and object storage, but runs completely on your own infrastructure. Again, that's a topic for another deep dive. But we now have the basics to run these apps on our servers, a hard prerequisite for many organisations to even consider them.

Zoom

If you want to play around with celld, have a look at celld-ctl (https://github.com/applet-one/celld-ctl), which provides a single-server control plane and lets you start building these personal apps we talked about on your server within 15 minutes.

Why This Works for Personal Apps

OK, so the promising part is the combination: a simple application model that LLMs can work with, and existing infrastructure to run it, in the cloud with Durable Objects or on our own servers with celld. That's not a complete personal-app platform, but it means we don't have to build the runtime and storage infrastructure from scratch. So back to the original question: Could this combination be the basis for building these personal, one-off applications?

First off, they are easy to generate because LLMs understand JavaScript or TypeScript and SQLite very well. You'll be amazed at how far you can get with today's models.

They're isolated by default: each app runs in its own V8 isolate with its own SQLite database, so a buggy or malicious app can't reach into another app's code or data. They're easy to operate because logic and state are encapsulated together. They're easy to scale: each instance is independent and, more importantly, can scale to zero when nobody is using it. Which, let's face it, will be true for many of our one-shot applications. Also, Cloudflare's very generous plans let you run many of these apps basically for free.

And they're powerful enough. My hypothesis is that this could cover around 90% of personal apps, both for private use and at work.

Where This Model Reaches Its Limits

So where does this model fall short? First, cross-communication between different apps isn't built in. I suspect many enterprise architects will bring up use cases that require some kind of distributed transaction across multiple apps. Also, you might argue that your application might not fit neatly into a small, isolated runtime. I would argue these constraints are a feature when you want to build and operate many of these applications.

So I guess the bigger question is what challenges emerge when we move from a handful of personal apps to hundreds or thousands. How do we know what's running? Who is responsible for these apps? How do we ensure they follow organisational standards without losing the simplicity and freedom that made them attractive in the first place?

These are questions we are actively exploring, and I'd love to hear your thoughts, questions and concerns. Where do you see this model working, and where would it break down?

More soon

Finally: We'll be discussing this model and the follow-up challenges in my upcoming talk at AI DevCon (https://tessl.io/devcon) in New York: Software Factories for the Software of One (https://tessl.io/speaker/matthias-luebken). Hope to see you there!