What if an app didn't have to fit everyone?

I've been wondering how much of the software I use I should be able to change myself.

Imagine a meal-planning app that almost works for your household. You cook for two most evenings, have the kids every other week, and want dinner leftovers to become tomorrow's lunch. You'd like the app to plan portions and groceries around that routine. Instead, you keep adjusting what it gives you.

What if you could explain that routine once and have the app change how it plans? A coding agent could work in the background, propose a change you can try, and save it if it suits you. Someone with a similar household might want to use it too.

Over the next five to ten years, I think we could start choosing consumer apps partly for how well we can adapt them. A company could serve needs it never planned a feature for, and customers could get a better fit without moving to another product. The company would still have to keep those personal versions working.

That would change a familiar product decision: how many different needs can we serve before the product becomes too complicated?

A feature for a few people doesn't have to reach everyone

Product teams have good reasons to turn down useful requests. Each one competes for development time, adds something to maintain, and may introduce choices other customers don't need. A request can be entirely reasonable and still be wrong for the default product.

User-made changes could loosen that tradeoff. A small group could get the behavior they want without adding another option to everybody else's screen. The team would decide which parts of the product can change and provide reliable ways to change them. It wouldn't necessarily have to design each variation itself.

Settings, templates and plug-ins already offer some of this freedom. If an existing setting solves the problem, there's little reason to generate new code. The more interesting possibility is a change the company hasn't anticipated, made by someone who can explain what they need but couldn't build it themselves.

The cost wouldn't vanish. It would move partly into checking changes, keeping them compatible and helping people when they fail. For this to be a better business, that work would have to be reusable across many variations. If every personal version needs its own support team, cheap code hasn't solved much.

Why keep the original app?

If software gets easier to make, we could also have many more small apps, each designed for a particular group. Why customize an existing product when someone could build exactly what you need?

For a small, self-contained tool, that may be the better answer. A good default can spare people the effort of explaining what they want. A focused app can also make choices a general-purpose product will never make well.

For products we use over time, though, there may be more to replace than the screens. A saved recipe collection, household preferences, device connections or years of records can all matter. Moving to a new app means keeping what matters and checking that the new one handles it properly. Sometimes the only thing we wanted to change was one awkward part of an otherwise useful product.

In those cases, a company could give people room to change the experience while continuing to look after the records, connections and services they depend on. A reason to stay would be that the product can grow with their needs, without asking them to start over each time.

That advantage would shrink where data and connections are easy to move, or where a focused app is genuinely better. I expect both approaches could coexist. For a founder, the useful question is why people leave: do they need a different product, or do they need to change something yours insists on keeping fixed?

A useful version could travel

Most people may never want to make a modification. They could still benefit from one.

Another family could try that meal-planning setup in a few taps. They would bring their own recipes and schedules. What travels is the way the software works, with none of the first family's private information attached.

A person who would never write a feature request might recognize their situation immediately. Discovery could happen through someone with a similar life, rather than through the app's list of features.

For a product team, this could make small pockets of demand easier to see. A request that sounded peculiar in a support ticket might become an adaptation hundreds of people keep using. That would be a reason to investigate and perhaps support it directly, though popularity wouldn't establish that it was safe or well designed.

Some niches might then become maintained versions within a larger product, rather than separate businesses rebuilding the same basic service. Others would still deserve their own app.

A company would then have a new decision to make: which adaptations should it recommend, maintain itself or leave as personal experiments? Helping people find a version they trust could matter as much as helping its creator make it. It would be easy to create a bewildering library of modifications and give customers another selection problem.

The limit is what the company can stand behind

A million customers wouldn't necessarily require a million complete builds. One plausible design is a shared core for accounts, data and essential operations, with each user's changes stored separately. Common adaptations could reuse the same code. More unusual ones might need their own isolated components.

Some infrastructure for that already exists. Cloudflare's Workers for Platforms can run customer-written or AI-generated server-side code in isolated environments with usage limits. It addresses part of the execution problem. It doesn't decide whether a change is useful, behaves correctly or remains affordable to support.

The harder question arrives when the company updates the shared product. Which personal versions still work? Which need to change? A customer shouldn't have to choose between keeping a useful adaptation and receiving fixes. The company would need to update compatible versions and explain when one has to be repaired or retired, preserving people's records through the change.

The checks would also have to match what a modification can do. Changing a grocery list is one thing. Letting it place an order introduces money and an action that can't simply be erased by restoring the old screen. Both might run without errors; the second needs tighter permissions and a clear point at which the customer agrees to buy.

Sharing also creates an opportunity for abuse. An apparently useful modification could quietly send private information elsewhere or consume expensive services. The app would need to limit what modifications can access and spend, and disable harmful versions after they spread. Having another agent review the code wouldn't remove the need for those limits.

This is where the cost of customization would become clear. If the company can check and update many variations through the same reliable mechanisms, it could support a wide range of needs. If every change becomes a special case, it may be better off offering a few well-designed options.

Some companies will have reasons to resist

A user might remove the feed that brings them back, the prompts that get them to invite friends, or the screens that carry advertising. What improves the experience for that person may work against the company's existing measures of success.

A paid utility might have more reason to welcome a personal version that keeps someone subscribing, even if they open it less often. It would still have to earn enough to cover the extra work. An established company could have the customers, data and infrastructure to make customization possible and decide it doesn't want to.

That refusal could leave an opening for a competitor. A smaller product might win customers by letting them solve a problem the larger one won't accommodate. It wouldn't need to match every feature, but it would need to make those changes dependable. Meanwhile, a polished product with strong defaults could win by making customization unnecessary.

I don't think the useful first experiment is to promise an app that can become anything. I'd look at recurring requests that are reasonable for some people and distracting for everyone else. Could customers make some of those changes themselves, using tools the company can keep working as the app evolves?

I'd want to see whether people keep them, whether others find them useful, and whether the support cost stays manageable through an update. A request can be too specific for the default product and still be worth making possible.