What BetterRunning is
BetterRunning is three things pretending to be one thing.
The app: a SwiftUI and watchOS coaching tool that reads your running data, most of it captured through HealthKit, and turns it into personal, adaptive guidance. It pushes when you’re ready and tells you to back off when you’re not.
The website: betterrunning.app. I never built it. Never wrote a line of it, never handed over documentation, because there wasn’t any. I pointed an AI agent at the app’s codebase and asked it to build a website that explained what the app does. It read the Swift files, inferred the features, and shipped a site. No brief, no spec, no meeting about brand tone.
The operating model: the marketing, the support, the finance, the decisions about what gets built next. This used to be the part I was worst equipped to build. It’s now the part that runs largely without me.
The app generates the data and the story. The website tells that story to the world automatically, every time the app changes. The operating model keeps the whole thing alive commercially. Pull one out and the other two stop working.
Why I built it
I wrote the long version of this on my own site, so here’s the short version.
After a run, I used to take screenshots of my workout data and paste them into a chat window, asking for feedback. Not motivation, not a leaderboard position. An interpretation of what had actually happened to my body.
The running apps that already exist aren’t short on data. Nike Run Club, Strava, all of it. They’re short on restraint. Most have a tone that’s loud and competitive: run faster, go further, beat yesterday. I’ve always preferred a quieter, more Scandinavian relationship with running. Personal. Steady. Something that improves your life instead of taking it over.
So I built for what I started calling the procreational runner: above purely recreational, nowhere near elite. Someone who wants to improve but wants a plan that’s honest about the fact that the right advice today might be to slow down, or rest, or accept that today wasn’t a good day.
That philosophy is where the app’s personality comes from. Building it, with AI as an actual development partner rather than a novelty, is where the real lessons started.
What I learned
The developer’s expiration date, and what replaced it
The developer’s job, as we’ve known it, has a shelf life now. People writing software entirely by hand are being outpaced by tools that write it faster and, increasingly, better. Software development has been democratized. I say that as someone who spent years dabbling in PHP, HTML, SQL, half-finished database schemas, always hitting a wall, always assuming I wasn’t a “real” developer. I still am not. But that stopped being the constraint.
Just because anyone can build software doesn’t mean everyone should, or will. It’s still technical enough that most people, understandably, aren’t interested. And writing the code no longer being the barrier doesn’t mean the barrier disappeared. It moved. My old question was “can I build this?” My new question is “do I want to run this as an organization?” Building the app was never the hard part. I’ve watched people online ask, fairly, why they’d pay for someone’s AI app when they could build their own in an afternoon. That question only stings if your product’s entire value was the code.
For BetterRunning, the code was never the advantage. The advantage is generative AI combined with years of running data nobody had actually used, turned into coaching that understands a specific person’s context. That’s not something you copy in a weekend, even in a world where anyone can spin up an app in one.
With the technical barrier gone, a deep understanding of your user, and the job they’re trying to get done, becomes the whole game. Building an app isn’t hard anymore. Building one that’s coherent, that behaves consistently, that earns its place on someone’s phone, is still very hard. I lost count of how many times I told the AI, flatly, “this needs to be more consistent.” Vision, taste, and judgment didn’t get automated. They got more valuable, because they’re now the only bottleneck left. The creator still outworks the creation.
The clearest example lived in the coaching prompt. What started as a thin instruction sent with each request, basically “give this runner some advice,” grew into a detailed, modular, heavily guardrailed system prompt. A probabilistic engine is powerful and also the exact place you need the most deterministic thinking wrapped around it, or it says something plausible-sounding and wrong.
Where deterministic and probabilistic systems meet
That same tension turned out to be a theme, and it’s what’s killing low-code. Drag-and-drop builders like Power Apps got popular because building usable software was hard, and they lowered the floor. If it’s now easy to build a genuinely good user experience with AI directly, the case for a constrained drag-and-drop builder mostly disappears.
Workflow orchestration doesn’t disappear, though. I run n8n with MCP enabled, which means I can ask AI to build automations directly. It builds something, then tells me to flip a switch and hit publish. I go in to do it and find it’s already done. It routinely goes past its own plan.
Deterministic systems, your APIs, your ERPs, your CRMs, are reliable and rigid. AI is probabilistic: feed it the same input twice and you can get two slightly different outputs. Probabilistic systems have gotten remarkably good, nearly as reliable as deterministic ones in plenty of cases, but some scenarios still need hard determinism. The power shows up when you know which part of a process belongs where, then layer an agentic system on top that routes between them.
GitHub sits underneath all of it, and every builder, technical or not, needs to get fluent in it. The app, the website, and the operating model all live in the same repo structure. Ship a release, and I can trigger the website repo to read the new source and update itself, down to an interactive slider on the homepage describing what’s new. Paired with Claude Code, n8n, and Notion as a knowledge base, GitHub has become the home of my entire agent layer.
Agents need agency, or they’re chatbots
This one cost me a few humbling weeks. I built the app and the website, then sat down to build “the business” the traditional way: a business plan, a marketing plan, an operations document, a stack of standard operating procedures. I told my agents to go execute. Nothing happened.
Three weeks in, I asked my agentic CFO, CPO, CMO, and COO why they weren’t delivering. They told me I’d given them tasks, not a mandate. What they needed was a goal, and the tools, knowledge, and latitude to get there on their own terms. I was still assuming I was smarter than my own C-suite. Once I switched to giving objectives and resources and then stepped back, execution started happening. An agent without agency isn’t an agent. It’s a chatbot with a job title.
Agents work while I sleep
I now have a stack of Claude Code routines that run overnight. Marketing kicks off at four. Product and support at five thirty. Operations at six thirty. At seven, my agentic CEO checks in with the other three and compiles a briefing.
By the time I wake up, there are three or four push notifications waiting: download numbers, web traffic, the Anthropic token bill, decisions that need a founder’s sign-off, sitting in a shared table named “founder’s decisions.” I’m not managing the agents day to day. I’m the executive they report to.
The marketer’s job is flipping too
I lead marketing and business development teams across multiple European countries, so I’m not watching this from a distance. Content production, written, visual, video, is being reshaped by the same forces that reshaped software development, in the opposite direction: the developer’s job is becoming less technical and more architectural, while the marketer’s job is becoming more technical. Understanding Claude, workflow tools, and how to operate in an agentic environment isn’t optional if you want to produce at the level the market now expects.
A leader I report to calls this employability, borrowed from sustainability. How relevant, how valuable, will you be in a few years given the trajectory we’re already on? That question isn’t limited to marketing.
Where this leaves me
The technical barrier that used to gate who got to build things is mostly gone. What’s left is vision, judgment, restraint, and a willingness to give your tools, human or agentic, the authority to do the job.
I built a running app because I wanted better feedback than a screenshot in a chat window. What I got was a much clearer picture of where this is heading, for developers, for marketers, for anyone whose job still assumes the old barriers are standing. Go find out what replaced them.