Introduction
As developers, we all have our own opinions about the “best” choice for every slot in the tech stack. But if you’ve been in the loop for any length of time, you know that “the best” changes almost weekly. There’s always a new framework, service, UI library, CMS, or authentication solution to consider.
With so many excellent options, choosing just one can be overwhelming. I often find myself trawling through documentation and example projects, comparing factors like developer experience, UI/UX, and long-term maintainability. The point of this article isn’t to join the endless debate over what’s “best.” In practice, “best” is subjective—guided by each developer’s priorities. Some value raw performance and optimized load times, while others prioritize developer experience, scalability, or stability.
But here’s the reality: what’s “best” depends entirely on the customer’s needs.
What Customers Really Value
Customers value simplicity and results. They want the fastest, most cost-effective, and easiest-to-maintain solution that maximizes business value. They don’t want to juggle 10 separate providers just because each one claims to be the technically superior option. And they rarely want to wait longer—or spend more—for a “perfect” technology when a good-enough option is already available from a trusted provider.
Of course, this varies. Large tech organizations are a different story—they’ll happily spend a year rewriting an ecosystem if it squeezes out even a 3% performance gain. OpenAI’s recent rewrite of the ChatGPT web app in Remix is a good example. To a small business, that might seem excessive, but at OpenAI’s scale those marginal gains are a necessity.
Speaking the Customer’s Language
Every customer comes with a unique set of requirements. Our job as developers is to uncover not just what the customer wants but also what they actually need. Sometimes those two things are at odds. It’s easy to forget that we speak an alien language. Most customers don’t know what Kubernetes is. If you tell them it’s a load-balancing containerization solution, 99% will stare blankly before saying, “That sounds nice, we should add that!”
But does a small e-commerce site with fewer than 50,000 monthly active users really need it? Almost certainly not. And if they did want scalability, there are simpler, managed options like Shopify that handle the backend invisibly, for a fraction of the cost.
The Real Job of a Developer
Our responsibility is to translate the jargon and hard technical choices into plain terms that customers can understand—and that won’t leave them frustrated a year later. Especially with bespoke builds, the customer needs to grasp the fundamentals of what they’re running. If they hire a dev team later and you’re not around, what happens then?
If you’ve split their app into 15 microservices, built a custom CMS, and signed them up for providers they don’t even realize they’re paying for… they’re in trouble. And I’ve been on the other side of this. More often than not, the client will just hire someone to rewrite your “technically perfect” solution into something simpler, just to stop the bleeding in costs and time.
The Takeaway
At the end of the day, all the cutting-edge tech in the world means nothing if the customer isn’t happy. Your job as a developer is not to stroke your own ego or build something only four people on the planet can maintain. Your job is to deliver the value the customer is paying for—and to make sure the solution actually works for them.