Shaky but functional

By lunch I had watched a demo work.

It was held together with hope and three open terminals. Something in the background was quietly on fire. (Figuratively. Probably.) It also, miraculously, worked.

Shaky but functional. I wrote the phrase down. By the evening it more or less summed up the day.

Three days earlier, fourteen people had spent a day not writing a single line of code. No build. Just the questions: who is this for, what is the one thing it does for them, and how will you know on Thursday whether it worked. Today they got to answer the other way round. With their hands.

I spent the gap looking forward to seeing how this experiment would conclude.

Here is the thing I got most wrong. I thought build day would be the comeuppance. Two-thirds of the company had never done a hackathon. We are in the middle of a heat wave. I had a clear picture of Thursday: half-finished things, a couple of brave demos, a lot of "it works on my machine, sort of."

Then lunch happened, and that shaky little demo worked. And it wasn't the only one.

Monday did the work#

At standup I asked for three things. Go back to the success you defined on Monday. Build the happy path. Be demoable before you are pretty.

The first one was the one that mattered. Monday was only worth anything if it survived contact with a keyboard. A success definition is easy to nod at in a workshop. It is much harder to remember when a terminal is open, something is broken, and the clock is getting rude.

But an hour in, the room had gone quiet in the right way. People were not stuck. They were choosing. Nobody had to be talked out of polishing the wrong thing. Nobody needed permission to make the rough version work first. The guide had a line in it, almost pleading: cut scope before you cut quality. By then, they were already doing it.

So far, so smug. Here is where it stops.

The build still fought back#

The afternoon arrived, and so did integration hell.

A clear target buys you a lot. It does not guarantee you a problem-free build. The design day told everyone what they were aiming at. But technical decisions still had to be made, of course.

This is the last mile. They knew what they had built. It fought back. The "shaky" was earned.

Scope under pressure#

Here is the part I'm proudest of, and it has nothing to do with code.

Under deadline pressure, with demos looming, not one team gold-plated. Nobody bolted a shiny second feature onto a shaky first one. Every team that hit a wall cut scope instead of cutting quality. For a team mostly doing this for the first time, that is the discipline I would least have bet on.

Two cuts are worth showing, because they went in opposite directions.

Invoicetigator checks whether the invoices our customers get from staffing agencies actually match the hours worked. The demo was a proof of concept that, a week ago, looked like it might not be feasible at all. No clever code got them there. A ruthless cut did: they found the smallest slice of the problem that was still worth having, and built only that. They didn't so much out-code the problem as out-scope it.

C-4 went the other way, and it's the more useful story. Their project is one consistent tone of voice across every role in the company, with an LLM doing the heavy lifting. They cut scope on Monday. They cut it again on Thursday. And they still ran out of day, because the thing was deeper than it looked from the outside.

I want to be careful here, because they worked hard and the effort was good and very useful. But the lesson is good, and it is mostly mine. They kept cutting breadth. The cut they needed was depth: do less of the thing, properly, instead of a thinner version of all of it. Spotting that early, and saying it out loud, is exactly the product-and-tech balance I spent two days claiming to float around and provide. On their team, on the second day, I didn't spot it fast enough. That one's noted for me, not for them.

What they showed#

At 16.15 every team demoed. Every team had something that worked.

Deeper than I expected, across the board. Invoicetigator's not-quite-feasible idea, demoed for real. It surfaced real-world problems too, and the team already had plans for them. The lead-gen and sales "minions" team showed theirs working on real data. The kind you could act on the next morning, not a screenshot of what it might do one day.

(Their mental image of an AI agent is still, for the record, a Despicable Me minion.)

I could keep listing wins. I'm going to stop, because the wins are not the point of these write-ups, though I am proud of all of them.

The test is still "Friday"#

A working demo at 16.15 proves a team can build something real in a day. It is genuinely good news. It is also not what this was for.

Thursday was only ever the smaller half of the bet. The bigger half is whether the scarce skill, knowing what success looks like, shows up on a normal day. Friday. No hackathon buzz. No silly whiteboard. No minions. Just the work, and whether anyone reaches for the thing we spent two days practising.

I can't answer that yet. Nobody can, on a Thursday evening with a drink in hand. (They earned the drink.) What I can say is that the people who walked out tonight built more, cut smarter, and panicked less than a room of mostly-first-timers in a heat wave had any business doing.

Shaky but functional was enough for Thursday. The future asks for something steadier. Not a demo that works once, but a skill people reach for when the buzz is gone and we are back in our day-to-day routines.

We'll find out then whether it stuck.