The Idea
Daily Quest App is a mobile app I am building on my own. It is still under development, nothing is released yet, and a lot of it is still changing. Even the name is a placeholder until I think of something better.
You turn the things you already meant to do into quests, and completing them earns credits. Credits are then the only way to pay for the things you would 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 are 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.
I should also be upfront about this. I am building it with Claude Code. I do the product, the design decisions and the architecture, and I review and test what comes back. There is a section at the end about how that works and what I think of it.
Designing the Quests
Most of my time goes into the quest system. A habit and a task want different things from an app, and one kind of quest cannot cover both.
There are five 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 you set on how long you use an app. Each one runs daily, weekly, on set days, or once.
Modifiers go on top of the type, and they are the part I have reworked most. Set Later is for a quest you cannot 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 runs at 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.
One rule I keep coming back to is that the payout has to sit below everything that decides it, so you always read the cause before the number. A modifier is shown next to the thing it changes, for the same reason.
The other problem is that people can price their own rewards badly on day one and never recover. Templates are my answer for now. They are ready-made quests with the difficulty and time already set, so a new user starts with an economy that already works.
Pricing Real Money
Guilt-Free Cash needs an exchange rate between credits and money, and it cannot 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 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. A month of credits always converts to the budget and no more, so earning twice as much makes each credit worth half as much and there is nothing to farm. The credits and XP are worked out on the server, so the phone never decides what a quest paid.
This is the hardest design question in the app and I do not think it is finished. It is the piece most likely to change once real people are using it.
App Limits on Android
The Limit quest needed something React Native does not do, so the app has a small native Android module that reads the system's app usage and sets alarms against it. Usage can only build up at one minute per minute, so the time left before you can hit your limit tells the app exactly how long it can wait before checking again.
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. A warning about your screen time is not worth a background process quietly taking credits off you.
It is also a good example of what this way of working made possible. I had never touched an Android native module before and would not have tried one on my own, but I could say what it had to guarantee and check whether the result held up.
Friends, Without a Leaderboard
Every quest is either public or private, and that split is what makes the social side work. 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. Being on the feed already means you did it, so there are no ticks. Avoid and Limit quests work the other way around and only show up on the day you break them, in red. Resisting something all day is not an event worth posting, but slipping is. You appear in your own feed too, in the same order as everyone else, showing exactly what your friends see of you.
There is no leaderboard and I do not plan to add one. Everyone prices their own economy, so a ranking would compare numbers that do not mean the same thing. The feed is there to share progress, and that is as far as I want to take it.
One App, Many Themes
The app has two layers I keep apart. Where things sit on a screen is fixed. How it looks is a theme, and a theme owns colours, shapes, type, motion and icons, but it is not allowed to move anything.
So there are no hardcoded colours or spacing values anywhere. Everything reads a token, all spacing is a multiple of 8, and adding a theme means writing a new set of tokens and touching nothing else. It is the decision that has paid off most, because it turned "the app looks wrong" into a question with one place to answer it.
How I Build It
I do not write the code for this app. I build it with Claude Code, and my role is closer to a designer and architect than to a programmer.
The process is deliberately heavy, and the loop is not something I invented. It 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 am accepting as a downside. The modifiers, the rate and the quest form all existed as specs, and as arguments about those specs, long before they existed as code.
The other skill I lean on is impeccable, which knows the Android and iOS conventions I would otherwise have been guessing at. Finding tools like these and setting them up properly is a real part of the job now, and it is most of what I have learned building this.
What I Think About Working This Way
I would say it is a mix.
What I lost is the part of programming I liked most. Sitting with a problem and solving it line by line is mostly gone, and I do miss it.
What I got instead is reach. I can work with stacks I have no real ability to use on my own, and it is much faster. I have taken this from nothing to almost a complete app, alone, in a few months.
It is not free. The models still hallucinate and still write bugs, and they will happily build the wrong thing very well. Testing, catching what is wrong and prompting again until it is right is a constant part of the job, and the specs and reviews exist because of that.
I do think this is where the industry is heading. Less of the work is about how to write code and more of it is about system architecture, knowing what to ask for, and knowing how to get the best out of these tools. This app is where I have been learning to do that properly, and it is still in development because getting it right matters more to me than putting it out early.