99% excitement, 1% concern

I was watching a movie on a Saturday evening with my laptop open on the table next to me. Every so often I’d glance over, read a few lines, and go back to the film. Claude Code, Anthropic’s terminal coding agent, was rewriting the entire frontend of one of our applications from Vue to React.

Not a component. The frontend. Every screen the application has, which is tens of thousands of lines.

I’d given it a narrow job and narrow permissions: build a proof of concept, in its own corner, touching nothing that mattered. Nobody had asked me to do this. It was a thing I wanted to know the answer to.

On Monday I showed it to our tech lead. He was genuinely excited, took the proof of concept into the real repository, spent a pass cleaning up its foundations, and shipped it. Within a day or two the old frontend was switched off.

GolfNext, where I work, builds the software golf clubs run on: bookings and memberships, the self-service kiosks that work as a reception desk when nobody’s behind the counter, the payment side of the driving range, which is the practice area where you pay for a basket of balls and hit them. I’d been there four weeks. The application I rewrote is one club staff sit in front of all day, so when it breaks, someone at a club is standing at a desk with a customer in front of them.

Before this I spent years at a much bigger company, which is most of the point.

A company let a four-week employee’s weekend experiment replace a staff-facing frontend inside a week. That’s the part I still find surprising, and the AI is the least of it.

Why a rewrite at all

Since the rest of this post spends a while on why good ideas stall elsewhere, it’s only fair to give the reason for this one up front.

It isn’t that React is better than Vue. Our mobile apps are already React Native, and if the desktop application we ship ever moves to a web interface, React would be the single framework behind every frontend at GolfNext, web or desktop. One set of idioms instead of two, one dependency tree, and one answer to a question rather than two that both half-apply.

The other reason is less flattering to talk about and matters more day to day: coding agents are noticeably better at React than at Vue. There is far more React in the world, so far more of it went into the training. If we’re going to build software the way we now build it, there’s an argument for standing where the tools are strongest.

What would have happened at my last job

Nothing, or close to it. But not for the reason you’d probably guess.

My last job was a large enterprise and I want to be fair to it: it wasn’t drowning in bureaucracy. There wasn’t a thicket of committees to get an idea through. What there was instead was a small number of senior developers who had been there a very long time, held most of the decisions, and were comfortable with the way things already were.

Nothing had to be formally refused, and mostly nothing was. A proposal only had to fail to interest the two or three people whose agreement it needed, and then it quietly didn’t happen. That’s a harder wall than a process, because a process at least tells you what to do next.

The deployment story had the same shape. Releases were largely manual, and the ability to perform one — along with the access you’d need to diagnose anything when it went wrong — sat with a handful of people. If you weren’t one of them, your work stopped at the point where it needed something only they could do, and then it waited. Not out of malice. It was how the permissions had settled over the years, and nobody whose day it improved had a reason to change it.

So the honest version of the contrast isn’t speed. It’s how much of what you already know how to do you’re actually permitted to do. At GolfNext, the person who reviewed my weekend experiment was also the person who could ship it. Where I worked before, that would have been two different people, and a queue.

How an idea gets a yes here

Two paths, and neither of them has an approval step.

The first is a conversation. Someone says the thing out loud, whoever’s in the room agrees it’s worth doing, and it gets done. No document. The second is a task in our tracker, which is the same thing with a title and an assignee so it doesn’t get lost.

There’s no third path where the idea goes away to be evaluated. Worth being precise about what that does and doesn’t mean: the gate we don’t have is the one that decides whether an idea is allowed to be tried. Code review and the release process are still exactly where you’d expect them.

Most of the ideas come from our founder, who started the company in 2012. He has more of them in a week than the team can build in a month, which could easily be exhausting and mostly isn’t, because the flow runs in both directions and an idea from a developer gets the same reception his do. I’ve brought several since I started, and not one of them got the treatment I was braced for.

Our tech lead wrote something close to this on this blog two weeks into his own job — he’d arrived braced for friction and found almost none of it. Four weeks in, from a different chair, I’d say the same. The difference is that I’ve now got a story concrete enough to argue with.

The reception isn’t just approval either, and that’s the part I hadn’t expected. Show something to our founder, our product manager or our CEO, and inside a minute one of them is building on it out loud: what could sit on top of this, what else it could be used for, where the value to the company would actually land. You arrive with a thing you made and leave with three things it could become. That’s a good feeling, and it’s also a reason to turn up prepared: an idea here grows the moment you show it, so it pays to have thought about where it could go before somebody else does.

The turnaround is the part I still haven’t adjusted to. Sometimes an idea in the morning is live within twenty-four hours. Sometimes it’s two weeks. It’s rarely a quarter.

The part I don’t want to gloss over

“An AI rewrote a staff-facing frontend and we shipped it two days later” is either good engineering or a story that ends badly.

So, the details.

The agent could create, and that was the whole of it: no editing or deleting anything that already existed, all of it off in its own corner. Nothing it produced was one merge away from a golf club’s Monday morning.

Then a human read it. Our tech lead clicked through every view — there aren’t that many, twenty or thirty with some forms and modals, half an hour of clicking — and concluded it looked good enough to replace the old application without breaking anything. What he didn’t have was years of history with this codebase; he’d been there about as long as I had. So the review wasn’t institutional memory. It was somebody who knows what a healthy React codebase looks like reading this one before it went anywhere near a club.

Where he did spend his time was the foundation rather than the behaviour: getting the look back closer to the application we were replacing, putting Biome in, settling how directories and files get named, and taking apart the places where the agent had stacked fifty Tailwind classes onto a single div — restructured, then a lint rule so it can’t come back. A human should still be able to read the thing. That’s the work that makes it safe to add functionality to, instead of building the next floor onto something already leaning like the Tower of Pisa.

That review is the actual safety mechanism in this story, not the model and not my prompt. Not the tests either, because this frontend never had much of a suite. That was already true before the rewrite. The rewrite just made it matter more.

It was also frontend-only. Same API, same data, nothing touched on the payment path.

What we don’t have is a gradual rollout, and this blog has already admitted as much: our customers are physical places, so the first ring is geography, and if a release goes badly at a nearby club the recovery plan is twenty minutes in a car. That’s a real safety net, and I’m not going to call it a canary deployment.

The thing I’m still carrying is that nobody has read every line of that code the way you read code you typed yourself. A rewrite that looks finished is the most flattering output an agent produces, because the gaps are omissions rather than bugs, and an omission doesn’t show up in a demo. I expect to keep finding them for a while. So far nothing has broken at a club.

The plan the weekend belonged to

Nobody had asked for that rewrite. It was the first piece of something longer I’d been sketching, and what decided the timing was mundane: I looked at how much of my Claude Code allowance was left for the month. Unused tokens don’t roll over. Capacity I hadn’t spent was capacity GolfNext had already paid for, and spending it cost the company nothing at all.

So I spent it. Over that stretch I started proofs of concept for most of our applications, all of them in one language with one code structure, to find out what a unified stack would actually look like instead of arguing about it in the abstract. Exactly one of them, the React frontend, has reached production. The rest are still proofs of concept, and I’d rather say that plainly than let this read as a migration that’s already happened.

We run two admin portals, each with its own backend and its own login. They serve different purposes, but there’s no good reason for them to be separate applications, and I genuinely don’t know why they were built that way — it predates me by years. What I do know is that every developer here and everyone in management agrees there should be one. The cost of having two lands on the people using them: club staff log in twice.

The plan is to end up with one. First an auth bridge, so a single set of credentials works across both. Then the merge itself: one frontend and one navigation, with both backends still running behind it. Only then the backend, replacing the two services with one, so there’s a single language and a single code structure under the whole portal instead of two of each.

There’s a reason that road is worth walking now rather than in two years. The ambition here isn’t modest. We’re in eighteen countries today, the plan involves a good many more, and a lot more users behind them. Much of that arrives through integrations: every club already runs some management system, and our position is to work with whatever they have rather than ask them to throw it out. Each one of those is another system to speak to and another set of assumptions to keep straight.

Two portals, two backends and two authentication schemes is survivable at the size we are now. It’s exactly the kind of thing that stops being survivable when things go well. So the argument for doing the unglamorous structural work is that there’s still slack to do it in, and that’s also why “let’s unify the stack” is met with excitement here rather than a request to justify it. Everybody already knows what’s coming.

That’s a long road rather than a sprint, and most of it hasn’t happened yet. Getting the frontend onto React was the groundwork for all of it, the thing that had to be true before any of those steps could start, which is why that was the experiment I picked for a Saturday evening. Step two was showing the whole plan to the people who would have to live in it.

Where the 1% went

Our tech lead was pushing in the same direction and wanted the rest of our frontends on React too. Management’s reaction to the whole package — the portals, the backend, the frontends — was, in round numbers, 99% excitement and 1% concern.

I want to be precise about the 1%, because it wasn’t what I expected. I’d braced for cost, or for risk to customers. What they were worried about was how the existing developers would feel.

These are people who have been building this software for years, in a stack they chose, and two of us — both of us about a month in the door — were proposing to change it. That’s the right thing to be concerned about, and it’s the concern that never shows up in an estimate.

So we ran a brainstorm with the team, and held our own opinions back until everyone else had spoken.

That’s harder than it sounds. We already had our proposal written down. Every time somebody drifted towards it the tempting move was to jump in and agree, which would have ended the discussion and turned everything after it into consent rather than input.

When we finally put ours on the table, nobody disagreed. The portal merge and what follows it they were actively excited about. The React standardisation itself they were only fine with, and that’s the more interesting half of the sentence: it’s the part that replaces the stack they had chosen, and “fine with” strikes me as an entirely reasonable thing to feel about that. Nothing in the proposal changed as a result, which is the least satisfying way for a meeting to go well, and I’d rather report that than dress it up. We’re working in that direction now.

Enthusiasm from management is easy to come by here. That’s a feature, and it’s most of why the twenty-four-hour turnaround exists at all. Enthusiasm from the people who have to live in the code every day is the one you have to earn, and the only reliable way I know to earn it is to shut up for the first half of the meeting.

Enthusiasm asks for discipline

I don’t want to leave this as a post about how nice it is here, so let me say what the environment actually demands, because it isn’t nothing.

A place that says yes in twenty-four hours only works if what you put in front of it deserves a yes in twenty-four hours. None of the proposals in this post were sketched in the meeting they were presented in. Our tech lead and I have spent a lot of hours together on plans and architecture, going through them properly before anyone else saw them, and separately we each did our own reading first. Most ideas I’ve brought here were researched before they were presented, not while they were being discussed.

The weekend proof of concept is the clearest case. Its purpose wasn’t to produce code. It was to take the riskiest assumption in a plan and settle it before asking anybody to commit to the plan. That’s preparation dressed up as a hobby.

This is the part I’d underline for anyone who thinks an enthusiastic culture sounds comfortable. When there’s no gatekeeper you have to convince, there’s also nobody checking your thinking for you. The rigour a process would have forced on you has to come from you instead, and it has to arrive before the meeting rather than after it. Enthusiasm doesn’t lower the bar for professionalism. It moves the bar onto you.

Which makes this a particular kind of place to work rather than a straightforwardly better one. If you’re ambitious, and you enjoy doing the preparation properly, it’s the best environment I’ve worked in — what you can get done is bounded by your own thinking rather than by somebody’s approval queue. If you’d rather have a process tell you what’s next and a committee share the weight of being wrong, I think you’d find it uncomfortable.

If you’re weighing up a place like this: the fastest thing about GolfNext isn’t the tooling or the agents. It’s the distance between having an idea and being allowed to try it.

You do have to be careful what you think about on a Saturday evening. It might be in production by Tuesday.