We Built Companies Around the Cost of Building

For most of the history of software, making things was expensive, and that cost shaped a lot more than the products. It shaped the company: roadmaps, headcount, what a PM does, how design and engineering split the work, who signs off, and in the end who got to turn an idea into something real.

AI is pulling that constraint out from under us fast, and we’re nowhere near the bottom yet. Everyone has already written the “AI makes developers faster” piece. It’s true and it’s the least interesting part. What I keep coming back to is what happens to companies, products and the people who make them once the scarcity they were built around goes away.

Companies will still make decisions. They’ll just make a lot more of them after the thing exists.

The cost was real

Look at how software used to get made and the whole thing feels almost impossible from here. Huge teams, enormous specifications, specialized machines, long testing cycles, physical media. I couldn’t tell you what half the equipment in these photos does. Making software was expensive, changing it was worse, and being wrong could cost you a year.

A lot of the process we inherited made sense for the world it came from. When building something took months or years, and finding out you were wrong could send you back to the beginning, of course you planned the shit out of it. I don’t blame the process. It was a pretty reasonable reaction to what a mistake cost.

The order we built around

For most of my career, the process looked roughly like this:

1. Idea
2. research
3. explain
4. debate
5. prioritize
6. approve
7. build
8. test
9. iterate
10. launch
11. iterate

Eleven steps, and that’s the short version. I left out the reorg in the middle, the offsite where we re-prioritized the priorities, and the two weeks waiting for someone to get back from vacation. Every company had its own version and none of them were short.

Back in the Teehan+Lax days we worked with a large financial services company on what was honestly a pretty straightforward tool for tracking equities and mutual funds. It took over a year to ship. Building it was never the slow part. Most of that year was the list above, one step at a time.

Before you spent the expensive resources, you tried to decide whether the idea deserved them. So we got good at deciding. We made roadmaps, wrote specs, estimated things, had design reviews, argued about priorities, made business cases and asked for headcount. There were always more ideas than people who could make them, so somebody had to decide which ideas got the people.

That scarcity did something useful: it killed ideas.

If there were twenty ideas and enough people to build three, seventeen were going to die. Probably a few good ones. Definitely a lot of bad ones. We called that prioritization. Underneath it was scarcity.

And scarcity shaped the company. Product decided what should be built. Design figured out how it should work. Engineering made it real. Management allocated the people who could do those things. It was never quite that clean, but access to builders was access to power. Want your idea to exist? Get it on the roadmap. Convince the PM. Get engineering resources. Make the case. Wait your turn.

That made sense when building was expensive. What happens when it isn’t?

The order is changing

This didn’t start with AI. Every time the feedback loop got cheaper, the way we worked changed with it. Prototyping got faster. Interfaces could be changed while you were looking at them. Spreadsheets let people who weren’t programmers make little pieces of software for themselves. The web made publishing almost free. Each time, some amount of planning got replaced by trying.

AI is the same pattern, just a lot bigger.

Not every part of software is getting cheap at the same rate. Running something safely and reliably can still cost a lot. But making enough of it to find out whether the idea works now costs about as much as lunch.

1. Idea
2. build
3. learn
4. decide

Eventually it might simply be:

1. Need
2. software

That sounds ridiculous until you look at how quickly this stuff is moving. Today you still open an AI coding tool, explain what you want, watch it work, fix things, test it and go around a few more times. There’s enough friction that it still feels like building software. I don’t think that lasts.

I have no idea what these tools will be able to do a few years from now. I’m not sure anyone does. But they’ll be a lot better, faster and cheaper than what we have today, that part isn’t really in question. The amount one person can make will keep going up, and the distance between having an idea and having working software will keep getting smaller. At some point, making software may not feel like making software at all. You’ll need something, describe it, and there it is. Maybe it lasts a year. Maybe an hour. Maybe you never even think of it as software.

We wrote every line of code. Then we reviewed code we didn’t write. Then we described what we wanted and stopped reading it at all. Each of those was a step closer to the idea and a step further from the work.

I can’t really picture what happens when that’s normal, and I’ve tried.

Build before permission

We’re already seeing people build things that would have required a small team not long ago. Designers are making working software themselves. Product people can come into a meeting with the thing instead of a deck about the thing. Engineers can try five approaches instead of spending a week arguing about which one deserves to get built.

“I think this might work” is one kind of conversation. “Here, try it” is another. A lot of hypothetical conversation disappears when everyone can touch the thing we’re supposedly debating.

Jay and Anita spend a lot of their time on the product side at Lightspark, the dashboards our customers actually use. They bring working software to crit now. We so rarely critique Figma these days.

Case in point: this stupid little tool. It answers exactly one question: what should a shadow look like? The web already has a hundred of these. I made another one anyway, just for this post. Two minutes, maybe 74 cents, zero meetings.

So build it first. Obviously not in production, not wired into customer accounts, not running the bank. Use some judgment. But if we can answer a question by making something in three hours, spending three weeks debating whether we should make it is insane.

Faster code is the boring part. Finding out whether an idea is any good used to take a quarter and now takes an afternoon, and a lot of our process was built for the quarter.

Software becomes disposable

We’ve always treated software as something that should last. You build it, launch it, maintain it, add features, migrate it, support it and eventually have a meeting about whether anyone is brave enough to kill it. But if making software becomes cheap enough, why should all of it last?

Maybe someone makes a tool for twelve people on Monday, it solves a problem for six weeks, and then it disappears. Maybe an agent makes something for one task and nobody ever uses it again. Maybe interfaces themselves become temporary, assembled around whatever someone is trying to do right now. Make it, use it, toss it. By the old rules that sounds wasteful. I suspect it’ll end up feeling pretty normal.

We’ve spent most of the history of computing treating software as an asset, something expensive enough to make that you naturally wanted to keep it. Cheap creation changes that, but it doesn’t make everything else cheap. Security, customer data, reliability, maintenance, none of that got any easier. Somebody still gets the call when the thing everyone depends on stops working.

So making something and committing to it should be two separate decisions.

Abundance

Photography is probably the easiest analogy. Film made every exposure cost something, so you thought before you pressed the shutter. You had 24 or 36 shots. You probably didn’t take fourteen nearly identical photographs of your lunch. Then digital photography made the marginal cost of another photograph basically zero.

We didn’t start taking 20% more photographs. We started taking pictures of everything. Our dogs. Our dogs again, slightly to the left. Our food. The parking spot so we remember where the car is. Twelve versions of the same sunset, all kept. Something at Home Depot we told ourselves we’d need.

The second world is obviously better. More people can make photographs. We capture things we never would have captured before and experiment without worrying about wasting film. We also made a ridiculous number of photographs nobody will ever look at again.

Software is probably headed the same way. When making something costs next to nothing, people make a flood of it, and I don’t think any of us has a real sense yet of how big that flood gets.

Then comes the mess

This could be a great time to be someone who makes things. Millions of people who could never turn an idea into software suddenly can. Weird little ideas get tried, tiny markets start to make sense, and the people closest to a problem stop waiting for someone else to get around to it.

Now imagine everybody doing it.

Bad software I’m not worried about. Nobody uses it and it dies on its own. It’s the pretty good stuff that scares me. Someone makes a little tool on Tuesday. Seven people use it. Someone hooks it into something else. Someone adds a feature. Seven users become seventy. A year later 400 people depend on it and nobody is entirely sure who owns it.

We already do this with spreadsheets. Every company has some version of FINAL_FINAL_v7.xlsx, created by Susan, who left four years ago, that apparently controls a meaningful percentage of the business. Now imagine everybody can make software that easily. And then imagine the machines can too.

We could drown in pretty good software: software that was cheap enough to make, useful enough to survive, and not important enough for anyone to properly own. The old constraint killed a lot of this stuff before it existed, and it’s going away, so we need something to take its place.

Permanence should be expensive

More approval isn’t the answer. Companies that respond to AI by wrapping creation in more process are going to get smoked by the ones that don’t. Making someone write a spec, get three approvals and wait for the next planning cycle before spending an afternoon testing an idea makes no sense when the experiment is cheaper than the meeting.

Our team at Lightspark just does stuff. Someone recently took a hard look at our docs, at how well they support the customers we have and how well they bring in new ones. It wasn’t on a roadmap. He saw a gap and went. He’s not going to lose his job for shipping changes like that, even if they aren’t perfect when they go out, because I know he’ll spot what’s off and be back tomorrow making it better.

Let people make things, including dumb things. Let agents make things. Most of it should probably disappear. What we need to get a lot more serious about is what survives.

Maybe the gate just moves later. Let almost anything get made, and be much pickier about what gets adopted, hooked into important systems, shown to customers and then maintained and secured forever. A prototype turning into infrastructure, an experiment turning into product, anything touching customer data: somebody should have actually decided that.

Creation should become almost free. Permanence should remain expensive.

That puts the gate somewhere else. We used to gather as much evidence as we could before deciding what deserved to be built. Now the thing itself can become part of the evidence. We still have to use judgment, but we’re judging something people can actually try.

What happens to us?

There’s an uncomfortable question here for designers and engineers. If almost anyone can make the artifact, what exactly are we for?

I think we still matter, just less for the artifact itself. If anyone can make the thing, making the thing stops being the advantage.

What’s left is mostly taste and judgment. Which problem is worth solving. When a rough version is good enough to learn from and when it’s just rough. Spotting the one strange idea out of fifty attempts that’s actually new. Knowing what deserves another afternoon and what deserves the next three years.

Engineering changes too. Generating code is getting cheap. Knowing what belongs in a permanent system, what has to scale and be secure, and what should just be thrown out is not.

My hunch is that a lot of what we called expertise was really just scarcity, and AI is about to show us which parts.

The calm before the storm

Right now this still mostly looks like faster software development: smaller teams, weekend apps, designers writing code, engineers making nicer interfaces, lots and lots of demos.

I think we’re going to look back and laugh at how small we thought this was. When digital cameras showed up, people used them like film cameras. Same pictures, they just stopped paying to develop them. Nobody was photographing their parking spot yet. That’s about where software is. Faster development is the same pictures without the developing costs. The parking-spot phase hasn’t started.

When it does, it changes who makes things, how long software lives and what design and engineering are worth. It probably changes what a software company even is. I can’t tell you what that looks like. It feels like the best time to make things I can remember, and also like the calm before a storm.

For most of my career, the question was: is this worth building? Soon that question may barely matter. We’ll build it and find out.

The harder question comes after:

What deserves to last?