We Built Invoicing in 3 Days Because a Customer Asked for It

It was a Tuesday afternoon when the message came in. An event agency in Stockholm — one of our paying customers — had landed a corporate client that wanted to send their employees to a private networking dinner. A few hundred tickets, professional venue, the kind of event that looks good on a company card.

The problem: the corporate client needed an invoice. Their finance department didn't do card payments for vendor purchases above a certain threshold. That's just how large companies work. And our platform, at that point, only supported card payments at checkout.

The agency's message was polite but clearly anxious: "This is a good contract for us. Is there any way to handle this?"

I sat with it for a moment. Then I started building.

Three days later, invoicing was live.

What "Customer-Driven Development" Actually Means

There's a version of this phrase that's become meaningless through overuse. Every product team claims to be customer-driven. Every roadmap says it reflects customer needs. But when you actually talk to the people building those products, you find out what's really happening: there's a quarterly planning cycle, a prioritization framework, a committee that weighs requests against strategic themes, and somewhere at the bottom of all that, a ticket in a backlog that will get reviewed in six months if the stars align.

That's not customer-driven development. That's customer-informed speculation with a long lag time.

What I did was different — not because I'm smarter than product teams at bigger companies, but because I'm a solo founder running a startup out of KTH, and I don't have any of that machinery. When a paying customer tells me they need something, the decision chain is exactly one person long.

The Invoicing Problem Was Real

To be clear, I hadn't ignored invoicing out of negligence. It genuinely hadn't been a priority because most of our customers — event agencies, student organizations, corporate event teams — run ticketing where attendees pay directly. Card at checkout, stripe confirmation, done.

But corporate procurement doesn't work like that. When a company wants to purchase a block of tickets for their team, their finance team often needs to receive an invoice, approve it through an internal process, and pay it within 30 or 60 days. It's a completely different payment flow, and it's completely normal in B2B contexts.

The agency's request made me realize: as we move upmarket toward larger clients and more professional event operations, this was going to come up again. It wasn't an edge case. It was a gap I'd just been lucky enough not to hit until now.

Three Days of Focus

I won't pretend the build was effortless. Three days is fast, and fast requires tradeoffs. You have to decide very quickly what's in scope and what isn't. You have to resist the temptation to build the perfect, fully generalized version of the thing when what the customer actually needs is a working version of the thing.

What I shipped was: the ability to create a manual invoice for a ticket order, send it by email as a PDF, mark it as paid when the bank transfer came through, and have that reflected in the event's sales dashboard. Clean, functional, auditable.

What I didn't build: automated payment reconciliation, multi-currency invoice templates, installment plans, or any of the ten other things that would've made it "enterprise-ready" by someone's definition. Those might come later. What mattered on day four was that the agency could send their corporate client a proper invoice and close the deal.

They did. The client paid. The event ran.

The Customer's Reaction

When I told the agency it was ready, their response was something close to disbelief. Not because it worked — they expected it to work if I said it was ready — but because of how fast it happened.

"We've been using another platform for two years," the agency contact told me, "and we've had feature requests sitting in their system since we signed up. We'd basically given up expecting anything."

That's the thing nobody talks about when they compare startups to established platforms. Yes, the big platforms have more features in aggregate. They have years of accumulated functionality. But they also have years of accumulated process, and that process means that the distance between "a customer needs X" and "X exists in the product" is measured in quarters, not days.

For us, it was three days. And that difference in response time compounds over months and years into something that's genuinely hard to replicate with money.

Why Big Platforms Move Slowly

It's worth being fair here: large platforms aren't slow because they're incompetent. They're slow because of structures that make complete sense at their scale.

When you have thousands of customers, you can't build every request. You have to prioritize, and prioritization requires a framework. The framework requires input from multiple stakeholders. The stakeholders have competing views and varying levels of influence. The winning requests get estimated, scoped, designed, reviewed by legal and compliance and security, developed across multiple teams with dependencies, QA'd, documented, and then released in a coordinated update cycle.

All of that is rational given their context. But the side effect is that any individual customer — even a good one — is waiting in the same queue as everyone else, and the queue moves on the platform's schedule, not theirs.

We don't have that queue. When a paying customer tells me something is blocking them, I can decide immediately whether to build it, and if I decide yes, I can start that afternoon.

The Discipline Behind the Speed

I want to be honest about the other side of this, because it's easy to make rapid customer-driven development sound like just saying yes to everything. It isn't.

There are requests I've declined or deferred. A student organization once asked for a feature that would've made sense for their very specific setup but would've added permanent complexity to the codebase that no other customer would ever use. I said no, and I explained why, and they understood.

The filter isn't "can we build this?" It's "does this make the platform genuinely better for the customers we serve?" Invoicing passed that test because corporate payment flows are standard, not exotic. Other requests don't pass it, and those go into a different pile.

The key is having a clear enough sense of your product vision that you can make these calls quickly. If you're uncertain about what your platform is trying to be, every feature request becomes an existential debate. If you're clear, the decisions are usually fast.

Other Times This Has Worked

Invoicing wasn't the first time we built something because a customer asked for it on short notice. A corporate event team running internal conferences needed the ability to set up separate ticket allocations for different departments, with reporting broken out by department. We built it. An event agency running festivals across multiple cities wanted to manage all their events from a single dashboard rather than switching between accounts. We built that too.

None of these were on any roadmap. All of them are now features that new customers find valuable without knowing the origin story.

That's how a product grows when you're actually paying attention to the people using it. Not by predicting what they'll need, but by responding when they tell you.

Speed Is the Superpower

There's a version of startup advice that's all about moving fast before you're big enough to move slowly. Get to scale, then add process. It's sensible advice in a lot of contexts.

But I think there's something worth protecting about the speed itself — not just as a phase to get through, but as a genuine advantage worth fighting to preserve as long as possible.

No amount of funding replicates the experience of a customer asking for something on Tuesday and having it on Friday. That's not a feature you can buy. It's a direct function of how many people are in the decision loop and how much trust you've placed in the people closest to the customer.

For us, right now, that's the founder. It won't always be. But while it is, I'm going to keep answering those Tuesday afternoon messages and seeing what we can build.

The agency still uses Eventfold. Their corporate client came back for another event. The invoice feature has been used by three other customers since we shipped it.

Three days well spent.