Boring stack is a brave call
Three months ago a developer messaged me: "You're still writing PHP? Isn't that a waste of your time?"
I sent him a screenshot in reply. Revenue from our production systems over the last quarter. He didn't follow up.
Choosing a boring stack isn't about being lazy with upgrades. It's about picking the right tool for the job, not for the resume. In 2024, when AI tools have reduced the barrier to entry for any technology to near zero, the question of how to choose a technology stack for a project has gotten harder — because rewriting is cheap now, and the consequences are the same as they've always been.
Where the pressure to switch comes from
It's not clients driving the pressure. Clients want speed, stability, price. They don't care whether the catalog runs on PHP 8.2 or Go.
The pressure comes from us. From the feeling that a "real" developer should use a "real" stack. From the fear of an interview in three years: "Why are you still on Bitrix when the whole industry went headless?"
I've felt this. Three years ago I seriously considered moving all new projects to Node.js — because "PHP is outdated." That's what the dev Twitter said. That's what I saw on Hacker News.
Then I looked at the numbers. The projects actually earning money and running without 3am incidents. All of them on PHP. Some are four years old. One catalog — 28k SKU, Bitrix + Elasticsearch — hasn't gone down under load in 2.5 years. Because the stack was chosen for the job, not the trend.
What "boring" actually means in 2024
"Boring" isn't a synonym for "legacy."
PHP 8.2 in 2024 has a JIT compiler, fibers, named arguments, union types. Bitrix is infrastructure with 20 years of reliability history in high-load Russian retail. Elasticsearch 8.x is a search standard maintained by Elastic with 4,000+ employees.
"Boring" means predictable. I know what breaks and how to fix it. The next developer who joins the project in a year won't have to retrain from scratch.
A project on a hyped stack often looks like this a year later: author left, no documentation, dependencies three major versions behind. A PHP project a year later is just a PHP project. Same problems, known solutions.
Three questions before I consider a new technology
I stopped asking "what's trending" and started asking three questions. If I can't answer them, the stack doesn't change.
What does it cost NOT to know this tech in two years?
Not "how good would it be to know it" — but what does the ignorance actually cost. Which clients will I lose? What projects can't I take? How much money is that?
For Go or Rust — the answer is usually "nothing" for my type of work. My clients are e-commerce, corporate portals, heavy catalogs. They need a solid Bitrix developer, not a high-throughput architect for hundreds of thousands of RPS.
For TypeScript in 2021 the answer was "enough to learn it" — because Next.js became the standard for the headless frontend I build. I learned it. It paid off.
Is the problem new, or just the tool trending?
If the problem is the same and the tool is new — that's almost always risk.
A web shop catalog with 50k SKUs isn't a new problem. It has known shapes, solved issues, familiar bottlenecks. Rewriting it on a new framework to "scale better" means creating new problems where there weren't any.
Different example: automating a content pipeline with Claude Code and MCP. That's a genuinely new problem without accumulated prior art. Experimenting with new tools there makes sense — because there's no well-worn path to default to.
Who maintains this in a year when the hype fades?
Not "who can build it" — who will maintain it. Those are different people.
Anyone who's watched enough YouTube tutorials can build something on a hyped stack. Maintaining, debugging, scaling — you need someone with production experience. For Bitrix there are thousands of available engineers in the Russian-speaking market. For Bun or SolidJS — I'm not sure I could find a replacement quickly.
When I turned down a $40K contract to rewrite a Bitrix system, this was the question that made the decision. Not "can we rewrite it" but "who maintains this as it grows." The answer was uncomfortable.
When I changed the stack — and regretted it
Here's a story that didn't go well.
Two years ago I picked Python for an internal studio tool instead of PHP. The reason was simple: I wanted to try FastAPI, I'd seen it in several impressive projects. The task itself was a standard CRUD with straightforward logic — something PHP would've handled in a day.
Result: three days to build with FastAPI. Then six months maintaining the deployment environment, dealing with dependencies, explaining the structure to a colleague. Eventually I rewrote it in PHP in two days. Done.
This isn't a knock on FastAPI. It means the problem didn't need a new tool. I brought the new tool for my own curiosity. The cost of that curiosity was time I could've spent on something that mattered.
When the boring choice is a mistake
I'm not defending stagnation. There are real cases where the conservative choice is wrong.
- Your team doesn't know the chosen stack and there's no time to train. Then someone else's "boring" is technically unfamiliar to you.
- The problem is genuinely new with no mature solutions. Experimenting there is justified.
- The vendor is dropping support. That's not hype — that's real risk. Python 2 was a real example.
- The job market for your clients overwhelmingly requires a different stack. If that's your market, count the career cost honestly.
The difference between conservatism and getting stuck: is the choice conscious? If I can explain why PHP is better for this specific job, that's conservatism. If I'm just afraid to learn something new, that's a different problem entirely.
The short version
Choosing a boring stack in 2024 takes more courage than jumping on the hype. Because hype comes with social approval. No one needs to justify choosing the trending thing. Choosing PHP requires explanation — to clients, to colleagues, to yourself in moments of doubt.
Three questions:
- What does it cost not to know this tech in two years?
- Is the problem new, or just the tool trending?
- Who will maintain this in a year?
If the answers point to something new — I switch. If not, I stay. No apologies.
*If you're facing a similar decision, or "let's just rewrite it" just came up in your team — DM me. Worth talking through before anyone signs anything.*