Designing an easier way to understand and maintain everyday spending
An independent budgeting product designed to reduce the friction of recording expenses, understanding spending patterns, and maintaining financial habits — with an AI advisor as a supporting feature, not the point.
- Role
- Independent — product, design & engineering
- Platforms
- Android
- Key result
- Offline-first — Local capture, syncs when online
- observation symbol
- observation
- open question symbol
- open question
- decision symbol
- decision
- rejected symbol
- rejected
- progression symbol
- progression
- result symbol
- result
Observation
Recording an expense is easy. Keeping at it is the part everyone quits.
Budget Buddy is an independent budgeting product I'm designing and building end to end. The intended user is an ordinary person who wants to keep a handle on everyday spending without turning it into a chore — not an accountant, and not someone who enjoys spreadsheets.
Problem
Budgeting apps rarely fail at recording an expense — they fail at getting people to keep doing it. Manual entry is tedious, categories feel like admin, and the numbers rarely turn into anything a person actually acts on. The friction, not the feature list, is the real problem.
Context · This is a solo product built to practise product thinking end to end: deciding what the app is for, designing the flows, building it, and running a real delivery pipeline — not just writing screens.
Ownership
Built solo, so there's no team outcome to separate out — everything here is individual work. That's stated plainly rather than dressed up as more.
What I owned
Personally executed
- Product direction and scope
- Interaction and visual design
- Full Flutter implementation on Clean Architecture (repository pattern + DI)
- Authentication and data layer
- The AI advisor integration, kept behind a service abstraction
- The CI/CD pipeline and versioned APK distribution
Constraints
- Solo project built around other commitments, so scope has to stay honest.
- No real users yet — every claim about behaviour is a hypothesis, not a result.
- The AI advisor must stay a supporting feature; it can't become a dependency the core budgeting relies on.
Questions
- What's the smallest amount of effort a person can spend to record an expense and still get value back?
- Do categories and monthly budgets reduce friction, or quietly add admin?
- What can an AI advisor say that's genuinely useful — versus restating numbers the user can already see?
- Where should data live so capture is instant but nothing is lost?
Decisions
Entry stalls whenever the network does — the wrong default for a habit product.
Instant entry, resilient to bad connectivity.
Kept as a supporting advisor instead — the product still works if the AI is removed.
Content needed — Options considered
Confirm the actual data stack. Portfolio + résumé describe Firebase/Firestore + Gemini + CI/CD; the public repo README currently describes GetX + Hive (local-only). Align the copy to whichever is current.
Lead with reducing entry friction, not with the AI advisor.
- Why
- The product's value can't hinge on a model call.
- Rejected
- AI-first positioning.
- Trade-off
- Less flashy, but the core budgeting stands on its own.
- Outcome
- Budgeting works fully with the advisor switched off.
Keep the AI advisor behind a clean service abstraction.
- Why
- The advisor should evolve — or be swapped out — without touching core logic.
- Rejected
- Calling the model directly from feature code.
- Trade-off
- A little extra indirection.
- Outcome
- The AI stays a feature, not the foundation.
Structure the app on Clean Architecture from the start.
- Why
- Features should stay isolated and testable as the app grows.
- Rejected
- Shortcut architecture for a solo app.
- Trade-off
- More upfront ceremony.
- Outcome
- Repository pattern + DI keep modules independent.
System
- Clean Architecture: repository pattern + dependency injection so features stay isolated and testable.
- Authentication and cloud data via Firebase (Auth + Firestore) for cross-device continuity.
- Offline-first capture: expenses save locally first and synchronise when a connection is available.
- Category and monthly-budget model that updates totals as transactions land.
- AI advisor integrated behind a service abstraction, so the AI layer can change without touching budgeting logic.
- GitHub Actions CI/CD that builds a versioned APK for distribution on each release.
- User records expenseamount, note, category
- Saved locallyinstant — no network required
- Totals updatecategory + monthly budget recalculated
- Sync when onlineFirestore reconciles the data
- Summaries / insightsadvisor turns numbers into plain-language guidance
Delivery pipeline: Flutter repo → GitHub Actions build → versioned APK → release metadata update → website repo update → Vercel deployment.
Content needed — Visual walkthrough
Real screenshots of expense entry, category budgets, and the monthly view → public/images/projects/budget-buddy/ then set `cover` and `gallery` to real images.
Results
- A working, full-stack app with offline-first capture, an AI advisor, and an automated build/distribution pipeline.
- Not yet published — this is active development, so there are no adoption or behaviour results to report.
Reflection
- Keeping the AI behind an abstraction stopped it leaking into core logic — the advisor is a feature, not the foundation.
- For a habit product, the hard design work is friction, not features.
- Faster expense capture (fewer taps, smart defaults) before adding more analysis.
- Validate the core hypothesis with real users before building richer insights.
- Ship a first public release.
- Then test whether lower-friction entry actually improves consistency — the current hypothesis is that it will, but it needs user testing.