“If AI can rebuild your product in a weekend, why would anyone pay for it?”
I hear this question just about every single day on X, Instagram, Reddit and more. It sounds like a question about the future of software. But underneath it is an old assumption: that what people buy when they buy software is the code.
If that were true, cheaper code would make the whole business fall apart.
But think about what you’re actually buying.
When you pay for a scheduling tool, you aren’t looking for access to a calendar interface. You want to stop emailing people about when they’re free. You want the invitation to arrive, the time zones to work, and the meeting to show up where it belongs.
You want something taken off your plate.
The code is part of how that happens. It isn’t the whole transaction.
You could make the brownies, too
I wrote about this in Convenience Is the Product.
Brownie mix is a simple proposition. Someone measured the ingredients, worked out the proportions, and put the instructions on the box.
You could do those things yourself. Buying the box doesn’t mean you couldn’t.
It means you’d rather spend your attention somewhere else.
Software has a similar bargain. Someone has decided how a process should work, which details matter, and what you shouldn’t have to think about.
AI changes how much effort it takes to make your own version. That matters. Some things you used to buy may become things you make.
But the ability to make something doesn’t automatically create the desire to be responsible for it.
A weekend is only the beginning
Let’s say you rebuild your scheduling tool this weekend.
It works. You connect your calendar, send a link, and book a meeting.
Then someone asks to reschedule. Someone else needs different availability for different kinds of meetings. Your team wants shared bookings. An integration changes.
Now you have a second job.
Maybe AI helps with all of it. Maybe each change takes minutes. You still have to notice the problem, explain what should happen, decide whether the result is right, and care enough to keep doing it.
That’s a different commitment from making something work once.
“Can I build this?” and “Do I want to own this?” are two different questions.
A product earns its place when the answer to the first is yes and the answer to the second is no.
The decisions are part of the product
There’s another layer here.
A useful product contains decisions you may never notice. What happens by default. Which options appear first. Which exceptions are supported. Which requests get turned down because accommodating them would make everything else harder.
Those choices give the product its shape.
This is what I explored in What You Won’t Do Defines You. Refusal is part of making something coherent. Every possible addition isn’t an improvement.
Cheap building makes that discipline more valuable. When you can produce five versions quickly, you still need a reason to choose one.
AI can help you consider the options. It can even recommend a direction. But someone still has to commit to what the product is for and accept the consequences of that choice.
As I wrote in Indecision Does Not Preserve Options, leaving a question open creates work of its own.
Being able to build every option doesn’t make every option worth building.
That doesn’t mean your business is safe
There’s a distinction worth making here.
People continuing to need software doesn’t mean they will continue to need yours.
If a competitor can reproduce your features and take the same burden off the customer for less, you have a real problem. Saying “we sell convenience” doesn’t answer it. The competitor can sell convenience, too.
And if a customer can make a version that takes almost no effort to maintain, buying yours may stop making sense.
Cheaper building changes those calculations. It puts pressure on what you charge and how much value you deliver.
But it doesn’t erase the underlying transaction.
You still have to understand a problem well enough to make useful choices about it. You still have to deliver the result reliably. You still have to keep earning the customer’s preference as their needs change.
The argument for starting a software company can’t be “people will always need software.”
It has to be: “There is something here people would gladly pay us to keep handling.”
What are you taking off their plate?
That’s the question I’d spend more time on.
How much does your customer still have to figure out? How often do they have to check your work? When something changes, who notices? Who deals with it?
A product can have a hundred features and leave most of the burden with the person using it.
Another can do one thing so completely that the customer barely thinks about it again.
That second product has a reason to exist, even in a world where its code is easy to reproduce.
The customer may know exactly how to build it.
They may even enjoy building it.
And still decide they have something else they’d rather do with their Tuesday.
That’s what you’re competing for. Not just the cost of making the software, but the value of everything your customer would rather spend their life doing.
Cheaper code changes what they can make.
Your product has to earn what they’re willing to hand off.
