Prism: A Personal Money OS I'm Building for Myself
Every budgeting app makes you file your spending into their categories. I wanted the opposite: a money system shaped around my own taxonomy, fast enough to log a transaction in under three seconds, that I'd actually use every day. Prism is that build: dogfood-first, with an AI omni-bar that turns '240 lunch' into a filled-in entry I just confirm.
- role
- Product + design + build (in progress)
- stack
- Next.js · TypeScript · Supabase · PWA · Vercel AI SDK · Product design · Personal finance
- status
- experiment
How I got here
I've tried the money apps. They all make the same quiet demand: bend your spending to fit their categories. My real financial life doesn't look like their dropdown. I already had a taxonomy that made sense to me, years of it, living in a wallet app and a spreadsheet, and no product would just use it.
So the goal wasn't "a better budgeting app." It was narrower and more honest: the smallest money tool that could replace my wallet app and my spreadsheet for daily entry, using my real categories from day one, that I'd keep using for seven straight days without falling back to the old tools. Dogfood first. Everything else comes after that bar is cleared.
How I thought about it
I made myself write the scope down before writing a line of code, and I was strict about what wasn't in v0.1: no budgeting math, no reports, no wealth dashboards, no marketing site. The spine is only two things: a category engine seeded from my own real data, and a ledger that rolls those categories up. Every fancier idea (envelopes, Zakat, tax, net worth) is just something that reads the ledger later, so the ledger has to be right first.
The one metric that mattered was speed. If logging a transaction takes more than about three seconds, I won't do it, and an untouched money app is worthless. So the core entry screen is a number-pad, not a form: amount first, category picker tuned for a deep tree, date defaulting to today.
I also drew a hard line on AI: it's an accelerator on top of the fast manual path, never a dependency in it. The numpad always works; the AI just makes it faster when it's there.
What I'm building
The foundation is a PWA (installable on my phone, with a PIN lock) backed by a database where my recursive category tree is seeded once from my own real CSV exports, so on first run it already speaks my language instead of a generic starter set.
On top of that sits the numpad-first entry flow: tap the amount, pick from a category picker built for recents-and-search (because my tree is deep), confirm. The ledger view groups transactions by day and does hierarchical rollups (select a parent category and it aggregates everything beneath it) plus a running month summary of in, out, and net.
The stretch layer, and the reason it's on this wall, is the AI omni-bar: type something like "240 groceries" in plain language, and a model turns it into structured data that pre-fills the numpad for a one-tap confirm. It never auto-saves. I always get the last look. It's AI as a speed boost on a path that already works without it.
Where it stands
Honest status: Prism is an early experiment, not a shipped product, and the interesting part is which half is done. The thinking came first, by hand: the PRD, the milestone plan, the personas, and the architecture pressure-tested before a line of it existed. Then I built the thing that built it: a set of defined personas, a CTO, a founder, a designer, a PM, each architected to make the calls its role would actually make, wired into goals and loops that let the run carry itself to a working product. Fable executed it. The judgment inside it is mine, encoded rather than supplied live.
So the code exists, and the architecture that produced it is the design work. What's missing is everything that makes a build trustworthy: I haven't verified it against the spec, audited what it actually shipped, or made the hundred small calls that turn a generated product into one I'd put my name on. That is a large chunk of work and it is the chunk I care about. Once a system you designed can produce a whole app without you in the loop, the bottleneck moves: the scarce skill stops being can you build it and becomes can you set it up to decide well, and can you tell whether what came back is any good. Prism is where I'm practising both on my own product rather than someone else's.
The reason I'm building it in public-adjacent daylight at all is that it's the clearest example of how I work on my own products: scope ruthlessly, dogfood before you dream, and let the thing earn each new feature by proving the last one.