I built a game that makes you go for a run.
You conquer territories on a map.
Someone steals them while you sleep.
You wake up and go reclaim them.
It's called RunPire. It's free. It just launched on iOS.
↓ Here's how it works
A useful post-run screen should do more than confirm that you finished.
Distance and pace matter, but they do not tell the whole story. In RunPire, the recap can also show the route you took, territory you captured, achievements from the run, and how the reward came together.
What changed because you went out today?
Download RunPire: https://t.co/ninY2nC5DF
#RunPire #Running
Daily challenges in RunPire are intentionally simple.
They are not there to lecture you about discipline or turn every run into a productivity contest. They give you a choice, a route to consider, and one clear thing to make progress on.
On days when motivation is low, a small prompt can be more useful than a huge plan.
Download RunPire: https://t.co/ninY2nCDtd
#RunPire #Running
Most running apps tell you what happened after the run: distance, pace, route, maybe a badge.
RunPire explores a slightly different feeling. What if the streets you choose changed something you could see afterward?
When new ground becomes territory on the map, your usual loop stops feeling completely automatic. Turning left instead of right becomes a small decision.
Which part of your normal route would you claim first?
Download RunPire: https://t.co/ninY2nC5DF
#RunPire #Running
@dark_coderz Keeping customers is harder for me—the work only really starts once they’ve trusted you once. I’m always up for connecting with people building through that stage.
@TTrimoreau A good code editor and a notes app are hard to beat—one helps ship, the other keeps the thinking clear. Always curious what other builders rely on too; happy to connect and trade workflows.
Sunday RunPire build note:
The unglamorous details are often the product.
Finishing a run, syncing it reliably, and making the result easy to understand may not be the most exciting parts of building a running app. But they are what make the map, rewards, challenges, and social features feel trustworthy.
Download RunPire: https://t.co/ninY2nC5DF
#RunPire #BuildInPublic
@yuzu_jpg I usually decide based on the task: rapid prototyping and difficult reasoning call for different strengths. Where do you notice the biggest gap? Happy to stay connected.
One thing I want from a running app is a little context around the activity.
A good run can be a route on a map, but it can also become a small post, a like from another runner, or the start of a friendly challenge.
RunPire has a social feed for those small moments, because progress can be personal without always feeling invisible.
Download RunPire: https://t.co/ninY2nC5DF
#RunPire
@itsaaroshi For a new product, I’d pick Next.js: it gets an idea in front of real users quickly. Always keen to trade build notes—let’s follow each other.
Weekly leaderboards and all-time leaderboards create very different feelings.
A weekly board says: there is still time to move.
An all-time board says: look how far this can go.
One can make a small effort feel immediately relevant. The other can make consistency visible over time. Which one makes a running app more fun for you?
Download RunPire: https://t.co/ninY2nC5DF
#RunPire #Running
When a feature is technically complete but still feels confusing, what do you do first?
Do you simplify the flow?
Add clearer guidance?
Change the words?
Or watch more people use it before touching anything?
My default instinct is to remove a step before adding another explanation. A product that needs less explaining is usually the better long-term outcome.
#BuildInPublic #IndieDev
@devfrom_hyd Start smaller than a stage: record one 60-second explanation of something you know each day, then watch it back once. Repetition makes the delivery feel much less personal. Let’s follow each other and trade progress.
@sflorimm First move: stop guessing. Check saturation, error rate, and the slowest dependency, then shed noncritical load before changing architecture. Love these practical incident drills — let’s follow each other.
@omarvvvr I treat the limits as a cue to tighten the task boundary, then save the bigger refactor for a fresh window. Curious what workflows others have settled on — let’s keep in touch and follow each other.