//context
Fakturio started when I watched my wife generate invoices by hand in InDesign. What began as a simple generator to spare her that grew into a full product, and a way to stretch my own building muscle end to end.
Freelancers have to manage invoices, taxes, receipts, projects, and clients, but most tools either split this across apps or expose too much accounting complexity. I aimed Fakturio at a specific user: the freelancer who bills by the hour.
The product was built around one wedge: turning tracked hours into a sent invoice with as little friction as possible, while staying legally correct across Swiss and EU compliance needs. Design, frontend, backend, compliance logic, and QA were all mine.
//build depth
Product scope
0-to-1 solo
Commit history
~349
Unit tests
111
Compliance
~10 EU countries
//key design decisions
The hard part was not making invoices look clean. It was translating complex financial and legal rules into flows a non-expert can trust: supply dates, exemption text, Swiss QR-bills, gapless invoice numbering, multi-VAT, and currency formatting, all inside familiar product surfaces.
Customer, Project, Task, and Time Entry hierarchy. Currently showing Customer. Hover or focus a level to change the background ASCII pattern.
Earned task hierarchy
The Customer > Project > Task > Time Entry model was added only once tracked work needed structure before becoming billable invoice items.
Custom invoice branding
I was targeting designers, marketers, and creative freelancers, where a consistent brand matters. So I built a customizable invoice design rather than a single fixed template, letting users keep their invoices on-brand.
Public invoice creator as the front door
The acquisition wedge is a public invoice creator good enough to use on its own. People create a real invoice first, then the flow turns that finished work into an account, so sign-up feels like saving progress rather than a gate.
Features that take the financial stress off
From my own freelancing and from testing, the recurring anxiety was not knowing where you stand: am I about to cross the VAT threshold, how much tax will I owe? So I added banners that warn when users are near or over the VAT registration threshold, and a tax calculator that estimates taxes and social security based on canton.
//what testing changed
I ran 10+ moderated usability sessions with freelancers billing by the hour. The same problems kept surfacing, and each one drove a concrete product change, not a cosmetic tweak.
Time tracking matched how people actually work
Testers expected the timer to already be running, thought in sessions rather than entries, and wanted hourly rates pre-filled per client. I rebuilt tracking around inline timers, table and calendar views, live totals, and an active timer that shows task and customer context.
Turning tracked time into an invoice
"Create invoice" did not make sense to users: they expected time entries to sum automatically, and invoices ignored customer currency. Entries now group by task into clean invoice lines, and currency follows the customer.
A task layer between projects and time
I started with a simpler model: client, project, and time entries tracked straight on the project. But multiple testers said they do different kinds of work on one project and want to track each separately, so I reworked the architecture and design around a task layer (client > project > task > entry).
An invoice form non-experts can read
Field labels like "Invoice #" confused users, the description field was unclear, and VAT felt mandatory when it should not be. I relabeled to "Invoice Number", added a Name field, made VAT optional, tucked description under products, and added custom payment terms.
//validation & trust
For a financial tool, reliability is part of the UX. The product combines user validation with production hardening: usability tests, structured states, integer-money calculations, row-level security, test coverage, a CI/CD pipeline, readiness checks, and monitoring.
//the real goal
Fakturio is a capability proof, not a market-success story, and I'm upfront about that. The main goal was to train my building muscle, and I achieved it: a fully functioning product, designed and shipped end to end and alone. It now has a few active users running their invoicing on it weekly, which for a solo build is a real success. Distribution is paused; it does not claim product-market fit.
//my role
Everything. This is the point of the case study: product design, UX flows, UI system, frontend, backend, compliance logic, validation behavior, QA, and production-readiness all lived with one person.
//designer-builder loop
The work followed a ship, refactor, harden loop: first invoicing and account setup, then dashboard and state refinement, then projects, tasks, time tracking, and finally trust work like tests, Sentry, readiness checks, and structured errors.
//reflection
The lesson was that building was not the hardest part; distribution was. I cold-messaged more than a hundred freelancers on LinkedIn and fewer than ten replied, which made the startup risk concrete in a hurry. That, plus the post-AI flood of small tools, is why I now lead with what is worth building before treating engineering as the bottleneck.
