Developers default to the stack they know. That comfort feels productive - until the project grows and the bill arrives. I call this the biased symptom: choosing the familiar tool instead of the right one.
My Journey Across Technologies
Like many developers, I started in my teens with PHP - when the back end rendered the front end and jQuery sprinkled the UI.
At 22 I joined a small Drupal boutique, then spent three years in Python, four in JavaScript, and now I’m back in Python. Along the way I tried Golang, touched some Java for my never-finished B.Sc., and explored plenty of tools. After enough projects, certain patterns keep repeating.
What Is the Biased Symptom?
The biased symptom happens when we choose a technology not because it’s the best fit, but because it’s familiar.
It shows up in startups all the time. Before LLMs you’d reach for Python or Node.js, React or Angular, and start shipping. Today it’s even easier to accept GPT’s first suggestion and roll with whatever stack it spits out.
But as the project grows, reality sets in:
- CI/CD pipelines must be designed and maintained.
- Data migrations get painful.
- A missing field in a user schema forces rewrites.
That’s when the biased symptom becomes expensive.
Laravel as an Example
Take Laravel. Many developers dismiss PHP as “old” or “not scalable,” yet Laravel provides:
- Artisan CLI for fast scaffolding.
- Built-in migrations and modular structure to keep code organized.
- Livewire and Blade for modern front-end patterns without heavy SPA overhead.
- A broad first-party ecosystem, plus tools for browser tests (e.g., Laravel Dusk).
- First-class testing with PHPUnit and Pest.
These save time versus cobbling together equivalents elsewhere. The point isn’t that Laravel is always the answer - it’s that dismissing it without evaluation is the bias in action.
Common assumptions worth challenging:
- “PHP is old.” So is Git. What matters is capability and context.
- “PHP doesn’t scale.” Poorly designed systems don’t scale - regardless of language.
- “PHP isn’t evolving.” It is; the ecosystem keeps moving.
A Real Client Story
A client thought they needed a CMS. My first reflex was Drupal - I know it deeply and could have spun it up quickly.
But their internal team was Python-based. Introducing PHP would add complexity and long-term friction.
So I paused and built small MVPs to test alternatives. When I presented options, the team lead said:
“A few months ago, Drupal might have made sense. Today, our technical team will own this project.”
That was the turning point. We pivoted to FastAPI + React. The result was an internal infrastructure project with:
- React components using atomic design and Ant Design abstractions.
- Types generated from backend APIs via OpenAPI/Swagger.
- Tight TypeScript integration to boost developer confidence.
- CI/CD pipelines and Storybook for smooth collaboration.
Drupal wasn’t “wrong” in general - just wrong here. Avoiding the biased symptom saved future headaches.
Takeaways
- Pause before committing. Don’t default to the tool you know; restate the problem and constraints first.
- Invite outside input. If the best tool isn’t in your toolbox, lean on docs, experts, or quick MVPs to compare.
- Separate fit from comfort. Great tech fails in the wrong context.
Failure is valuable - if you learn from it. Choosing the right tool, not the familiar one, is how you avoid paying too high a price.
