The most profitable technical decision I ever made was refusing to start over.
Three years ago, a potential client asked me what tech stack we use. I said Laravel. He paused, smiled politely, and said: “Isn’t that a bit… old?”
We got the project anyway. Delivered it two months ahead of schedule. He never asked about our stack again.
That moment taught me something the tech industry desperately needs to hear: nobody cares what framework you use. They care that it works. They care that it ships. They care that when something breaks at 2 AM, someone on your team knows how to fix it without Googling for three hours.
But somewhere along the way, we convinced ourselves that the stack is the product. It is not. The product is the product. The stack is just how you build it.
The Rewrite Trap
Every developer has felt it. You are six months into a project, things are working, clients are happy, and then you read a blog post about some new framework that promises to solve every problem you have ever had.
Suddenly, your perfectly functional codebase looks ugly. The architecture feels outdated. You start whispering to yourself: “If we just rewrote this in bla bla bla, everything would be so much cleaner.”
I have been there. Multiple times. And I have watched other teams fall into that trap while I forced myself to stay put.
Here is what happens when you rewrite:
The first month feels exciting. Everything is fresh. The new framework is elegant. Your team is energized. You are writing clean code with no legacy baggage.
The second month, you start rebuilding features that already existed. The ones nobody thought about because they just worked. Edge cases. Integrations. That weird business logic the client requested eighteen months ago that nobody remembers the reason for but everyone relies on.
By the third month, your new shiny codebase has half the features of the old one, twice the bugs, and zero revenue to show for it. Meanwhile, your competitor, the one still running their “boring” stack just shipped three new features and signed two new clients.
I have seen startups die this way. Not from bad ideas. Not from lack of funding. From rewriting codebases that did not need to be rewritten.
The Boring Stack Advantage
I run my projects on Laravel. PHP. MySQL. A monolith. Not microservices. Not serverless. Not whatever just hit the front page of Hacker News this week.
And here is what that boring choice has given me:
Speed of delivery. My team knows this stack inside out. When a new project comes in, we are not learning — we are executing. The patterns are muscle memory. The gotchas are already documented in our internal wiki. We have solved most of the common problems before, and our solutions are battle-tested.
Predictable hiring. Finding Laravel developers is not hard. Training them is even easier because the ecosystem is mature, the documentation is excellent, and there are thousands of tutorials, courses, and community resources. Compare that to hiring for a cutting-edge framework where the talent pool is tiny and everyone commands a premium because they are “early adopters.”
Lower maintenance cost. Boring technology has boring bugs. And boring bugs have boring, well-documented solutions. When something breaks in Laravel, chances are someone on Stack Overflow solved it in 2019. When something breaks in a framework released six months ago, you are on your own.
Client confidence. This one surprised me. I used to think clients wanted to hear about the latest tech. They do not. They want to hear that you have built something similar before and it worked. When I tell a client we have delivered fifteen projects on this exact stack, their shoulders relax. That is trust. Trust closes deals.
But What About Innovation?
This is the part where someone says: “But Hafiq, if everyone thought like you, we would still be writing COBOL.”
Fair point. But let me ask you this: when was the last time adopting a new framework early actually gave you a competitive advantage in business?
Not a technical advantage. Not a developer experience advantage. A business advantage.
For most of us, freelancers, agency owners, startup founders, technical leads, the answer is almost never. Your clients do not care if your API is built with the latest Rust-based edge runtime. They care if it responds fast, stays up, and does what it is supposed to do.
Innovation matters at the infrastructure level. At the research level. At the scale of Google and Meta, where shaving off milliseconds across billions of requests justifies building custom tools.
But you are not Google. Neither am I. And pretending we operate at that scale is the most expensive form of self-deception in the tech industry.
I wrote about this before, use a monolith. Seriously. Unless you have millions of concurrent users, a monolith deployed on a single well-configured server will outperform a poorly implemented microservice architecture every single time. And it will cost you a fraction of the effort to maintain.
How I Actually Make Technology Decisions Now
I have a simple framework. Three questions:
Can my team ship this in the timeline the client expects? If adopting a new tool means the team needs two weeks to learn it, and the deadline is in six weeks, the answer is no. We use what we know.
Will I be able to hire or train someone to maintain this in two years? Technology comes and goes. If the framework I choose today has no community in two years, I have built my project on a foundation that is already crumbling. I pick technology with staying power, not hype.
Does this solve a real problem, or does it just feel modern? This is the hardest question because ego gets involved. Sometimes we want to use new tech because it makes us feel like we are keeping up. That is not a reason. That is insecurity disguised as innovation.
If a new tool passes all three, I will consider it. But it has to earn its place in the stack. I do not adopt technology because it is new. I adopt it because it is better “provably, measurably better — for the specific problem I am solving.
The Tender That Proved Me Right
Last year, I submitted a proposal for a government-linked project. The RFP was complex, a multi-module system, tight deadline, strict compliance requirements.
I knew at least two competing teams were pitching with more “impressive” stacks. One proposed a microservices architecture with Kubernetes orchestration. Another went with a headless CMS approach using a JavaScript-heavy frontend.
Our proposal was straightforward. Laravel monolith. Server-side rendering. MySQL. Deployed on a managed cloud instance. Nothing sexy. Nothing buzzworthy.
We won.
Not because of the tech stack, but because of what the stack enabled: a realistic timeline, a clear maintenance plan, a lower total cost of ownership, and a team that had delivered similar projects before without surprises.
The evaluators did not want innovation. They wanted reliability. They wanted confidence that we could actually deliver what we promised.
That is the unsexy truth about winning work: clients pay for certainty. And certainty comes from experience with proven tools, not from experiments with unproven ones.
What I Tell Junior Developers
When a junior developer on my team asks me if they should learn the newest framework, I always say the same thing: learn it on your own time if you are curious. But master the fundamentals first.
Understand HTTP. Understand databases. Really understand them, not just the ORM layer on top. Understand how authentication works under the hood. Understand deployment. Understand what happens when your application gets traffic it was not designed to handle.
These fundamentals do not change when frameworks change. A developer who deeply understands SQL will be valuable whether the industry is running on Laravel, Rails, Django, or whatever comes next. A developer who only knows the latest framework is one deprecation notice away from starting over.
The same applies to technical founders. Do not build your business on a technology because it is trendy. Build it on a technology because your team can execute with it reliably. Your investors might not understand this. Your Twitter timeline might not agree. But your bank account will.
The Real Competitive Advantage
Here is what I have learned after years of building software for real clients with real money on the line:
The teams that win are not the ones with the best tech stack. They are the ones that ship consistently, maintain what they build, and do not waste months chasing architectural perfection that nobody asked for.
Boring is not a weakness. Boring is a strategy.
It means your team spends time building features instead of fighting tooling. It means your estimates are accurate because you have done this before. It means your clients trust you because you deliver, not because you dazzled them with a conference talk about your infrastructure.
The next time someone looks at your stack and says “isn’t that a bit old?”, smile and say: “Yes. That is exactly why it works.”
Then go ship something while they are still setting up their dev environment.
Previously, I wrote about why you should just use a monolith and how AI helped me win project tenders. If those resonate, give them a read.
That is the unsexy truth about winning work: clients pay for certainty. And certainty comes from experience with proven tools, not from experiments with unproven ones.
What I Tell Junior Developers
When a junior developer on my team asks me if they should learn the newest framework, I always say the same thing: learn it on your own time if you are curious. But master the fundamentals first.
Understand HTTP. Understand databases — really understand them, not just the ORM layer on top. Understand how authentication works under the hood. Understand deployment. Understand what happens when your application gets traffic it was not designed to handle.
These fundamentals do not change when frameworks change. A developer who deeply understands SQL will be valuable whether the industry is running on Laravel, Rails, Django, or whatever comes next. A developer who only knows the latest framework is one deprecation notice away from starting over.
The same applies to technical founders. Do not build your business on a technology because it is trendy. Build it on a technology because your team can execute with it reliably. Your investors might not understand this. Your Twitter timeline might not agree. But your bank account will.
The Real Competitive Advantage
Here is what I have learned after years of building software for real clients with real money on the line:
The teams that win are not the ones with the best tech stack. They are the ones that ship consistently, maintain what they build, and do not waste months chasing architectural perfection that nobody asked for.
Boring is not a weakness. Boring is a strategy.
It means your team spends time building features instead of fighting tooling. It means your estimates are accurate because you have done this before. It means your clients trust you because you deliver — not because you dazzled them with a conference talk about your infrastructure.
The next time someone looks at your stack and says “isn’t that a bit old?”, smile and say: “Yes. That is exactly why it works.”
Then go ship something while they are still setting up their dev environment.
Previously, I wrote about why you should just use a monolith and how AI helped me win project tenders. If those resonate, give them a read.