Steven Murray/ Personal OS
~/content / articles

The build got cheap. That's when the real work showed up.

You can ship a full website in a day now. The bigger unlock is quieter: getting everyone to agree got cheap too. Here's what that changed, and the stack of expensive lessons it took to see it.

Steven Murray · 09 Jul 2026 · 9 min read

I can take a client's website from a rough brief to a real, live, working site in about a day. Sometimes less. A few years ago that sentence would have sounded like a lie, or a corner being cut somewhere quiet. Now it's just a Tuesday.

I should be straight about something before I go further: I'm not a web developer. I never was. I'm an operator who got hooked on what these tools can do and started shipping things I'd always have hired someone else to build. No craft, no scar tissue. And I think that's exactly why I could see what changed, because I was never attached to the old way of doing it.

Here's what struck me. The building getting cheap didn't remove the hard part of getting something made. It moved it. It moved somewhere I wasn't looking, so I kept paying the same school fees everyone always paid, just faster and in front of more people.

I've now paid those fees enough times to have worked out where the hard part went. This is what I wish someone had told me at the start.

The building was never the bottleneck. Agreement was.

The way it always worked was simple enough. You scoped the work, someone disappeared for a few weeks to build it, then came back with something to show. The build was the mountain. Everything else was the walk to the trailhead.

Here's what took me too long to see: the slowness of building was quietly doing a second job. It was hiding how vague everyone was about what we actually wanted.

When a change takes a week, nobody asks for five changes a day. A fuzzy brief has a week to sort itself out while you're busy building. Half-formed opinions firm up on their own. Slowness was a tax, but it was also a filter, and I never noticed it was filtering.

Take the slowness away and the filter goes with it. Now I can turn a comment into a live change before the client has finished their coffee. Which sounds wonderful until you realise the comment was half-baked, the change was the wrong change, and I've done wrong work at a speed that impresses everyone including me.

So the bottleneck didn't disappear. It moved from making the thing to agreeing what the thing is. And here's the part I nearly missed: the tools didn't just make building cheap. They made agreeing cheap too. That second one is the bigger deal, and it's the one almost nobody is talking about.

The meeting was the bottleneck wearing a nice shirt

Think about how alignment used to happen. You booked a meeting. You waited three days for the calendar to line up. Everyone showed up, half of them unprepared, and you talked in circles about a thing nobody could see because it didn't exist yet. You left with a shared feeling and four different memories of it. Then you went and built to your version.

The meeting wasn't where alignment happened. The meeting was a slow, expensive stand-in for it, because we had no cheaper way to get a group of people looking at the same thing.

Most of that is just gone now. The work lives in a shared channel. A client drops a comment, and instead of "let's grab thirty minutes next week," the answer is a live link an hour later. We close queries in minutes that used to eat a meeting each. The human beings are out of the middle of the loop, where they were only ever acting as a slow relay, and the fast, repetitive part sits with the machines, which is exactly where it should sit. People are back at the two ends where they actually add something: the vision going in, and the judgement coming out.

And because each round got so cheap, the whole economics flipped. The old game was to minimise back-and-forth, because every round cost a meeting. The new game is that I'll happily take more back-and-forth, because a round is now a message and a link. Five quick loops is nothing. It's still cheaper, and faster, and clearer, than one meeting. That sentence would have been madness five years ago. Now it's just how the work moves.

North starthe vision stays fixed01Feedback02Confirmed spec03Build04Live preview05Verify06Ship
The loop. The build is one step in it. Most of the value is on either side.

Show them something they can click. Every time.

The single most useful habit in all of this is stupidly simple: every round ends with something the client can click, not something I've described. No "here's what I'm thinking." No mockup living in my head. A real link, a real page, a real button that does the real thing.

Because a person cannot give you useful feedback on a description. They can only react to an experience. Show them a paragraph about a gallery and they'll nod politely. Show them the actual gallery and they'll know, instantly and with total confidence, that the photos are wrong and the third one should be first. That clarity was always in there. The clickable version is just the only thing that gets it out.

I can now send five real options in the time it used to take to write the email proposing one. So I do. They pick, they sign off, we move. When showing costs an afternoon and telling costs nothing, there's no honest reason left to ever just tell.

A photo gallery a client can actually click through — not a description of one. Details anonymised.
A photo gallery a client can actually click through — not a description of one. Details anonymised.
A short qualifier the client fills in themselves, so the brief arrives already sorted. Details anonymised.
A short qualifier the client fills in themselves, so the brief arrives already sorted. Details anonymised.

Why the spec stopped being a bible

Because I came to this without the scar tissue, I'm adopting a lot of so-called best practice fresh, and spec-led development is the clearest example. Write down clearly what you're building before you build it, agree it, then build to it. Sensible. Obvious, even. I do it on everything now like it's a no-brainer.

But here's the thing I've come to understand about why it used to be so painful. The spec became this heavy, immovable bible, a document you locked in blood and defended against all change, and everyone treated changing it as a small catastrophe. And it wasn't because writing things down is bad. It was because getting aligned was so expensive that once you'd finally, painfully agreed on something, you could not afford to reopen it. The rigidity wasn't discipline. It was fear. The spec was a fortress because re-aligning was a war.

Take the cost out of re-aligning and the fortress isn't needed. If I can send five samples and get a clean sign-off in an afternoon, the spec doesn't have to be a bible. It can breathe. It can change when it should change, because changing it is cheap now.

With one condition, and it's the whole game: the north star has to hold. The vision, the point of the thing, what it's actually for, that stays fixed. Everything downstream of it, the layouts and the wording and the order of the sections, is allowed to move. You're not abandoning rigour. You're moving the rigour to the one place that actually needs it, the vision, and letting the details stay soft. Fixed star, flexible map. That's the trade the cheap tools finally let you make.

The trap: cheap makes scope creep worse, not better

Now the one I really want you to take away, because it's the exact opposite of what you'd expect.

You'd think that when everything gets this cheap, scope creep stops mattering. Who cares if they ask for one more thing? It costs almost nothing. Just add it. Keep them happy.

That instinct is a trap, and it's a worse trap precisely because everything is cheap. When every "can you also just…" costs ten minutes instead of two days, I say yes to all of them. Yes is easy. Yes feels generous. Then I look up three weeks later and I've quietly built an entirely different, larger project, for free, that nobody scoped and I now have to maintain. Death by a thousand cheerful yeses.

Cheap doesn't remove the discipline you need around scope. It removes the natural friction that used to enforce it for you. The cost of each extra used to be the brake. Now there's no brake, so you have to be the brake, on purpose, every time.

The move I've landed on is to split two things that feel like one: yes to the build, no to the unbounded scope. I'll happily build the thing. I won't let "the thing" quietly grow to mean "everything, forever." So new requests get sorted, out loud, into "this, now" and "that's the next phase." Saying "great idea for phase two" isn't a dodge. It's the thing that lets phase one actually finish. And this is the flip side of accepting more back-and-forth: you can only afford all those cheap loops if each one still points at the same agreed target. Cheap iteration and loose scope are not the same thing. One is a gift. The other is how projects quietly never end.

Fast and wrong is just wrong, sooner

Speed has a nasty little side effect: it tempts you to skip the checking.

When something took a week to build, you checked it carefully, because rebuilding was a week you didn't have. When it takes an afternoon, a voice says it's basically done, ship it, you can fix it later. That voice has cost me real embarrassment. Fast and wrong isn't a clever trade-off. It's being wrong, delivered earlier, in front of the client.

So there's a rule baked in: I check the actual live thing, in the real place, not the version on my machine that only proves the code runs. The whole point of the speed is that the client gets something real. If the real one is broken, the speed bought you nothing but a faster way to look unreliable.

This is where the shape of the work is clearest. The machine does an enormous amount of the making. What's left for me is the judging, and it turns out that's the part that was always going to matter. The machine can't decide that a thing which technically works still shouldn't ship, that a document should only claim what's actually true, that this request is in scope and that one isn't. That judgement is the whole job now. It's the part with my name on it, the part that doesn't get cheaper no matter how good the tools get. Honestly, it's the part I'd want to be doing anyway.

A caveat, so I don't oversell it

Everything above is about relatively simple sites. Brochure sites, landing pages, small business builds. That's the honest scope of the claim, and it's a big, useful chunk of the world, but it isn't all of it.

The moment something gets genuinely complex, real data, real users, things that break in expensive ways, you need the proper rigour back: testing, careful architecture, actual product management, people who've earned their scar tissue. The cheap-and-fast loop doesn't replace any of that. What's changed is that even those people's lives got easier. The alignment tax dropped for everyone. They still need the rigour. They just spend less of their week stuck in the meeting that used to stand in for agreement, and more of it on the hard problems only they can solve.

The craft didn't leave. It moved.

For a while I worried that if this got so easy, the skill would drain out of the work and it'd all become a commodity. That's not what happened. The building got cheap, the aligning got cheap, and the craft moved one step upstream: into knowing what to build, getting a clear yes without a meeting, holding the north star steady while the details flex, keeping scope honest when nothing pushes back, and having the judgement to know when "it works" and "it's right" are two different things.

That's a harder skill to see. You can't screenshot it. It doesn't demo well. But it's the difference between shipping fast and shipping fast and correct, and it's the reason "I built it in a day" is a real claim and not a warning sign.

The build got cheap. Good. That was never the interesting part anyway. It just took me a while, and a decent stack of expensive lessons, to work out that the interesting part had been waiting upstream the whole time.

← All articles