DokladBot product teardown: how I scope an AI product as a solo founder

The short version: DokladBot turns a photo of a receipt into a posted accounting entry. The product job is not the model. The model extracts. The product is everything around it that makes a small business owner trust the output enough to click "post" without re-checking. This teardown is how I scoped that as a solo founder who also writes the code.

The problem

Czech freelancers and small firms drown in paper. Every receipt and invoice has to be read, categorized, matched to a payment, and posted into one of three accounting systems. It is slow, it is boring, and it is exactly the kind of structured-but-messy work an LLM is good at and a human resents. The pain is recurring (every month), the data is structured (amount, VAT, supplier, date, company ID), and the downstream action is concrete (post it). That combination is what made it worth building.

The user and the job-to-be-done

The user is not a developer and does not care about AI. They care about one thing: spend less time on paperwork without getting the numbers wrong. So the job-to-be-done is "make my receipts disappear into my accounting correctly." Everything in the product is judged against that sentence. A feature that adds a setting but not trust loses.

The one metric that matters

Not accuracy in isolation. The metric is the share of documents that go from photo to posted with one tap and no correction. That single number captures extraction quality, category suggestion quality, and UI friction at once. If it goes up, the product is doing its job. If accuracy is high but people still re-check everything, the number stays low and the product has failed even though the model "works."

The key decisions

AI is the core, not a feature. Extraction pulls amount, VAT, supplier, date, and company ID from a photo and proposes the accounting category. I built it as an AI-native product, not a form with an AI button.

Reliability over cleverness. A single wrong number erodes trust faster than a missing feature. So the system has multi-model fallback, rate-limit-aware retries, cost control, and a human-in-the-loop step where the model is unsure rather than guessing confidently.

Meet the data where it already is. Ingestion is built end to end on a private inbound-email inbox per company and a WhatsApp path, because that is where receipts already live. The best UX is the one the user does not have to learn.

Ship the integrations that cover the market, not all of them. I shipped to the three accounting systems that cover most of the Czech market rather than chasing the long tail. Coverage is a product decision, not an engineering one.

What I deliberately did not build

This is the part that separates product thinking from feature-listing. I did not build: a mobile app (the email and WhatsApp paths removed the need), a custom OCR model (the LLM does extraction well enough that training one would be effort spent in the wrong place), multi-currency at launch (the user is Czech), and a dashboard full of charts nobody asked for. Each "no" bought focus on the one metric.

The roadmap, framed by leverage

The roadmap is ordered by impact on the one-tap-posted metric, not by what is fun to build: tighten the human-in-the-loop threshold so fewer documents need review, expand bank payment matching, and harden the edge cases that currently force a correction. Growth work (acquisition on Meta, Google, Seznam) sits alongside, but the product bet is that the one-tap rate is what makes the growth worth paying for.

Why this is a product story, not an engineering one

I wrote the code, but the interesting decisions were product decisions: what the metric is, what not to build, where to put the human in the loop, which integrations matter. The model is a commodity. The product is the judgement around it. That is the work I want to do more of.

DokladBot is live in beta and going to market. If you want the same thinking applied to your AI product, get in touch.