AI product experiment that resulted in 421 leads in the first month

Amount, category, who paid, how it splits. The new-expense sheet is built to use with one hand while you are standing at the checkout.

If logging an expense takes more effort than the expense is worth, people stop after the first try. Most of the work here went into keeping that habit alive past the first week. Making it look nice was secondary.

Design and code: instead of using Figma, I started using VS Code with Claude Code. From day one I was building via the terminal.

Solo product builder: that way I could test the app working and iterate doing my own usability testing, share it with my family, and have other people try what I built right away.

Solving real problems: I designed an expense sheet one morning, had it live by the afternoon, and watched people use it that night.

Shipping a product is mostly not coding. Writing FamigliApp was maybe 5% of the work. The other 95% is getting it in front of the right people and getting them to actually want it. AI makes that 5% much faster. It does not really help with the 95%.

• Distribution — getting discovered. SEO, launching in multiple locales, a separate landing per persona. If nobody sees the product it has zero users, however clean the code is.
• Desirability — making people want it. Positioning, copy and real lifestyle photos. This is all design work, and it is what decides whether people stick around.
• Legal and accounting — what you do not vibe-code. Terms, privacy and data handling, billing, taxes, invoicing.

The hard part has moved. It is not writing the app anymore, it is the strategy, the taste, and having the right people around you for the parts you cannot do yourself.

This is the part I am most curious about long term. Instead of a separate landing per campaign, which racks up design debt fast, I built one bento system that handles all five personas with the same components.

Tokens are three layers. Primitives are raw, context-free values that no component reads directly. Semantic tokens carry meaning and are theme-aware, and they are the only layer the UI touches. Component tokens are contextual, composed from semantic values plus the spacing scale.

Every grey is the same ink hue at different opacities, coherent by construction rather than arbitrary hex. Never pure white. Typography is Geist at three weights only, 400, 500 and 600, with hierarchy coming from size and letter-spacing rather than weight. Negative letter-spacing scales with size: headlines compress, body stays open.

Shared household money meant I could not get data isolation wrong. Every household is walled off at the database level with row-level security, on every table, so one household can never see another’s expenses, tasks or balances. It is the default, not a setting someone has to remember to switch on.

It is a mobile-first PWA with web push rather than a native app. One codebase, every deploy live instantly, no app-store reviews and no two native apps to keep in sync.

This is still early, so I would rather end on the open questions than a victory lap. I still think narrowing the audience down to couples was the right call, but I have not actually proven it converts better yet.

What I want to do next is measure the couples loop properly: where people drop off in the task and expense flows, and how it compares head to head against the old version. That is the only way I will know if the new flow is genuinely easier or if it just feels that way to me because I am the one who made it.

The thing I am sure about is the speed. With Claude Code and Figma MCP, going from a design idea to something real users can touch takes hours now. I designed an expense sheet one morning, had it live by the afternoon, and watched people use it that night. That still catches me off guard, and I am still learning how to use it well.