Building an event planning app: what failed and what finally worked
I started building an event planning app, Bonacube App, in 2020, right after my last major event in charge, the Lahti 2017 Nordic World Ski Championships. The first version planned events well but could not survive the changes of pre-production, so I parked it for five years.
The rebuilt version works because it separates the agreed plan from the moving plan: a frozen baseline, a live plan next to it, and every change logged with its budget impact. This is the full story.
Back in 2020 I quit my day job, just weeks before corona hit, and started building an event planning app. The app I wished I'd had as event director of the Nordic World Ski Championships 2017.
It worked, but not the way I wanted. After a few events I produced myself and a couple of pilot organisers, I made the heavy decision to park it. The most expensive failure of my business life.
This summer it came back. To explain why it failed, and why the rebuilt version works, I need to start with the idea behind it.
The idea: all events run on the same logic
After 25 years in events, one thing had become obvious to me: all events are the same. A birthday party and a world championship run on the same logic. People arrive, experience something, and go home. To make that happen, you need a space, some stuff, some staff, and some services. The scale changes. The logic doesn't.
So I turned that logic into software. You design the event as a journey: storyboards, stages, steps. What happens, in what order, for whom. Then you build a bank of everything the event needs, sorted into the four S types. Then you connect the two. Every step gets its resources, with quantities, prices and timing.
The plan writes itself from those connections. The budget writes itself from the plan. Nothing is invented twice. An hour of planning saves ten hours of doing, and the app was that hour, made visible.
It worked. The plans were better than anything I had built in spreadsheets. I thought I had it.
Why the first version failed
The first blow everybody knows. Corona stopped the event industry overnight, and every conversation about funding an event-tech product stopped with it. You cannot raise money for planning events when there are no events to plan.
The second blow took me longer to admit. The app had a design flaw, and corona only hid it for a while.
The app was good at planning. It died in pre-production.
Planning ends with a confirmed plan. Then preparation starts: quotes, orders, bookings. And preparation is nothing but changes. A supplier offers a better product. A quantity doubles. A venue moves a build day. In this industry, something always comes up. That part is normal.
The app couldn't hold it. Every change meant editing the plan by hand, then updating the budget by hand, then telling the supplier by hand. It took too much time to adjust. Worse, the confirmed plan and the changed plan lived in the same place, so every edit overwrote history. A few weeks into preparation I was never sure where the real plan was.
Which was the exact problem I had built the app to solve. So the team went back to spreadsheets, because at least a spreadsheet is honest about being chaos. The app went into the parking slot, and it sat there so long I almost forgot it existed.
A plan that cannot survive changes is a document, not a plan.
What changed after five years
The idea never stopped being right. Building it stopped being possible. A fix of this size meant hiring developers and finding money. I had neither, and for five years that equation held.
This summer the equation broke. I learned to work with modern AI development tools and spent over 100 hours of evenings rebuilding the app as one person. What needed a funding round in 2020 needed a few months of focused work in 2026. And because I wasn't paying a team by the hour, I could rebuild the part that killed version one properly, instead of patching it.
What the rebuilt app does differently
The planning engine stayed: journey on one side, 4S bank on the other, the plan as the connection between them. That part was always right. Everything after "the plan is confirmed" is new.
When you confirm the plan, the app locks it as a baseline. That version never changes again. It is the agreed truth, on record. Next to it, a live plan opens: an identical copy, built to move.
Change a quantity, a price or a provider, and the app shows the old value, the new value, and what it does to the budget before you confirm. Then it logs who changed it, when, and why. The question "where is the real plan?" now has one answer: here.
Suppliers get their slice of the plan as a live link instead of an email attachment. No login, no budget visible. When the plan changes, their page changes. Nobody works from an old PDF again.
The budget watches the gap between planned and live. Readiness has a gate: every resource moves through preliminary, quoted, booked and confirmed, and every step gets signed off by a person with a name and a timestamp. And after event day, you lock what actually happened and carry it into the next edition, so planning starts at 80 per cent instead of zero.
What I learned
Two things.
First: a plan that cannot survive changes is a document, not a plan. Version one produced beautiful documents. Version two holds a moving plan. That difference took me five years and one pandemic to see clearly.
Second: parked is not dead. The idea sat untouched because the cost of building it was wrong, not because the idea was. If you have a project in that same parking slot, check what a rebuild costs today. The answer surprised me.
The app is live at bonacube.com, with three complete demo events you can open without signing up. The thinking behind the pre-production problem is covered in more depth in why event plans fail before the event starts, and the planning logic it sits on in the Program and Project Planning Framework for major events.
