The idea
Qvestit is a mobile app I'm building on my own with Claude Code. I do the product, the design decisions and the architecture, and I review and test what comes back. It's Android first, and the closed beta on Google Play is out now. Until recently it was called Daily Quest App.
You turn the things you already meant to do into quests, and completing them earns credits. Credits are the only way to pay for the things you'd otherwise just take, like an hour of gaming, a snack or a night out.
The part I find most interesting is Guilt-Free Cash. You set a monthly budget for the money you're willing to spend on yourself, and the app turns earned credits into permission to spend it. Real money can never buy credits, so everything in the economy has to be earned.
Designing the quests
A habit and a task want different things from an app, so there are five quest types for now. Action is a thing you do, priced by how long it takes and how hard you push. Avoid is a temptation you resist. Timed runs a countdown you have to finish. Progression is built from parts, either the same action repeated toward a target or a checklist of separate steps. Limit is a cap on how long you use an app. Each one runs daily, weekly, on set days or once, and daily and weekly quests keep a streak.
Modifiers go on top of the type. Set Later is for a quest you can't price in advance, so you set the difficulty when you complete it. Repeatable lets one quest be logged many times in a day. Stakes is the only one with a downside. You attach a penalty to a quest to buy yourself some motivation, and if you miss it the credits are taken whether or not you open the app. It has three tiers, Important, Serious and Critical, each raising the payout and the penalty together. Without it, something small but important like taking your medication is worth a few credits and carries no weight at all.
Pricing real money
Guilt-Free Cash needs an exchange rate between credits and money, and it can't be a fixed number. Someone who finishes twenty quests a week earns far more credits than someone who finishes three, and if a credit was always worth the same amount, the first user would just hand themselves more money.
So the suggested rate comes from what you actually earn. The app looks back over eight weeks, works out how many credits a month of your quests produces, and divides that into your monthly budget. Earning twice as much makes each credit worth half as much, so there's nothing to farm. On day one there's no history yet, so the setup asks how much you want to spend guilt free each month and estimates a starting rate from the quests you've set up.
This is the hardest design question in the app and I don't think it's finished. It's the piece most likely to change once real people are using it.
The first run
A new user starts by completing a practice quest on a real quest card and spending the credits in the shop, before anything else. Then they pick the areas they want to work on, choose their first quests from templates in those areas, pick a few guilty pleasures for the shop and set a daily XP goal. The guilty pleasures are priced by how bad they are for you, so a night out costs more than watching an episode. Sign-up comes last, so nobody makes an account before they've seen what the app does. Notification permission is asked for the first time a feature needs it, like a timer running out.
Themes and Prisms
How the app looks is a theme. A theme owns colours, shapes, type, motion and icons, but it can't move anything on a screen. There are no hardcoded colours or spacing values anywhere, so adding a theme means writing a new set of tokens and touching nothing else. The default theme is near-black or white with one green, which only shows up on credits, finished quests and success messages.
Themes are also what the app sells. Prisms are a second currency that only buys looks, which for now means themes and their colour variants. You can buy Prisms, earn a few by watching an ad, or earn them from challenges. Real money still never buys credits, Guilt-Free Cash or progress.
Friends and the feed
Every quest is either public or private. Friends see your public quests, but the credits and XP on your card include the private ones, so you can keep something to yourself without your day looking empty. The feed is one card per friend per day, showing what they earned and the quests behind it. Avoid and Limit quests only show up on the day you break them, in red.
There's no leaderboard and I don't plan to add one. Everyone prices their own economy, so a ranking would compare numbers that don't mean the same thing.
Challenges
Challenges are tasks inside the app, like creating an Avoid quest or reacting to a friend's card. Getting started is a list of them that walks a new user through every feature. There are also daily and weekly challenges, timed events, and community events where everyone's progress adds up toward one shared goal. Challenges pay Prisms and XP, never credits, because credits are tied to real-life effort. For the same reason, XP from challenges counts toward your level but not toward your daily streak.
Paying for the app
Qvestit has a 14-day trial with no card, and after that it costs $4.99 once. There's no subscription. I didn't want a short trial that turns into an expensive subscription. People should get real time to try it and then pay once, cheap enough that it's just five dollars. Running the backend for one user costs so little that one payment covers them for years. If the trial ends without a payment, the app turns view-only. Everyone in the closed beta gets it unlocked for free.
App limits on Android
The Limit quest needed something React Native doesn't do, so the app has a small native Android module that reads the system's app usage and sets alarms against it.
The rule I set for it is that it can barely do anything. It never touches the network, never fails a quest and only writes a local note. If anything goes wrong it does nothing and lets the app sort it out later. I had never touched an Android native module before and wouldn't have tried one on my own, but I could say what it had to guarantee and check whether the result held up.
How I build it
I don't write the code for this app. I build it with Claude Code, and my role is closer to a designer and architect than a programmer.
The loop comes from superpowers, a set of skills for Claude Code that turns an idea into a written design spec, the spec into a plan, and the plan into slices that each end in testing and review. A spec covers what the feature is, why it works that way, what it must never do, and what I'm accepting as a downside. The other skill I use is impeccable, which knows the Android and iOS conventions I'd otherwise be guessing at.
Getting ready for the beta meant setting up a release process. Every pull request is reviewed by Claude and has to pass all the checks before a bot merges it, and a release to production also waits for me. Updates go out over the air to 20% of phones first, and I can widen the rollout or roll it back with one button.
What I think about working this way
I would say it's a mix. I miss sitting with a problem and solving it line by line, which was the part of programming I liked most, and there's very little of that left now. On the other hand I can build in stacks I couldn't use on my own, and it's a lot faster. I've gone from nothing to an app that's almost ready for testers in seven months, on my own.
The models still hallucinate and write bugs, and sometimes they build something that works but isn't what I asked for. A lot of my time goes into testing, finding what's wrong and prompting again, and that's why the specs and reviews are there. I think this is where the industry is heading, and that more of the work will be about system architecture and knowing how to use these tools well. Qvestit is where I've been learning that.