Apps at the Speed of Need

I've got a pet project on the back burner that I'd kind of lost the thread on; I'd scoped it months ago, sketched the screens on paper, and built part of it with a coding agent before life pulled me elsewhere (and before the whiskey collection made me organize it). When I picked it back up, I handed the entire thing to Fable 5 (because why not give it a try - also: wow, just wow) and asked it to revisit what I'd built, rescope what was left, and get us realigned.

It did. (And again: wow.) It produced a multi-step plan across a sprint, that plan went to Claude Code running Opus 4.8 to build against, and inside the application itself, Qwen handles the generative work on my own hardware. By the morning the backend was fully tested and deployed, and I was frontend-ready.

Four different roles were involved in accomplishing that work, and three of them were models. I was definitely the fourth.

For most of my working life, there was a middle layer between the design work I do and any other function I needed handled when creating digital products, unless I taught myself to do it (which I frequently have). I needed someone to build the database, and then to connect to it and make the results display in the design. More recently, someone else built the software and if you needed or wanted to use it, you rented that middle layer, and those were the only two options (unless you had the rare capability to build it all yourself).

That middle layer of renting software is thinning fast. Now, with a single tool, anyone can write prompts that attempt to create apps. The catch, and it's the whole catch, is that the middle layer's disappearance hasn't made the work disappear. Being good at Figma never made anyone a good UX designer, and a subscription to a frontier model doesn't make any of us good writers, coders, or product teams. The functions required for success still need to be accounted for and the difference is that now we're the ones accounting for them.

After making this AI learning and exploration effort my second full-time job for the better part of a year, I barely put thought into who did what. My approach to routing has become instinctive. I scoped and decided and course-corrected, Fable planned and orchestrated, Claude Code reviewed, ingested the requirements, and delivered, and Qwen ran the tests that validated what the daily load would work like in production. Each did the job it was best suited for, if not perfectly. The handoffs happened without much ceremony, and maybe just a little copy and paste, and approving a lot of command-line prompts.

That division of labor wasn't new, especially when you take a look at any sort of software development lifecycle. I've been working this way through every app I've built this year and I've been circling it in these articles without landing it cleanly.

It's bugged me for quite a while, and I think I can finally name it.

Nearly Everything I Created Could Have Been a SaaS Pipe Dream

As a colleague told me recently, I've been burning the midnight token a lot lately, and the list of applications in my wake is admittedly a bit of a #humblebrag. From the coffee profile application to the spirits catalog to the workout creator application, the conference tools, the expense report tool, the audio and video creation tools, 5 Minute UX, The Feed & The Thread, Patterns and Signals, a couple of research tools, and on and on. I'm sure most of them could have been packaged, priced, and sold, or I'm at least sure that someone, somewhere, would have tried to.

And I get that. Most people are spending their own hard-earned money on inference for both building and maintaining, and those costs can get out of hand, especially when you're the founder and the investor and it's all the same wallet.

The thing is, though, I've been building software that fits one person exceptionally well, and doing it fast enough that the economics only make sense for that one person. These apps wouldn't have justified their existence five years ago. The cost of building them was too high to spend on an audience of one, and that cost has collapsed. In 1999, so many of these projects would have required special hosting configurations, a 1-2 pizza team, and a coordination of shared time to pull things together. The removal of those barriers changes what's worth the investment of building.

And, look, I get it: that doesn't sound very human-centered at all. That's not really the case; I don't know that I can even attempt to step away from doing the thing that I've been doing for decades. Anything with a publicly exposed interface still gets thoughtfully built, validated, and tested with real people, even a few begrudging friends. I can't switch it off. We've all got that one friend who's a little tired of being shown the next new project. I'm usually that first friend - the one with the annoying new project.

While I definitely think that what we currently see as SaaS likely isn't going to stay the same, I don't think it means that SaaS dies.

I mean, c'mon. I've heard that Design is dead at least 3 different times this year alone.

I do think it means SaaS stops being the automatic answer to "I have a problem, is there an app for this?" I think we're getting much closer to what I've frequently cited as "Apps at the speed of need" because more and more frequently, I've seen something that I've thought "Can I build that? I bet I can build that. Let me try that." and then before the morning is done I've got a knock-off NotebookLM Short Video Explainer MVP and I've saved a Vision document for future exploration.

So yeah, apps at the speed of need, and we each become our own small IP farm, and enterprises are heading in that direction, too. We no longer need the majority of subscription services when we can create what we need when we have the infrastructure in our clouds or in our basements.

Compounding Infrastructure

Every project I've worked on, from the first RAGs to the spirit collection, leaves new capability behind. Spirit Spy needed to read text off a curved label, so it got optical character recognition that's now available to the next project. Spirit Spy also needed web enrichment, and we pulled from research tools that had left behind search and retrieval. The design language, the deployment pattern, the local inference setup, and the data conventions have all been built up steadily since the beginning (and learned through some hard failures), so each app hardens a little more of the foundation.

Whatever the next project might be won't start with a blank slate at this point, and frankly, that'd be a failure on my part. It will start with a foundation built from everything the previous projects learned, added, or adjusted. That's an economy of scale, and it only grows. Last night's project deployed a non-trivial backend in an evening because almost nothing about it was new except the domain.

I'm noticing a small shift in my own language that captures what this is. It's still exciting to say "I built an app" from time to time, however, the framing that I'm starting to view this all through now is "I extended my infrastructure." The app is almost an emergent property of the platform underneath it. Through some mix of happenstance and unconscious planning, I've built the platform well enough that new apps feel like routine extensions of it. It's the point where the map and the territory start to meet.

Inference Architecture and the Division of Inference Labor

Twenty years ago we learned not to put every workload on the same server. Well, some of us did. I've been learning that for the better part of the past year, which is why I now do things like "fleet management" and have things like "network topology" that I seem to reference more than I'd thought possible. This is, of course, good hygiene if you're going to head down this path of local inference. It's also a thing you don't have to consider all that much if you're subscribing to frontier models and those do all of that thinking, balancing, and overall heavy lifting for you, and all at the price of an ongoing subscription that has limits.

The lesson that I'm learning now is not to put every workload on the same model, or sometimes not even on a model at all.

Some work needs frontier reasoning: the planning, the hard architectural decisions, and the orchestration. Some work needs to really know how to weave code together, how to test and validate code, understand design systems, work with compliance as part of the output, and commit it all. Some work needs a capable local model running cheaply and constantly: reading labels, extracting metadata, generating and refining content, and all the other things that fall into daily work that is essential, yet still, work that keeps you away from doing the more creative and expansive endeavors. Some work needs no model at all, just plain deterministic code that saves, validates, and syncs without a shred of intelligence, because intelligence would only make it slower and less reliable.

And above all of it sits a person deciding what good looks like. Someone who orchestrates the orchestrator, watches the watchers, and ensures that we stay the heck away from Gas Town.

Last night's four roles were exactly that: I was there for judgment and scope, a frontier model was activated for planning, a coding agent executed for delivery, and a local model was engaged for the generative load. I never once considered asking the expensive reasoning model to do the OCR, and I definitely wasn't going to ask the local model to rewrite the strategy.

The work went where it belonged. And that's the important piece here: I was choosing which inference made sense for how I needed the work to flow.

The Blueprint Outlasts the Build

I've noticed that since I've been working this way, the app stopped being the valuable artifact. Apps are great; I still love creating something cool and useful, regardless of whether it's just for me. That said, the infrastructure has become so much more durable than any single thing built on it, and the plan that describes the app is more durable than the code that implements it.

And that's why I keep sharing product requirements documents (PRDs) instead of dropping links to github repositories. A repo is a finished build that someone has to trust, inspect, and maintain in an environment they may not control.

A PRD is a blueprint. You build your own version from it, with your own tools, in your own environment, on your own hardware, and you adjust, reduce, or improve it as you go.

The code is disposable. The blueprint compounds, the same way the infrastructure does.

The Last Subscription

The most valuable thing I built this year wasn't any of these projects. It was the infrastructure underneath them, and the realization that I've been LEGO-building foundational blocks until connecting the next app became routine.

I've told myself a lot of times that in my career I'm a pattern detective, and in this case, that pattern is the point. Creating apps at the speed of need isn't magic, and it most certainly isn't a one-shot prompt given to a companion that miraculously cranks out a billion dollar business overnight. (Just ask all of your billionaire AI buddies. You don't have any? Me, either!)

Apps at the speed of need are what happens when you invest in a foundation that compounds and divide work across the right mix of people, frontier models, local models, and plain code. Get those right, and building a small piece of software that fits one person exceptionally well stops being a project and starts being an evening.

Maybe that means that the definition of what it means to be an enterprise is getting a lot more local, and quickly. Well, if that isn't just in-the-middle-of-writing-this-piece thinking showing up out loud, I don't know what is.

I'm not here to pronounce the death of SaaS. I'm definitely SaaS-averse, especially given what I see in front of me and how I'm working today. SaaS isn't the default anymore, and I don't think you'll get far trying to sell something built from a prompt and a design-tool subscription. When you're charging a monthly fee for something you spun up in an afternoon, without much thought to whether it's safe, secure, or meaningfully different, that isn't a business. It's not entrepreneurial. And you're not a founder.

For me, and possibly for many of you, it seems like the default is becoming: I have a problem, and I have the infrastructure to solve it myself.