Our whole company runs on a hackathon side feature

Two months ago, WarRoom was the name of one panel inside a project about something else entirely. Today it runs our boards, our sprints, our client updates, and most of our meetings.

I still find that slightly funny. Nobody planned it. Here’s how it actually happened.

It started with a hackathon and almost no rules

One Eleven runs internal hackathons, and the brief is deliberately loose: build something with AI, it doesn’t have to be work-related, just solve a real problem. Ross wrote about why we do them this way, and I can tell you from the inside that it works, because I would never have built WarRoom in a normal sprint. There was no ticket for it. Nobody asked. There was just a week where everyone was told to go and be curious, and I took that seriously.

The idea came from a product that didn’t exist yet

Around that time I watched a YouTube video about Campus, something FlutterFlow were teasing. It hadn’t launched, there was no beta, nothing to try. Just people describing an infinite canvas where you could open several windows at once. A flow in one, your cloud console in another, everything laid out side by side instead of scattered across fourteen tabs.

I couldn’t stop thinking about it. I didn’t want to wait for it either. So I started building our own.

On 3 June I dropped a screenshot into Slack, a dark canvas with a few rounded rectangles floating on it, and asked the team to guess what it was. It was rough. But it was real, and it moved, and I was pretty proud of it.

Then I added a whiteboard, because I wanted us to have our own

While I was building Campus, a second idea kept nagging at me.

We use a whiteboard constantly. Workshops, planning, mapping things out on a call. And I loved the thought of us having our own one. Not another tab you jump out to, but a canvas that lives right where the rest of the work already is.

So I built one. I used TLDraw’s SDK to move fast, because at that point it was just one feature among several inside a bigger project. I called it the war room.

The team’s energy went somewhere I hadn’t planned

I demoed Campus at the first hackathon session on 5 June. It went down well. But I kept noticing where the conversation drifted back to.

It wasn’t the multi-window workspace I’d spent most of the week on. It was the whiteboard. The thing I’d added on the side.

I didn’t want to guess, so at 4:57 that afternoon I just asked:

may i ask which feature of Campus did you like most? is it the shared Canvas, or the War room? because im really excited about this project, and im really willing to work on it more on my own free time till it reaches a good state to be a One Eleven production app for us to use regularly

Thato replied five minutes later. Two words: “war room”.

Ross Hartigan, half an hour after that: “agreed”.

And the next morning Ross Nelson said the thing that settled it for me: “The full replacement of MIRO would be incredible 🔥”.

That’s genuinely one of my favourite things about working here. I asked a real question at five in the afternoon and had a clear answer from the people who’d actually use it before I’d even finished making up my own mind.

So I followed them

Three days later, on 8 June, the first proper version of WarRoom shipped. I took the name of a feature and rebuilt it as the product, with Claude doing a lot of the heavy lifting.

Then it grew faster than I expected, mostly because every answer handed me the next question. Once we had our own boards, why were we planning the work somewhere else? So sprints came. Then tickets. Then chat, then time tracking. Then a client portal, because it felt silly for the people we build for to have to wait for a status call to see where things were.

By the showcase on 3 July it wasn’t really a hackathon project any more. The team had moved their actual work onto it, off Azure DevOps and off Miro. People started running meetings inside it. Then client meetings.

Owning the canvas outright

Once it looked like something we might one day offer to other teams, one decision made itself: the canvas had to be ours.

Building on someone else’s SDK is exactly the right call when you’re moving fast and proving an idea. It’s a different call when the canvas is the product. We wanted full control of the thing everyone had picked us for. How it renders, how fast it is, where it goes next, with no ceiling set by somebody else’s roadmap.

So we rebuilt it from scratch. Shapes, connectors, viewport maths, multiplayer, export. Honestly, that was less painful than I’d braced for. It’s ours now, top to bottom.

The workshop that proved it

My favourite moment isn’t a feature.

We were running a team workshop, everyone in one board, and it froze on the first person who tried to use it. I was a bit embarrassed, I’ll admit. Early software doing early-software things, in front of everyone.

But what happened next is the part I still think about. Nobody said “let’s go back to Miro.” We moved one room over into the sprint board and carried on the workshop there, on tickets instead of sticky notes. The session just kept going.

That’s when it clicked for me that we hadn’t built a whiteboard. We’d built somewhere to work, and it was already sturdy enough to catch itself when one part fell over.

Michael kept asking the harder question

Michael Shepherd sent more feedback than anyone. At one point he sent me a feature request asking for a feature request button, so anyone could drop a thought in without leaving the app. We built it. It’s in WarRoom today, and it files a ticket automatically.

But the volume isn’t what I’m grateful for. It was the direction.

Early on, when WarRoom was still a whiteboard with ambitions, he told me I’d need to think much harder about how organisations actually work and how permissions fit together. That one message shaped the architecture more than anything else. It’s why WarRoom is properly multi-tenant, with roles enforced down in the database rather than hidden in the interface, and why we didn’t have to pull it all apart again six weeks later.

He pushed for keeping everything inside one product instead of bolting connections onto other tools. He asked for chat rooms before chat had even crossed my mind. And he gave me two bits of advice I still say back to myself:

Release in small chunks, one at a time, so when something breaks you know exactly what broke it.

And: good products aren’t the ones that do everything. They’re the ones that do specific things very, very well. Be careful you don’t end up with a pile of features you love and nobody uses.

Then he did the thing that made it real. He pushed to get WarRoom onto a proper URL and onto a live client project. That’s the step that turned an internal experiment into something we actually depend on.

He has a rare combination. He’ll give you the detail and the direction, and he’ll keep asking the question you were quietly hoping to skip.

The part that wasn’t me

I built the first version. What turned it into the thing we use every day was the team.

Every bug report, every “wait, why does it do this?”, every person who moved real work onto something half-finished and then told me exactly what they needed from it. They gave it their time while it was still rough and their encouragement while it was still just an experiment. That’s the whole difference between a hackathon demo and a product, and I don’t think I’d have kept going without it.

Where it goes next

Two months on, WarRoom runs our delivery end to end, and we’re getting it ready as a product other teams can use.

But the thing I’d take from all of this is simpler than that. A hackathon with no rules produced the tool we now run the company on. And it got there because the people around me answered straight, asked better questions than I was asking, and backed it well before it had earned that.