I built the perfect running app for me. Now I can’t justify paying monthly for some apps

There’s a question I keep coming back to recently:

If one person can now build and maintain an entire app with the help of frontier AI models, why should every app require a monthly subscription?

Take something as simple as a budget-tracking app. Why should I pay for it every month or every year if I can build something similar in a week, potentially with even more functionality tailored specifically to what I need?

I’m not saying subscriptions are going away entirely. Some apps have real ongoing costs such as servers, cloud storage, AI inference, licensed content, customer support, and constantly changing data.

But I do think something else might be coming to an end: the idea that a subscription should be the default business model for almost every app.

For years, subscriptions made sense partly because software was expensive to build and maintain. You needed designers, developers, infrastructure, support, and months or even years of work to turn an idea into a polished product.

AI is starting to change that equation.

And I experienced that shift firsthand while building an app called EmberRun.

How It All Started

EmberRun started about a year ago at the intersection of two things I spend a lot of time thinking about: software development and long-distance running.

I’ve been building software professionally for around five years and running consistently for the past three. As I got deeper into the sport, eventually attending a certified running coach program, I started noticing small problems in the way I planned and organized my training.

The frustration was simple:

I wanted a better way to organize my running plans.

There are already excellent products from Garmin, COROS, Runna, and many others. The market certainly isn’t missing running apps.

But I wanted something more personal.

I wanted to create a training plan from scratch, adapt it to exactly what I needed, and use it with the devices I already owned (an Apple Watch). More importantly, I did not want to add another subscription just to organize my training.

That led me to a bigger question.

As an iOS developer, I already pay $99 per year for the Apple Developer Program. That lets me distribute the apps I build through the App Store and install development builds on my own devices.

For me, that fee was already part of the equation. But that distinction matters. If someone joined the program purely to avoid paying for a $100-per-year running app, the economics would obviously look very different.

And the developer fee is not the real cost of building an app anyway.

My time is.

EmberRun took me about a year to build, not a week. If I priced hundreds of hours of my own development time at a professional software engineer’s rate, paying for an existing running app would have been dramatically cheaper.

So EmberRun is not evidence that everyone should cancel their subscriptions and start building their own software.

It is one data point, built by someone who already knew how to develop software.

What I find interesting is how much that data point changed during the year I spent building it.

For roughly the first eight months, I built EmberRun mostly without AI doing the implementation for me. I learned a lot in the process, but my biggest constraint was simple: time. Every feature competed with every other feature for the hours I had available.

Then I started seriously using agentic coding tools.

Over the following four months, the scope of what I could build expanded significantly. Features that previously would have consumed a large part of my available development time became much faster to prototype, implement, test, and refine.

That does not mean the cost dropped to zero.

I still have to maintain the app. Apple will release new versions of iOS. APIs will change. Bugs will appear. Users may need support. Features that work today may need attention a year from now.

Those ongoing costs are also one of the legitimate reasons subscriptions exist.

But something had clearly changed.

The question was no longer simply, “Why pay $100 a year when I can build this myself?”

It became:

How much software becomes practical for one person to build and maintain when AI dramatically reduces the amount of work they have to do manually?

And once I had already built one app, I started thinking beyond EmberRun.

If I use five different utility apps, each charging its own monthly or yearly subscription, perhaps I do not need to replace all five. But what if one of them is simple enough that I can build exactly what I need? What if I can remove the features I never use, add the widgets I actually want, and integrate it directly with the devices and services I already own?

The calculation starts to look different.

On Android, the distribution cost can be lower still. Google currently charges a one-time $25 registration fee for full distribution, rather than an annual developer membership.

That was the original thinking behind EmberRun.

But somewhere during that year of building it, the more interesting story stopped being about running.

It became a story about how dramatically the economics of building software are starting to change.

What Used to Take a Team

Not long ago, building a polished app usually meant bringing together several different roles.

Someone had to shape the product. Someone had to design the interface. Engineers had to build it. Tests had to be written, bugs investigated, infrastructure maintained, and documentation kept up to date.

Even a relatively small app could quickly become a team-shaped project.

That relationship is starting to change.

Today, frontier models such as Claude Opus 5, Claude Fable 5.1, GPT-5.6 Sol, and GPT-6 Astra go far beyond autocomplete.

They can reason across a codebase, plan changes, implement features, write tests, investigate failures, explain unfamiliar code, and work through tasks that span multiple steps.

These are no longer just claims about what AI might eventually be able to do.

In 2026, METR and Epoch AI published early results from MirrorCode, a benchmark that asks AI agents to recreate existing software from its behavior. Their results showed that frontier agents could already complete some coding tasks estimated to take human developers weeks.

Don’t get me wrong, I do not think that AI has made software development automatic (yet).

The more interesting conclusion is that one capable person can now attempt a much broader part of the software development process.

That is exactly what happened with EmberRun.

While building it, I moved constantly between product decisions, Figma designs, SwiftUI screens, domain models, persistence, tests, debugging, and documentation. AI helped me work across all of them.

I was still responsible for the decisions. I still had to understand the code. I still had to recognize when the AI was wrong, decide what belonged in the product, and make sure the final result actually worked.

But I was no longer working alone in the traditional sense.

And that changes the economics of building an app.

The First Thing I Built Was Control

The first major feature I built for EmberRun was the Custom Plan Builder.

The idea was simple: runners should be able to create whatever plan they want.

They can copy a program they found online, recreate a plan provided by a coach, or build one entirely from scratch. Workouts can be assigned to specific days, reused across the plan, moved around, and adjusted whenever life gets in the way.

Once the plan is ready, it can be saved, duplicated, exported, imported, and shared as an .emberplan file.

That file format also creates an interesting possibility.

Because the plan exists as a document outside the app, a runner could theoretically use any capable AI model to generate an .emberplan file and then import it directly into EmberRun. The AI does not have to live inside the app. The runner can choose which model or tool they want to use.

This feature ended up being more important than I originally expected.

When people hear the phrase “AI-generated training plan,” they often imagine an app deciding everything for them.

But many runners do not want to give up that level of control.

They may already have a coach. They may be following a specific training philosophy. They may have a race strategy they trust, or simply know what has worked for them in the past.

What they need is not another system telling them how to train.

They need a better way to organize the training they have already chosen.

That is why EmberRun has a fully manual path.

The runner remains in control of the plan, while the app provides guardrails around it.

It can check for missing information, duplicate workout days, invalid workouts, overly long plans, and hard sessions placed too close together.

So the result is more than just another calendar.

It becomes a portable training document that the runner owns, edits, shares, and takes with them.

Then I asked a different question

Once the manual plan builder existed, I started wondering:

What if the app could help create the plan without requiring a cloud service?

Most AI features are easy to prototype when every request can be sent to a remote model. But every request also creates an ongoing cost.

The more users generate, the more inference the developer pays for.

That changes the economics of the product.

The current frontier API models are priced by usage. For example, OpenAI lists GPT-5.6 Sol at $4 per million input tokens and $20 per million output tokens, while GPT-6 Astra is listed at $10 per million input tokens and $50 per million output tokens. Anthropic’s current model overview lists Claude Opus 5 and Fable 5.1 with their own per-token prices.

For a developer, those costs may be reasonable during development.

For a popular consumer app, they become part of the business model.

A free app that generates expensive cloud responses for thousands of users is not truly free to operate.

That was the point where EmberRun Intelligence feature took a different direction.

Putting the Model on the Phone

Once I decided EmberRun should generate plans with AI, one architectural choice mattered more than almost anything else: where should the model run?

The obvious answer was the cloud. Larger models are faster, more capable, and easier to update. But every generated plan would also become a billable inference request. If thousands of runners used the feature, the cost would grow with them.

That was the opposite of the product I wanted to build.

So I put the model on the phone.

EmberRun uses Gemma 4 E2B through Google’s LiteRT-LM. The model is roughly 2.6 GB, so it is downloaded only when someone enables EmberRun Intelligence rather than being bundled with the app.

The first setup still needs an internet connection, enough storage, and some patience. After that, plan generation can happen entirely on-device. The runner’s inputs and generated plan can stay on the phone, and I do not pay for a cloud request every time someone taps Generate Plan.

Of course, the cost did not disappear. It moved.

A phone has far less compute than a data center, so generation is slower and varies by device. Running the model uses battery and processing resources. And because Gemma 4 E2B is small enough to fit on a phone, I cannot expect it to match the reasoning depth or consistency of a much larger frontier model. For difficult or unusual requests, a cloud model may still do better.

There is a compatibility tradeoff too. I developed and tested local generation on an iPhone 13 Pro. EmberRun supports iOS 17 or later, but I have not verified the same experience across every supported iPhone, each with different memory, thermal limits, and processing capabilities.

That limitation forced a second design decision, and it turned out to be just as important:

the model should not run the whole application.

It is tempting to ask an AI model to generate a 12-week half-marathon plan, calculate every date, assign every workout, distribute weekly mileage, validate the result, and hand back a finished calendar.

A model can attempt that. But much of that work is not an AI problem.

Some decisions are contextual: what the focus of a training phase should be, whether a threshold workout makes sense, how to describe an interval session, what a recovery week should emphasize, or how to summarize the plan.

Others are deterministic.

Suppose a runner asks for a 10-week plan starting September 21, with four runs per week and the long run every Sunday.

I do not need AI to discover which dates are Sundays. Swift can calculate that exactly, build each training week, find the available run days, place the long run correctly, and make sure nothing falls outside the requested plan.

Weekly distance works the same way.

If the model decides week four should total roughly 35 km and contain an interval session, an easy run, a recovery run, and a long run, it does not need to invent four precise distances that happen to add up correctly. The app can take the 35 km target, distribute the volume according to predefined rules, round the distances, and verify the total.

The model contributes the intent. The code enforces the rules.

That also gives EmberRun a safety net when the model gets something wrong. If it proposes two hard workouts on consecutive days, the app can flag them. If required workout information is missing, the result can be rejected. If a generated plan exceeds the requested duration, ordinary validation code can catch it before the runner sees it.

The same split applies at a smaller level. The model might decide that a runner should enter a threshold-focused phase and suggest six-minute intervals around threshold effort. Swift can decide that the workout belongs on Tuesday, that Tuesday is September 29, how much it should contribute to the week’s volume, and that another hard session should not follow immediately.

This is the architecture EmberRun Intelligence eventually settled on:

the model provides the intelligence; the application provides the structure.

And that brings the economics back into focus.

Cloud AI moves the computational burden away from the user, but every request has to run somewhere and someone has to pay for it. Local AI moves that burden onto hardware the runner already owns, trading server bills for storage, battery, generation time, and some model capability.

So when I say EmberRun is free, I do not mean it costs nothing to build or maintain. I still spend time on development. The model consumes storage. Downloads consume bandwidth. iOS updates can break things. Bugs and support do not disappear.

What changed is the cost structure.

The core AI experience does not create a growing inference bill every time another runner generates a plan. For a product I want to keep free, that difference is enormous.

And the engineering lesson reaches beyond running apps: the strongest AI products may not be the ones that hand everything to a model. They may be the ones that are deliberate about where AI should be flexible — and where ordinary software should remain firmly in control.

What does this have to do with subscriptions?

Everything.

Apple’s own guidance says subscriptions should provide ongoing value. Apple lists continually updated content, software-as-a-service products, and cloud support as appropriate examples for subscriptions.

That makes sense.

A subscription is reasonable when the app provides something that continues to cost money or continues to deliver new value.

Examples include:

• Cloud AI inference
• Storage and synchronization
• Streaming media
• Large content libraries
• Live services
• Human coaching or support
• Regularly updated data
• Ongoing professional tools

In those cases, the subscription is paying for an active service.

But what about a static utility?

What about an app that has no server, no ongoing data cost, and no meaningful monthly service behind it?

If the app is mostly a collection of features stored on the device, charging every month can feel disconnected from the actual economics.

The subscription becomes less about sustaining the product and more about maximizing recurring revenue.

That model is becoming harder to defend when a single developer can build and maintain more capable software with AI assistance.

EmberRun’s answer

EmberRun will always be free.

I do not intend to put the core experience behind a subscription. I may add a Support one-time payment button for people who want to support me, but the app should remain usable without a monthly or yearly payment.

That decision is possible because EmberRun’s most expensive feature “AI plan generation” runs locally after the model download.

If the app depended on a cloud model for every plan, I would have a different conversation. At that point, a subscription or usage-based payment could be reasonable because each user would create a real recurring infrastructure cost.

But that is not the product I wanted to build.

I wanted a running companion that felt private, flexible, and affordable.

The current version is available on the App Store, designed for iPhone and available for free.

So, are apps with subscriptions done?

Not yet.

But I think automatic subscriptions are becoming less convincing, and free and one time payments maybe the better option for some specific apps.

AI-assisted development lowers the cost of creating software. Local models lower the cost of delivering certain intelligent features. Together, they make it possible for smaller teams to build products that previously required much larger organizations.

That does not eliminate the need for subscriptions.

It changes the question behind them.

Instead of asking, “Can we charge monthly?”

Developers should ask:

“What ongoing value or ongoing cost does this payment represent?”

If the answer is cloud infrastructure, live data, human expertise, continuously updated content, or expensive AI inference, a subscription may be completely justified.

If the answer is only “because every other app does it,” users may start asking harder questions.

EmberRun is my small experiment in that new world.

It was built with AI assistance, but it was not built without human judgment. It uses local AI, but it does not pretend that a model can replace product design or engineering discipline.

Most importantly, it is a product whose price follows its architecture.

Because the app does not need to pay a cloud model every time a runner creates a plan, I do not need to force every runner into a recurring payment.

That may not mean subscriptions are done.

But it may mean the era of charging monthly for everything is.

I built the perfect running app for me. Now I can’t justify paying monthly for some apps was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.