When You Can Build Anything, Choosing What to Build Is Everything
The hardest part of building software has changed.
It used to be the building itself — the months of development, the cost of getting it wrong, the weight of every commitment. When shipping a feature took a quarter, less than ideal prioritisation was easy to hide. Long cycles gave you cover — by the time something landed, the context had shifted enough that nobody stopped to ask whether it was the right thing to build in the first place.
AI has compressed that. We can prototype in hours and ship in days. The cost of building has dropped dramatically. But that speed has created a new problem: when you can build anything quickly, choosing what to build becomes the highest-leverage decision your team makes.
Most teams haven't adjusted to this. They're still spending 90% of their energy on execution and 10% on direction. We think that ratio needs to flip. And that shift isn't just a product management problem — it changes what it means to be an engineer.
Engineers need to be close to the problem
When building was slow, it made sense to separate the people who decided what to build from the people who built it. There was a long pipeline — research, specs, handoff, execution — and engineers sat at the end of it. That model breaks down when the cycle time drops from months to days. You can't afford the latency of passing context through layers of documentation and meetings.
At Opply, our engineers sit alongside the ops team. The ops team uses the product daily and sits closest to customers. They experience the same friction, hear about problems in real time, and understand the context behind a complaint in a way that a ticket never captures.
This isn't an accident. It's a deliberate structural choice. When an engineer hears about a problem directly from the person experiencing it — whether that's the ops team, a support ticket, or a customer conversation — they understand it differently than when they read a brief. They understand the why behind the pain, not just the what. And that understanding changes the solution they build.
The solution matters as much as the decision
Prioritisation gets a lot of attention — and rightly so. But even perfect prioritisation falls flat if the engineering response isn't right.
What we mean by that: when a problem is identified, the way you solve it matters enormously. Two teams given the same problem will build very different things depending on how they think.
Our approach is to ask a few questions before we write any code:
What's the simplest thing that actually solves this? AI makes it tempting to over-build. When you can generate a sophisticated solution in a day, it's easy to skip past the version that's three lines of config and a database change. We try to resist that. The goal is to solve the problem, not to demonstrate what we're capable of.
Does this solution move the product forward or just patch a hole? Some problems need a quick fix and nothing more. But the best engineering work solves today's pain in a way that also builds toward the product's long-term direction. That means understanding the vision well enough to design toward it, even when you're working on something small.
Are we solving what the customer asked for, or what they actually need? These are often different. Being close to the problem — through the ops team, through direct conversations — gives us the context to tell the difference. A customer might ask for an export button when what they really need is a view that eliminates the need to export at all.
Speed changes the engineering mindset
When building was expensive, engineers were trained to be cautious. Plan extensively, spec thoroughly, build once. That mindset made sense when a wrong decision cost months.
Now that we can build, test, and iterate in days, the calculus is different. The cost of trying something and learning from it is often lower than the cost of planning it perfectly upfront. This doesn't mean we move recklessly — it means we treat shipping as a way of learning, not just a way of delivering.
For engineers, this is a genuine shift in how you work. You spend less time interpreting specs and more time talking directly to the people affected by the problem. You're not waiting for a spec to be handed to you — you're part of the discussion about what the problem actually is. You prototype fast, put it in front of real users quickly, and iterate based on what you see.
This is what we mean when we talk about product engineering. It's not a rebrand of the same job. It's a fundamentally different relationship between the engineer and the problem.
Communication is the whole game
None of this works without communication. Not status updates — actual, ongoing, two-way communication between the people building the product and the people closest to customers.
Our engineers sit alongside the ops team, so context flows naturally rather than being filtered through handoff documents. Stakeholders understand why a solution was built the way it was, not just what was shipped. Everyone can challenge an approach before it's locked in.
The biggest waste in product development isn't building slowly. It's building confidently in the wrong direction because the people designing the solution were too far from the people experiencing the problem.
AI has given every team the ability to build anything, fast. That sounds like a superpower. But speed without closeness to the problem just means you build the wrong thing quicker — and now you can do it ten times before anyone notices.
The question worth asking isn't "how fast can we ship?" It's "how close are the people building to the people hurting?" Because in a world where building is cheap, understanding is the competitive advantage.
