Building Is the Easy Part Now

Twenty years ago, 37signals published Getting Real. Recently, I picked it up for the first time. After reading it over the last week, its lessons feel more relevant than ever.

Why? Because AI is changing how software gets made, and the constraints that once forced us to build less are disappearing.

Getting Real says small teams can move faster by building less, working directly in the product, and keeping the cost of change low. Less software, fewer features, and less technical debt to figure out down the line. In 2006, that advice was solid. Building software back then was expensive.

Getting a new feature into users’ hands meant design, engineering, testing, infrastructure, documentation, support… the list goes on. Even reaching a convincing prototype took real time (and money). That real cost of implementation meant you had to be picky and decide how best to spend your limited time and money.

With AI, that filter is getting much weaker.

Building Is Becoming the Easy Part

A few weeks ago, I wrote about how AI helped me turn a product frustration into working code. The first version was good enough to review, criticize, and improve.

That is still what excites me most about AI and how we work today. It shortens the distance between an idea and something you can actually use.

But AI also makes it wayyy too easy to confuse “we can build this” with “we should own this.” Or… even build a business on top of it.

Today, a rough idea can quickly turn into a working prototype, even before the idea is fully developed. The interface can appear slick and engaging, and the demo can be truly impressive…

Then reality sets in. Every feature creates decisions.

• Where does it live?
• Who is it for?
• What happens when there is no data?
• What happens when something fails?

AI can help answer many of those questions and implement the decisions that follow, but it doesn’t make the real work go away.

Cheap Code Can Create Expensive Software

This is the part I think we’re underestimating.

While development costs have dropped faster than anyone could have imagined in 2006, the cost of understanding a product hasn’t.

It’s expensive to ask users to learn yet another concept, make one more choice, or remember one more place where something lives.

Complexity is everyone’s problem.

The team pays through maintenance, meetings, and coordination. Support pays when the product is unclear. New contributors pay when they have to understand how it all fits together. And finally… customers pay every time the product asks them to stop and think about the product instead of the job they came to do.

I haven’t seen any of that show up in an initial AI-generated prototype.

In fact, AI may make that first pass so convincing that it becomes very hard to say no. Once something works, even partially, it starts to feel wasteful to delete it. Just think about all those poor tokens burned.

We become attached to AI’s output, even when the effort to create it was 1,000x cheaper than it used to be.

Don’t get me wrong. I’m not knocking AI. But beware of this new kind of trap.

We can now build software faster than we can understand, refine, and maintain it.

Getting Real Matters More Now

Getting Real argued for less software because more code creates more complexity and more dependencies. It also pushed teams to solve today’s problems instead of trying to predict every future need.

That advice has aged well, but the reason for following it has changed.

Twenty years ago, building less was how a small team conserved scarce time and money. Today, it is how any team conserves attention, clarity, and judgment.

The questions I am asking now are pretty simple:

• What is the smallest slice that solves the actual problem?
• Which decisions can wait until we know more from users?
• What should not become a setting?
• Does this solve a real user problem, or are we just building it because we can?

AI makes iteration cheaper, which is incredible. I literally can’t believe the magic we’ve been handed. It also makes holding back more important because the old friction is no longer there to slow us down.

The lesson from Getting Real was never just “ship faster.” It was to reduce the gap between an idea and reality so you could learn sooner and change course while change was still cheap.

We finally have tools that can do that at a scale that would have sounded like science fiction in 2006.

The challenge now is remembering that faster building doesn’t excuse us from deciding what deserves to be built.