The cost of building software is collapsing. The cost of bad decisions isn't.

For most of the history of software, building was a constraint. A new product required engineering resources, weeks of planning and often months of development. That didn't include the overhead of security, legal or compliance. That cost created a natural filter. When building something was expensive, teams were forced to make choices about what was worth building in the first place.

AI is changing that.

Tools like Claude Code and Codex are pushing the marginal cost of producing software dramatically lower. An idea that once required weeks of engineering work can increasingly become working software in hours.

This is a remarkable development but it creates a new problem: when everything can be built, what should you build? The cost to build may be collapsing. The cost of making the wrong decision has not.

Every feature you release creates another path through your product. Another workflow your customers have to understand. Another thing your team has to support. Another dependency that will eventually need to be maintained, changed or removed. AI makes software cheaper to create. It doesn't necessarily make software cheaper to own.

At ProPay, we believe that in the age of AI, your roadmap is not just what you should build but what you should not. Taste is the most important feature in the age of AI.

Taste is the new constraint

Taste is often misunderstood as aesthetics. In this context, we mean something closer to judgment. Taste is the ability to distinguish between what can exist and what deserves to exist.

It means understanding a problem deeply enough to know what should exist, what shouldn't exist and what the simplest possible solution looks like.

Historically, an enterprise product decision looked like this: 10 ideas enter a meeting, and after hours of deliberation one gets chosen. AI changes that equation, now every idea could get built. But should it?

In fact, the ability to build everything may be one of the biggest risks AI introduces into product development. Without the natural constraint of engineering capacity, it becomes very easy to accumulate features, workflows, dashboards and AI agents simply because they are possible to create. The cheaper software becomes to create, the easier it becomes to create expensive complexity.

You can build the wrong thing faster than ever before.

Here's what that looks like in our own product. One of the first things we built takes a technician's description of a broken part and figures out which part number they actually mean. "Ice maker thingy, the one with the arm." It works well.

The obvious version orders the part automatically every time. We could have built that in an afternoon, and it demos beautifully.

We built the slower one. Ours scores its own confidence and routes the uncertain cases to a person. That's a worse demo and a better product, because a confident wrong answer in parts procurement isn't an error message. It's a second truck roll, a return to process, and a homeowner who has now been without a refrigerator for nine days.

Speed of building is not speed of learning

Enterprises struggle with speed as a natural consequence of organization structure. Building products has often meant long prioritization meetings, endless back and forth about requirements and long build times because of legacy code.

AI is compressing large parts of that process. That is a good thing.

But it's important to distinguish between speed of building and speed of learning.

If something that once took two months can now be built in two hours, you've dramatically accelerated execution.

But if you never stopped to understand the problem, all you've done is arrive at the wrong answer faster.

The classic product management questions pre-AI matter more than ever:

1. Why are we building this feature now?

2. What problem are we actually trying to solve?

3. How does this interact with our current product surface?

4. What happens if we don't build it?

5. What is the simplest version that solves our problem?

6. Has someone else already built this that we can leverage?

None of these questions are particularly revolutionary.

That's the point.

We don't believe AI has changed the fundamentals of building great products. It has changed how quickly we can execute once we've made a good decision.

How we build at ProPay

At ProPay we think deeply and move quickly. We don't think these are opposites. AI allows us to spend less time translating an idea into software and more time making sure the idea is worth translating in the first place.

Here are some practices we put in place:

• RFCs: At ProPay we believe in the statement "writing is thinking". This always begins with a document we call the Request for Comment. Anyone can write one. The point is to put your thoughts out and articulate the importance of your feature. Is the feature something we truly need? How does it contribute to our overall company goals? This is the single most important step in the process.

• Jam on it: We have multiple "Jam" sessions a week where the team gets together and reviews product documents. People challenge assumptions. They ask uncomfortable questions. They point out second-order effects the person proposing the idea may not have considered. The purpose isn't to create bureaucracy or get unanimous agreement. It's to make the idea better while changing it is still cheap.

• Prototype: A prototype changes the quality of the conversation. Suddenly the strange edge case is obvious. AI has dramatically shortened this feedback loop. That's exactly where we want to use speed, to learn sooner.

• Prioritize: Enterprises take it to mean "This is what you can and can't have". At ProPay it means "What is first, second, and third". Nothing gets deleted from the list. It gets sequenced appropriately based on impact.

• Build with context: We don't write detailed PRDs anymore. Once an idea has been written down, challenged by the team and often prototyped, we already have a large amount of shared context. Modern development tools are remarkably good at turning that context into working software.

• KYP, know your product: When we launch something, we spend time using it ourselves. Automation comes later. For a company like ProPay, this is particularly important. We build software that sits inside complex real-world operations. The edge cases aren't theoretical. They're the job.

The bottleneck has moved

AI has made us dramatically faster builders and shifted the bottleneck upstream. The scarce resources are now understanding your customer, defining the problem, making tradeoffs and knowing when building is not the solution.

Over the next few years you're going to be pitched by a lot of teams who can build very quickly. Speed will be the pitch. It's the easiest thing to demonstrate and close to the least useful thing to evaluate.

If you want to get underneath it, the questions we'd ask are the ones we try to answer ourselves:

What did you decide not to build this quarter, and why? A team that can't answer this isn't making choices. It's building whatever came up most recently.

When your system isn't sure, what happens? The answer should be specific, and it should involve a person. "It's very accurate" is not an answer.

Who at my company has to change how they work for this to pay off? If the answer is nobody, either it's unusually well designed or nobody has thought about it.

We are happy to answer all three ourselves. If you run claims operations at a warranty company and want to put us through them, book a demo and ask.

The advantage will belong to the companies that consistently make better decisions about what deserves to exist.

The cost of building is collapsing.

Judgment isn't.