Projects BTW Terug
VAT back on a home battery
Buy a home battery in the Netherlands and you pay 21% VAT on the hardware and the installation. Most people can claim it back and never do, because the route runs through a tax office that was not built for them. BTW Terug turns that into three uploads.
The money
It tells you whether you qualify before it asks for anything.
A home battery is a large purchase and 21% of it is VAT. Most of the people who paid it can claim it back, and most of them never do, because finding out is harder than forgetting about it. The average claim is around 3,465 euro.
So the first thing the app does is a qualification check, before an account exists and before anyone pays. The battery has to be new rather than second hand, bought within five years, and installed in the Netherlands. Nobody gets to the payment screen without passing it.
bought new, not second hand required bought within five years required installed in the Netherlands required Fail any one and the app says so, rather than taking the money and finding out later.
The intake
It asks one thing at a time, and fills the tax form itself.
A VAT reclaim is a form nobody wants to read. The app never shows one. It asks for personal details, the installation address, the invoice and the documents, in that order, one step at a time, and saves as it goes so a session can be abandoned at midnight and picked up at breakfast.
The tax office document is then generated from those answers rather than typed. The customer uploads an invoice, proof of payment and identification, and the dossier assembles itself. The VAT figure is calculated from the invoice rather than estimated, so the number on screen is the number being claimed.
0 do you qualify checked first 1 who you are 2 where it is installed 3 the invoice 4 choose a package payment 5 upload documents 6 submit Auto-saved at every step. The tax form is generated from this, never typed.
The assistant
It already knows where you are in your own application.
Every applicant gets an assistant that has read their dossier. It knows their name, which step they reached, which documents are still missing, which package they bought and what their claim is worth. A question about “my invoice” is answered about their invoice.
It answers from a curated knowledge base rather than from open recall, and it knows today’s date and which tax quarter that falls in, because a VAT deadline is the one answer that has to be right. When it cannot answer, it hands over to a person instead of improvising, and it can put the next step on screen as a button rather than describing where to click.
who you are name, package, status how far you got steps completed your dossier invoice, amount, documents today date, tax quarter, deadlines what it may say the knowledge base where it stops escalate to a person Grounded in your file, not in general recall.
The back office
Payment, dossier and mailbox are one system, not three.
Payment runs through iDEAL. When the bank confirms it, that alone moves the dossier: the payment is verified, the record updated, the customer emailed and the office notified, without anyone watching for it.
Behind that sits the side the customer never sees. Every dossier has its status, its tasks and its notes in one place. Customer email arrives in the same screen as the file it belongs to, so a reply is written next to the invoice it is about rather than in a separate inbox. Each status change sends the applicant a notification and an email, so nobody has to ask where their claim has got to.
bank confirms
──► payment verified
──► dossier updated
──► customer emailed
──► office notified
No one is watching for it.
Concept to business
Eight days from an empty repository to taking payments.
The first commit was on 13 January. The application was deployed and accepting real payments on the 21st. In that window it went from an idea about a tax rule to a business a stranger could buy from, built by one person.
That is four products, not one: the site people find, the application they use, the office that processes their claim, and the writing that keeps the whole thing findable. A market this specific is won on search, so articles are researched, written and published on a schedule rather than when somebody remembers, and illustrations are generated rather than licensed. A stock photo budget is a poor reason to publish less.
None of that is remarkable because a model was involved. It is remarkable because the gap between deciding and shipping was eight days, and because the thing still runs without a team. That is the part we are actually selling.
13 Jan empty repository 21 Jan deployed, taking payments What shipped the marketing site the application the back office the content engine One person. Still no team.
Where the line sits
It tells you the condition before it takes your money.
The claim rests on the applicant counting as someone who trades energy, which is what makes the VAT reclaimable at all. In practice that means moving to a dynamic energy contract, and it is a real change to how a household buys electricity.
A service paid per claim has an obvious reason to mention that late. This one puts it before the purchase, because a claim that collapses at the tax office costs the customer more than the fee ever saved them. The filing itself stays with a person: the assistant prepares, explains and chases, and a human signs off what goes to the tax office.
“A claim that collapses at the tax office costs more than the fee ever saved.”
Why the condition is stated before the purchase
Something in your field that a professional still does by hand?
Knowledge that lives in one person’s head, a judgement made the same way every time, and a form nobody wants to read. That is the shape we look for.