• 

  Dashboard

• 

  Profile

• 

  Gamification (repairs)

Budget Runner

Inspiration

Budget Runner began with a simple observation: most personal finance tools are useful, but very few are emotionally engaging. They can show where money went, calculate totals, and display charts, yet they rarely make the user feel that good financial habits are building toward something tangible.

We wanted to explore whether a finance app could remain practical and trustworthy while also offering a meaningful sense of progression. The goal was not to attach arbitrary badges to a spreadsheet or turn budgeting into a shallow points system. Instead, the gamification needed to grow directly from the user's real financial behaviour.

That led to the central idea behind Budget Runner: every well-managed budget contributes to a persistent retrofuturistic cyberdeck.

The user sets weekly and monthly spending limits, logs real expenses, and sees those decisions reflected in a game system. Meeting a budget earns progression, while the remaining difference between the spending limit and the actual amount spent becomes a virtual currency called SynthCoins. Those SynthCoins can then be invested in cyberdeck modules such as neural chips, holographic cores, memory modules, displays, expansion boards, frequency jammers, quantum network cards, cooling systems, projectors, and power cells.

The project's visual identity grew from the same concept. We wanted Budget Runner to feel unlike a generic financial dashboard, so we built it around a synthwave and retrofuturistic design language: dark interfaces, neon accents, wireframe components, technical diagrams, subtle scanlines, and a cyberdeck that turns financial discipline into something visible and personal.

The broader experiment behind the project was also important to us: could an AI coding partner understand and preserve a deliberately unusual product vision instead of pulling the project back toward conventional patterns? Budget Runner became a way to test AI-assisted development not as “vibe coding,” but as structured pair programming guided by a clear product design, PRD, and GDD.

What it does

Budget Runner is a personal finance web application with a complete gamification layer built around budgeting, progression, and cyberdeck customisation.

At the finance level, users can:

• register income and expenses;
• organise transactions into editable categories;
• configure weekly and monthly budgets;
• create global budgets or category-specific budgets;
• review spending distribution and cash flow;
• track recent transactions and budget progress;
• use the application from desktop or mobile layouts.

The gamification system is directly connected to those financial actions.

When a user completes a budget period without exceeding the limit, they receive Flux, the score used to calculate their level. If they finish the period with money left over, the eligible surplus is converted into SynthCoins at a 1:1 ratio.

For a budget period (p), the raw surplus is:

$$ E_p = \max(0, B_p - S_p) $$

where:

• (B_p) is the budget limit;
• (S_p) is the eligible spending recorded during the period.

The awarded currency is:

$$ C_p = \left\lfloor E_p^{\text{eligible}} \right\rfloor $$

where (E_p^{\text{eligible}}) excludes any value that has already contributed to a reward in an overlapping weekly, monthly, global, or category budget.

This is important because Budget Runner supports simultaneous budgets. A transaction may appear in several financial calculations, but the same economic value cannot generate SynthCoins more than once. Weekly closures take priority over monthly closures when periods overlap, followed by category budgets over global budgets, with deterministic tie-breaking rules to keep the system auditable.

SynthCoins can be spent on modules for a virtual cyberdeck. The deck has ten fixed slots:

• CPU — Neural Chip
• GPU — Holographic Core
• RAM — Memory Module
• Display — Neon Display
• Expansion — Expansion Board
• Jammer — Frequency Jammer
• Network — Quantum NIC
• Cooling — Cryo Cooler
• Projector — Hologram Projector
• Power — Fusion Cell

There is no inventory. Each slot can contain only one active module, so buying a new module for an occupied slot replaces the previous one.

The net replacement cost is:

$$ \text{tradeIn} = \left\lfloor 0.5 \times P_{\text{old}} \right\rfloor $$

$$ \text{netCost} = \max(0, P_{\text{new}} - \text{tradeIn}) $$

where (P_{\text{old}}) is the original price of the equipped module and (P_{\text{new}}) is the price of the new one. Destroyed modules have no trade-in value.

Every module belongs to one of four visual families:

• Retrowave
• Synthwave
• Vaporwave
• Hi-Fi Tech

Modules also have three gameplay attributes:

• Power — a static value that contributes to the user's level;
• Shield — a static resistance value from 0 to 10;
• Energy — a dynamic health value that begins at 100.

Equipping several active modules from the same family grants a Power bonus. The total progression score is:

$$ F_{\text{total}} = F_{\text{base}} + \sum_i P_i + \sum_f B_f $$

where:

• (F_{\text{base}}) is persistent Flux earned from completed budgets;
• (P_i) is the Power of each equipped, non-destroyed module;
• (B_f) is the bonus produced by family (f).

For each family:

$$ B_f = \left\lfloor P_f \times r(n_f) \right\rfloor $$

where (P_f) is the total active Power from that family and (r(n_f)) is the bonus rate determined by the number of matching modules:

• 2 modules: 5%
• 3 modules: 12%
• 4 modules: 20%
• 5 or more modules: 35%

The store rotates its available modules every budget period. Offers are selected according to the user's level, so higher-level users can encounter rarer and more powerful hardware, but also more expensive options. The rotation does not examine the user's current build and does not guarantee a replacement for every empty slot. That scarcity is intentional: it gives older modules and repairs greater strategic value.

When a user exceeds a budget, Budget Runner does not remove previously earned SynthCoins. Instead:

• no SynthCoins are awarded for that period;
• no completion Flux is awarded;
• new cyberdeck purchases are temporarily disabled;
• the SynthCoin balance is shown in red with a restrained glitch effect;
• equipped modules receive damage;
• repairs remain available.

Damage is calculated from the percentage by which the user exceeded the budget:

$$ D_{\text{base}} = \left\lfloor \left( 1 + \frac{x}{100} \right) \times 100 \right\rfloor $$

where (x) is the percentage overspent.

For each module (i):

$$ D_i = \max \left( 0, \left\lfloor D_{\text{base}} - 10S_i \right\rfloor \right) $$

$$ E_i' = \max(0, E_i - D_i) $$

where:

• (S_i) is the module's Shield;
• (E_i) is its current Energy;
• (E_i') is its Energy after damage.

A damaged module continues contributing its full Power as long as its Energy remains above zero. If its Energy reaches zero, it is destroyed, stops contributing Power and family bonuses, and the user's level is recalculated immediately.

Damaged modules can be fully repaired at any time, even while purchases are locked:

$$ \text{repairCost}_i = \left\lceil P_i^{\text{original}} \times \frac{100 - E_i}{100} \right\rceil $$

This creates a persistent risk-reward loop. Users can spend SynthCoins aggressively on higher-Power modules, choose more defensive Shield-heavy hardware, preserve currency for repairs, or build around family synergies.

The full MVP is implemented locally and includes the finance system, budgets, statistics, Flux, levels, SynthCoins, the cyberdeck, rotating offers, purchases, replacement, damage, repairs, destruction, and responsive layouts. A public demo currently uses a sample account. Google OAuth and the complete production deployment remain the final major tasks.

How we built it

We began with design rather than code.

Before implementing the application, we created a structured product specification and a dedicated game design document. This was especially important because Budget Runner combines two systems that need to remain consistent:

1. a personal finance application with real user data;
2. a persistent game economy with progression, purchases, damage, and state transitions.

The documentation established the project's design pillars, terminology, formulas, data ownership rules, user flows, visual direction, failure states, and edge cases. It also defined what should not be added to the MVP, helping us avoid scope drift.

Development was carried out as a collaboration between Mike Fieldins and Codex, using GPT-5.6 “Sol” as an AI pair-programming partner.

The working process was intentionally different from unstructured prompt-driven development. Instead of asking the model to improvise the product, we gave it a clear design language and explicit system rules. Codex worked from the PRD and GDD, implemented bounded tasks, reviewed existing code, and helped iterate on the application while the human developer retained product ownership and final decision-making authority.

This approach was particularly useful for Budget Runner because the application deliberately avoids generic interface patterns. The visual design, cyberdeck system, rotating store, and failure mechanics all depart from what a standard finance application would normally contain. Keeping those decisions documented allowed the AI partner to understand not only what to build, but also why apparently unusual constraints mattered.

The local MVP was developed as a complete vertical system rather than a collection of disconnected mockups. Financial events feed the budget engine; budget closures feed rewards or penalties; those results update the virtual economy; and purchases, repairs, module destruction, family bonuses, Flux, and level all remain connected.

We also treated the economy as a transactional system. Purchases and repairs are not merely visual state changes: the application must validate the user's balance, the active offer, the target slot, replacement value, purchase locks, and the resulting Power and level before committing the operation.

The same principle applies to budget closures. The system must prevent duplicate rewards across overlapping periods, apply damage only once per closure, and keep the final state auditable and deterministic.

Challenges we ran into

The largest challenge has been preparing a system of this scale for a viable Firebase deployment.

Budget Runner is more complex than a typical hackathon CRUD application. Its backend needs to support financial records, simultaneous budget periods, reward attribution, rotating store offers, module instances, purchase locks, damage events, repairs, destruction, family bonuses, Flux, level changes, and user-specific histories.

The system worked locally, but deploying it responsibly required us to reconsider how much backend complexity was practical within the target infrastructure and cost constraints. The gamification backend had to be resized and reorganised so the production version could remain viable instead of simply reproducing the local architecture without regard for execution cost, operational limits, or future scale.

This was not only a deployment problem. It also became a product-design constraint: every background evaluation, read/write path, and state recalculation needed to justify its cost. We had to distinguish between data that must be persisted, values that can be recalculated, and processes that can be simplified without weakening the game rules.

The remaining deployment work is therefore not just “uploading the app.” It involves finding the right balance between correctness, maintainability, and the economics of running the service.

Another major challenge was balancing usability with the synthwave aesthetic.

Budget Runner is intentionally visually distinctive. Neon highlights, wireframe diagrams, scanlines, glitch effects, retrofuturistic terminology, and family colours are central to its identity. However, personal finance is a domain where clarity is essential. Amounts, warnings, budget states, repair costs, and consequences must remain easy to read.

We had to treat visual effects as feedback rather than decoration:

• glitch is reserved for exceptional states such as purchase locks or destruction;
• colour is never the only indicator of damage or failure;
• the cyberdeck uses synthetic technical visuals, but its stats remain explicit;
• responsive layouts reorganise information instead of simply shrinking it;
• financial dashboards remain more restrained than the gamification screens.

A third challenge was the interaction between overlapping budgets and the reward economy.

Weekly and monthly budgets can coexist, and users may also have both global and category-specific limits. The app must show accurate financial progress for all of them while ensuring that the same underlying value is not converted into SynthCoins multiple times. This required deterministic priority rules and a clear separation between “included in a financial calculation” and “eligible to generate a reward.”

Finally, module replacement and destruction introduced several consistency risks. A replaced module must stop contributing Power immediately. A destroyed module must also stop contributing Power and family bonuses. Every purchase, repair, or destruction can change the user's Flux total and level, so recalculation has to happen as part of the same logical operation rather than as an unrelated visual update.

Accomplishments that we're proud of

The accomplishment we are most proud of is the speed at which a complete and unconventional MVP could be built with Codex while preserving a coherent design vision.

Budget Runner was never intended to be a generic finance dashboard with a few badges attached. It combines:

• practical personal finance tools;
• simultaneous budget logic;
• a persistent virtual economy;
• a ten-slot cyberdeck;
• rotating offers;
• replacement and trade-in rules;
• module families and build bonuses;
• damage, repair, and destruction;
• dynamic level recalculation;
• responsive synthwave UX.

Despite that scope, Codex was able to understand and apply the project's established design paradigms, even when those paradigms deliberately departed from standard application patterns.

That was exactly what we wanted to test.

The result demonstrates that AI-assisted development can support a product with a strong identity rather than pushing every project toward the same generic component library and familiar user flows. The key was not asking the model to invent the direction. The direction was documented, defended, and continuously reviewed.

We are also proud of the way the gamification system remains connected to the core purpose of the product. The cyberdeck is not an unrelated minigame. Its state reflects budgeting performance, and every meaningful game action is funded by real financial discipline.

The system also avoids several common gamification shortcuts:

• no premium currency;
• no real-money purchases;
• no loot boxes;
• no arbitrary daily energy;
• no removal of previously earned currency as punishment;
• no inventory bloat;
• no rewards for repeatedly opening the app.

Progress comes from the activity the application is supposed to support.

Finally, we are proud that the local MVP is already functionally complete apart from Google OAuth and the final production deployment. The current demo uses a sample user, but the underlying finance and gamification systems are implemented and connected.

What we learned

The main lesson from Budget Runner is that AI can become a central part of a development workflow without taking away the developer's agency or direction.

For us, the difference between “vibe coding” and pair programming is not whether AI writes code. The difference is who owns the product logic.

In this project, the human developer remained responsible for:

• the problem being solved;
• the design principles;
• the final feature set;
• the ethical boundaries;
• the visual identity;
• the system rules;
• the acceptance criteria;
• the decision to approve, reject, or revise an implementation.

Codex accelerated implementation, helped interpret documentation, identified affected areas of the codebase, and made it possible to iterate at a speed that would have been difficult to reach alone during a hackathon.

We learned that AI performs much better when it receives:

• a clear PRD;
• a detailed GDD;
• explicit formulas;
• defined edge cases;
• stable terminology;
• bounded implementation tasks;
• an explanation of design intent, not only expected output.

This mattered especially when building unusual features. Without documented intent, an AI assistant may “correct” a deliberate design choice toward a more conventional solution. For example, it might try to guarantee replacement items for every empty slot, add a conventional inventory, or simplify failure mechanics until the strategic tension disappears. Explaining why those constraints exist allowed Codex to preserve them.

We also learned that infrastructure can reshape design. A local architecture may be logically correct but still require simplification before it becomes economically sensible in production. Deployment is therefore not a separate phase that begins after development; it feeds back into data modelling, service boundaries, background processing, and product scope.

From a game design perspective, we learned that ethical gamification requires more than avoiding manipulative monetisation. It also means making consequences legible, preserving recovery paths, and ensuring that the game layer never pressures users into harmful real-world financial behaviour.

Budget Runner's punishment system reflects this. Missing a budget can damage virtual hardware and temporarily disable purchases, but it never confiscates previously earned SynthCoins. The user can still repair modules, recover over time, and continue using every financial feature.

What's next for Budget Runner

The immediate priority is deploying the complete version of Budget Runner and making the production architecture economically sustainable.

The local MVP already implements the main finance and gamification systems. The next stage is to finish the full Firebase deployment, complete the remaining authentication work, and validate the production behaviour of:

• financial records;
• weekly and monthly budget closures;
• overlapping reward attribution;
• SynthCoin transactions;
• rotating offers;
• module purchases and replacements;
• damage and repair events;
• level recalculation;
• responsive user flows.

A central part of that work is cost-aware scaling.

Rather than treating scale as an abstract future problem, we want to understand which operations are performed most often, which data needs immediate consistency, which values can be derived, and which processes can be batched or simplified. The goal is to preserve the full design without allowing infrastructure costs to grow faster than actual user value.

After deployment, the next major step will be real playtesting.

The formulas and systems are internally consistent, but balance can only be validated with usage data. We will need to measure:

• time to first cyberdeck purchase;
• SynthCoins earned versus spent;
• repair-to-purchase ratio;
• frequency of module destruction;
• distribution of module families;
• how often users experience purchase locks;
• whether users understand overlapping rewards;
• whether the visual layer improves engagement without reducing financial clarity.

Those findings will guide the first balancing pass.

Beyond the MVP, the system is designed to support future expansions such as achievements, opt-in leaderboards, and seasons. Those features will only be added if they reinforce the core purpose of the application: helping users build healthier financial habits through visible and meaningful progress.

The next milestone is not to make Budget Runner larger. It is to make the complete system deployable, sustainable, and genuinely useful outside the local development environment.

Built With

• codex
• docker
• express.js
• firebase
• gpt-5.6
• jwt
• node.js
• postgresql
• react
• tailwind
• typescript
• vercel