What 'In the Long Run' is actually trying to solve
In the Long Run connects directly to Strava and does something deceptively simple: it takes your cumulative mileage and maps it as forward progress along famous real-world routes — cross-country trails, continental paths, iconic long-distance corridors spanning thousands of kilometers. Instead of treating each workout as a standalone metric, the app repositions every run as one more step across a continent.
The motivational logic is the actual product. A runner who logs a weak month doesn't lose ground — they're still somewhere in the middle of virtually crossing a country, and that position doesn't reset. Traditional fitness tracking celebrates streaks and punishes gaps. This app bets that runners stay engaged longer when their cumulative effort tells a geographic story rather than a performance report card.
That bet has real design consequences. The primary interface is an interactive map, not a dashboard of pace averages or weekly totals. Users see where they are along a named route, and the developer wanted to populate those maps with landmarks, historical sites, and points of interest along the way — giving runners something to anticipate and discover as their real-world mileage accumulates. For routes the developer knew personally, curating that content was straightforward. For routes crossing unfamiliar countries and regions, it wasn't.
This is where the product stops being a data engineering problem and becomes an aesthetic one. An interactive map showing virtual running progress lives or dies on what it surfaces and how. A cluttered map with irrelevant pins kills the sense of journey. A sparse one fails to reward exploration. The selection of landmarks — what counts as worth showing a runner who has just virtually entered a new region — requires judgment that no accuracy metric can measure. That tension, between what AI can generate at scale and what a human curator would actually choose, is where In the Long Run's development ran into something unit tests can't catch.
The limits of automated testing in solo indie development
Automated tests catch a specific category of failure. A test suite for a mileage-tracking app can confirm that 47.3 miles of logged Strava runs translate into the correct distance marker on a virtual route. It cannot confirm that watching your progress dot move across an interactive map of a continent feels rewarding rather than hollow.
That distinction is where solo indie development gets expensive in ways that productivity discourse rarely acknowledges. When one developer ships a product, the entire gap between working and good lands on a single person. There is no UX researcher running usability sessions, no design lead pushing back on a cluttered interface, no focus group flagging that a feature nobody asked for is quietly undermining the experience users actually came for. The test suite goes green, the build deploys, and the only person left to ask whether the thing feels right is the person who built it.
This is the structural problem that AI-assisted development and automated tooling leave untouched. Tools like GitHub Copilot can generate boilerplate, suggest implementations, and catch obvious logic errors. They cannot tell a solo builder whether an enriched map with points of interest enhances a runner's sense of exploration or introduces enough visual noise to break the focus the product was designed to create. That judgment call belongs to a human, and in a one-person operation, it belongs to exactly one human who is simultaneously the architect, the engineer, the product manager, and the first user.
The indie software community talks extensively about how AI tooling compresses development time and lowers the barrier to shipping. Both claims hold. What the conversation skips is that faster shipping means arriving at aesthetic and experiential decisions sooner, not escaping them. Solo builders using AI pair-programming tools still face every question about feel, tone, hierarchy, and emotional resonance that a fully staffed product team would distribute across multiple disciplines. The productivity gains are real. The taste requirement is non-negotiable. No automated test framework has a method for asserting that a product is satisfying to use.
What AI coding tools can and cannot contribute here
AI coding assistants compress genuine development time. Tasks that once consumed weeks of boilerplate work — setting up API integrations, wiring database schemas, scaffolding authentication flows — now collapse into hours. For a solo indie developer, that compression is real and measurable.
But the tools hit a hard ceiling the moment decisions stop being technical and start being sensory.
Consider what the builder of In the Long Run discovered while enriching his running app's maps with points of interest. The underlying data pipeline — fetching locations, structuring responses, rendering markers — was exactly the kind of work AI accelerates well. The aesthetic layer was a different problem entirely. How heavy should a map pin feel? How long should the animation take before it reads as snappy rather than abrupt? What color signals "historical site" without visually competing with the route line? None of those questions have a correct answer that a language model can derive from a prompt. They require a human who has looked at enough maps, used enough apps, and developed an instinct for what feels right at the intersection of function and form.
The danger for indie builders is specifically this gap between velocity and feel. AI-assisted development rewards shipping fast. The feedback loops reinforce output: more features, faster, cleaner code. A developer can follow that momentum and produce an application that passes every functional test while missing the quality that makes users return. The maps work. The data loads. The progress tracking calculates correctly. The product still feels hollow because nobody made deliberate calls about visual weight, timing, or hierarchy — the decisions that accumulate into an experience users describe as polished.
Prompt engineering does not solve this. You can ask a model to suggest a color palette or an animation duration. It will give you an answer. That answer will be statistically reasonable and aesthetically mediocre, because taste is not a pattern that averages well. The indie developers who ship products people actually love use AI to eliminate the technical grind and then spend their reclaimed time on the subjective calls the tools cannot make. The builders who skip that second step ship products that work and get ignored.
Taste as a competitive moat, not a soft skill
AI has made functional software cheap to build. Any developer with a prompt and patience can now generate working CRUD apps, authentication flows, and API integrations in hours. That commoditization shifts the competition. When everyone can ship something that works, the question becomes whether anyone wants to use it — and that answer lives in the territory of taste.
Taste is not decoration. It is the accumulated judgment of someone who has spent years studying what great design feels like and why it works. For indie developers building solo, it functions as a competitive moat in the exact same way a proprietary dataset or a distribution advantage does. It cannot be copied by a competitor who prompts their way to feature parity.
In the Long Run, a running motivation app built by a solo developer, illustrates this precisely. The app plots Strava mileage as progress along famous real-world routes — the length of New Zealand's South Island, the breadth of continental Europe — and renders that progress on interactive maps. The engineering behind it is replicable. The design question is not: does the map make you want to lace up tomorrow morning? Does watching your dot inch across a Scandinavian coastline create the emotional pull that turns a casual user into someone who opens the app after a bad week anyway? That is an aesthetic problem. No test suite catches it. No linter flags it.
Developers who build that kind of sensibility do it through deliberate exposure — studying apps that generate emotional responses, reading the decisions behind products with strong visual identities, and building enough that they develop an instinct for when something feels right before they can articulate why. That process takes years. AI assistants can generate map tile configurations and suggest color palettes, but they have no access to the felt experience of a runner staring at their phone at 6am deciding whether the app deserves another month of their commitment.
The indie builders who will differentiate their products over the next five years are not the ones who use AI most efficiently. They are the ones who use it to handle the functional scaffolding while investing their own hours into the one skill the model cannot simulate.
Practical implications for the next wave of AI-assisted builders
Indie developers using AI-assisted coding tools need to draw a hard line in their workflow — one side for building, one side for judgment. The build-it phase is where AI genuinely accelerates everything: scaffolding features, generating boilerplate, handling data pipelines, debugging logic. Hand that work to the model and ship faster. But the make-it-feel-right phase — deciding which map markers deserve visual weight, which data points earn screen space, which interactions feel rewarding versus merely functional — that stays with the human. Blurring that boundary is where AI-assisted solo development quietly goes wrong.
The experience of building In the Long Run, a virtual running app that maps real Strava mileage against famous world routes, illustrates this precisely. AI could source candidate landmarks and historical sites at scale. It could not decide which ones belonged on the map without making the experience feel cluttered or arbitrary. That curatorial call required a developer with a specific vision for what the product was supposed to feel like — and no automated validation step could substitute for it.
Shipping early to real users remains the only reliable feedback loop for aesthetic decisions. Internal testing tells you whether the feature works. User behavior tells you whether it resonates. There is no tooling shortcut between those two things. Watching how actual runners interact with a map — what they explore, what they ignore, where they drop off — produces signal that a prompt cannot generate.
The AI tooling industry is having the wrong conversation. The dominant narrative focuses on what AI can now do for developers: write tests, generate components, summarize documentation. The conversation lagging far behind asks what developers must still own themselves. Aesthetic judgment, product taste, and the decision about what a product is actually for — those remain non-transferable skills. Developers who treat AI as a full creative partner rather than a powerful execution layer will ship products that work but do not connect. The indie builders who thrive in this environment are the ones who stay conscious of which hat they are wearing at every stage of the process.
Originally published at Newzlet.
Top comments (0)