Finhudas

TL;DR

• A mobile accounting app for freelance drivers, most of whom had never done bookkeeping, on a phone they used daily but were far from fluent with.
• Accounting is hard on its own. Teaching it through a phone someone already struggles with does not add difficulty, it multiplies it.
• Validated before it existed. A broken wireframe screenshot in a Bolt-driver Facebook group pulled so much interest that Bolt themselves reached out.
• Accounting-accurate meant a heavy first journey: every new driver had to upload a CSV and two more documents just to log their income.
• My first build with AI, back when AI was weak. The answer was constraints: a design system simple enough for a machine to code, shipped in under six months.
• One external link in the KYC step caused a 60% churn. Moving the step after registration fixed it.
• Next, income entry becomes fully automated, which deletes the heaviest step in the product.

A broken screenshot

Finhudas did not start from a plan, it started from a pattern. Kurohudas, our fuel app, kept surfacing the same wish right next to it: drivers wanted to track expenses, and a lot of them drove for Bolt. So we ran the cheapest test we could. We dropped a raw screenshot of an ugly wireframe that barely worked into a Facebook group for Bolt drivers, and waited.

The response was immediate and loud. Loud enough that Bolt themselves reached out to ask about expense tracking and accounting. We had our validation before we had a product. You do not need something polished to find out whether anyone wants it. You need something real enough for people to react to.

Two kinds of illiteracy

Here is the sentence that shaped everything. Most of the people we built for had never done a day of bookkeeping, and many used a phone daily without ever feeling fluent on it, often older and straining to read a small screen. Accounting is hard on its own. Teach it through a device someone already fights with, and the difficulty does not add, it multiplies.

So we quietly stopped building a fintech app and started building something closer to an educational one. Not cheesy, and not a course, but a product that teaches as it goes, one plain-language decision at a time. We were teaching an unfamiliar subject to someone who never signed up for a lesson, and almost everything hard about Finhudas comes from that.

The rules that weren't simple

The first version was not the hard part. Scoping an MVP to what a freelance driver actually needs was straightforward enough. The brutal part was the accounting itself: the rules, the laws, and every edge case for what can and cannot be counted as an expense. All of it had to live inside the app, correctly, every time.

And accuracy has a cost you pay on day one. Because every trip has to land in the accounting journal, the very first thing a new driver does is log their income by uploading a CSV and two more documents. Correct on paper, and a brutal welcome on a phone held by someone who would rather be driving.

Building with AI, and its limits

Finhudas was the first product I built almost entirely with AI assistance, back when AI could do far less than it does in 2026. I still designed every screen in Figma by hand and did much of the research myself. But that limitation shaped the product for the better. To let the AI build, we kept the design system radically simple: a small set of plain, repeatable components, quick to code and easy to scale. The result was not pretty, but it was passable, and for an MVP that was plenty. It let two people with full-time jobs ship in under six months.

It also taught me where AI still breaks, and those limits hold in 2026, even with models as capable as Fable 5, Opus 5, or Sol. It is weak at creative layout, at UX judgment, and at catching every edge case. Its strength is that constraints fix most of that. Give a model your design system and a problem described as close to reality as possible, and it stops drifting. Hand it a template and it performs; leave it guessing and it behaves like it has no context. Context is your design system plus an honest account of the real problem. A PRD helps, but only if you truly understand that problem. A vague one just launders the vagueness.

Trusting the statistics

Then the mistake, and it is a good one. It lived in onboarding, in the KYC step. The trigger was the SBS scheme: pay a foreign EU company for a service and you owe reverse VAT, which drags in an SBS obligation, which only applies once you are registered. So I added a check. If a driver was not registered, we showed a short guide with a link out to go and register.

The official data, VMI's own numbers included, said most drivers already were. They were not. People tapped that link and never came back. One step, a 60% churn. The fix was almost embarrassing in its simplicity: pull the step out of onboarding and move it to a guide that runs after registration. Never send a user to an external link during onboarding or KYC. And never trust a statistic, however official, over the users in front of you.

Guiding without a tutorial

Live demos at a Bolt driver event showed how much age and technical literacy shape the experience: one elderly driver struggled just to read the screen. With a product this complex and an audience this varied, guiding the user through the journey is not optional. But the guide cannot feel like a tutorial, or people tune it out. Our first attempt leaned on Shepherd.js, and it moved very little.

We iterated on it from there. In the end we are retiring it anyway, because income entry is about to become fully automated, which quietly removes the very step the guide was there to hold people through. The best guidance is the step you get to delete.