Centwise.
An end-to-end personal-finance app, designed and built solo. The brief I gave myself: ditch the spreadsheet metaphor. Money should feel calm, not accounted for. Currently used by members of Home Groningen after being shown live during a Sunday sermon.
/ at a glance
What was built.
- 01Custom data model in Postgres, surfaced through a typed Supabase client end-to-end.
- 02Auth and per-user data isolation handled at the database layer, not in app code.
- 03Manual tagging on top of categories. Users group transactions their way, not the algorithm's way.
- 04Design language shared with the rest of the Zieck portfolio. Same tokens, different product voice.
01 / problem
The brief.
Most budgeting apps are spreadsheets in disguise: categories, columns, monthly totals. That model fights how people actually experience money, which is as moments, not rows. The product question was simple but unforgiving. Could a finance app feel like a journal instead of a ledger, without losing the rigour underneath?
02 / process
Double Diamond.
Walked the project through the Double Diamond, the same framework Dutch public-sector design teams use. Two cycles of diverge-then-converge: first on the problem, then on the solution.
01 / Discover
The problem space
02 / Define
The problem itself
03 / Develop
The solution space
04 / Deliver
The solution itself
01 / Discover
Heard the recurring complaint from people in my own community at Home Groningen: budget apps make you feel like a bookkeeper. Everyone had tried one and quietly dropped it. Gathered intel through informal conversations with potential users about how they actually tracked, or quietly avoided tracking, their money. The pattern was consistent across the people I spoke to.
02 / Define
The real problem wasn't a missing feature. It was a tone mismatch. Finance apps spoke accounting at people who wanted journaling. Reframed the brief: build something around thirty members of the Home Groningen community would open more than once. A tight, identifiable cohort kept the design honest and ruled out a thousand other features that didn't serve them.
03 / Develop
Built a deliberately small clickable prototype with the chosen flow. Brought it back to the same group plus a few new faces and watched them use it. Feedback hit hardest on first-use moments and on language that read like accounting. Rewrote those parts, simplified the entry flow, and made tagging the centerpiece instead of categories.
04 / Deliver
Launched where the users already were: live during a Sunday sermon at Home Groningen, with sign-up available the same morning. The app is in active use by members of the church. Roadmap decisions are now driven by what they actually ask for.
03 / decisions
Forks in the road.
The interesting part of any build is what got picked, what got rejected, and why. Here are the ones that mattered.
/ decision 01
Manual tags over auto-categorisation
Auto-categorisation is the obvious move. It is also the thing that makes users distrust budgeting apps the moment it gets one transaction wrong. Adding manual tags as a parallel layer keeps auto-categorisation honest and gives users a way to model their own life, a holiday or a project, without fighting the schema. This came directly out of the prototype feedback rounds.
/ decision 02
Recent-activity-first, categories second
The category-first dashboard I originally sketched died the moment testers couldn't recall categories from memory but could vividly recall context. The dashboard now leads with what just happened. Analysis sits one tap deeper for the few users who want it. A classic case of letting feedback kill a pretty design.
/ decision 03
Ship to a real audience before polishing
It would have been easy to keep the app in private beta until every flow was perfect. Instead I demoed it live during a sermon and let real church members start using it. The feedback from the first week reshaped the priority list more than three months of solo polish would have.
Where it lands.
Live with members of Home Groningen using it for real. The roadmap is now driven by what actual users ask for, not what I imagine they'd want, which is the entire point.
/ reflection
What this taught me.
Launching inside a community that already trusts you saves months of imagined-user debate. One week of real feedback reshaped the priority list more than three months of solo polish would have. The flip side: the trust only buys you the first conversation. Real users still need genuinely good design after they walk in.
Up next
