Zeller Invoicing did $6m in gross transaction value in its first year, and the invoice creation screen is still some of the UI I'm most proud of. This is the story of everything we didn't see while we were making it.
The short version is that we set out to build one feature and shipped four. Invoicing, Contacts, Inventory and Quotes, where the roadmap had a single line item. That sounds like a win, and in the end it was one. But we didn't find those features by planning for them. We found them in a spec review, weeks after the design had been signed off, at the point where finding them was most expensive.
The reason is simple enough to say now. We were excited to jump straight to the solution, so that's where we went. Months on the invoice creation screen alone: a Mailchimp-inspired accordion that let you build an entire invoice on one page, section by section, without ever leaving it. It got very good. It was also, though nobody said this out loud at the time, a single node in a system that nobody had drawn.
This is what that cost, and what I do differently now because of it.
Months on one screen felt like progress
It's worth being precise about how a team spends months on one screen, because nobody ever decides to. It happens by a series of individually reasonable weeks.
We worked closely with the CEO, who reviewed details carefully and held a high bar for the UI. That bar is a good thing, and I'd defend it. But there was no discovery phase, no customer interviews up front, no journey maps pinned to a wall before pixels were pushed. The philosophy at the time was build, ship, and let real customers push back. It's a legitimate way to work and it suits a certain kind of team and stage.
It has a side effect, though. When you don't have customer inputs to anchor decisions, every call starts to feel like a debate about taste. And debates about taste don't get resolved. They get outlasted.
So the accordion got better, and better, and better. Every round was defensible on its own terms. Each one made the screen genuinely nicer than it had been the week before, which is precisely why none of them ever felt like the moment to stop and ask a bigger question.
That's the trap, and I've watched it catch better teams than ours since. Refinement is the easiest thing in the world to mistake for progress, because it's the only part of the work you can actually watch improving. The screen in front of you gets visibly better every week. The part of the system you haven't drawn yet stays exactly as invisible as it was on day one.
By the time we tested, we were too committed to listen
There was a moment this could have been caught, and what stings slightly is that we reached for it ourselves. Nobody had to tell us to validate the solution. We wanted to. We just acted on the instinct at the wrong point in the project.
By the time we were ready to put the accordion in front of people, it had been through months of review. It had a name. It was "the design." Defending it had quietly become part of my job. Walking it back would have been expensive, politically far more than practically, and everyone in the room understood that without anyone needing to say it.
Which meant the test could only really confirm. Any finding big enough to matter was a finding we couldn't afford to act on, so the exercise had quietly changed purpose somewhere along the way. It had stopped being a question and become a formality.
We tested when we were proud of it. We should have tested when we were embarrassed by it. A scrappy version validated early is worth more than a polished one validated late, and not because the feedback is any better. The feedback is the same. It's that you can still afford to hear it.
The spec is where the rest of the system shows up
So the accordion went to sign-off intact, and for about a week it looked like we'd got away with it. Then we started preparing the work for development, and the rest of the product fell out of it.
We needed Contacts, because an invoice needs a Payer, and Payers need somewhere to live: a real list of your customers rather than a text field. We needed Inventory, because plenty of the businesses we were building for sold physical things and expected to pull them straight onto an invoice. We needed a digital payment portal, because an invoice you can't pay isn't a product. We needed email journeys, because invoices get sent, chased, reminded, receipted. We needed PDFs, because a PDF is what the recipient actually opens.
Every one of those needed design. None of them were in the months we'd already spent.
So we rushed them, which is the part I'd take back if I could take back one thing. Supporting features designed under time pressure, at the end, to catch up to a screen that had been allowed to take as long as it liked.
And that's the trade I didn't understand I was making. The months weren't spent on the wrong screen. They were just badly distributed. Half of that time, moved from the invoice UI to the rest of the journey, would have cost the accordion very little and saved almost everything that came after it.
A feature is a flow, not a node
None of this was unknowable, which is the uncomfortable part. It wasn't hiding. We just never went looking, because invoicing looks simple. You make an invoice, you send it, you get paid.
It isn't simple at all. An invoicing tool is a creation experience, an invoice list, the document the recipient receives, a payment mechanism, reminders and status changes, edits and voids, and reporting sitting on top of all of it. We started designing the front of that and never asked what the rest of it was.
When we finally did map the journey, it paid for itself within a day. It surfaced a feature we hadn't planned for at all: once we understood how people who send invoices actually work, it became obvious that many of them send a quote first, a step sitting entirely outside our original scope. That became Quotes, a distinct feature that fed naturally into invoice creation. We'd never have seen the need for it from inside the invoice screen, no matter how long we stared at it. And we stared at it for months.
Journeys first, screens second. Even a rough sketch of the full loop is worth more than a polished version of one corner of it.
We shipped four features and only planned one
The part I've come around on is what all of that scrambling actually produced, because it's easy to tell this story as a failure and it wasn't one. We didn't ship an invoicing tool. We shipped Invoicing, Contacts, Inventory and Quotes, four connected features off the back of a roadmap line that said one. In its first year the thing did $6m in gross transaction value.
And the connections weren't incidental, which is what I keep coming back to. Contacts existed because Invoicing needed somewhere for customers to live. Inventory came into it because Invoicing surfaced the problem. Those seams are exactly what made the product feel like a platform rather than a folder of tools, and not one of them would have come up if we'd treated Invoicing as self-contained.
So the ecosystem was real, and it was good, and it's still the strongest thing about the finished product. We just found it under duress instead of finding it on purpose. The question that would have got us there in week one isn't a hard question: what does this feature unlock, share, or borrow from the rest of the system? The good ideas tend to live at those edges. We reached them anyway, at the worst possible moment to be reaching them.
What I took from it
Strip out the specifics and three things stayed with me. The build-and-ship philosophy taught me to be less precious about my work. The absence of research taught me how much I'd been leaning on it without realising. And the close scrutiny on every detail taught me when to hold ground and when to fold.
I wouldn't change Zeller's way of working. It's a real philosophy, it suits the company, and the numbers came out fine. What I'd change is when I zoomed out.
Because that's what I actually got wrong, and it took me a long time to name it properly. I treated the wide view as preparation. Something you do before the real work starts, and therefore something you can skip when the team is moving fast and the solution already feels obvious. It isn't preparation. It's the thing that tells you what you're designing. We spent months designing an invoice screen when what we were building was a billing system, and no amount of refinement on the screen was ever going to tell us that.