Leaving PHP, Part 10: the strategic question, not the technical one
Part 1 was hiring. Part 2 was the runtime. Part 3 was types. Part 4 was the ecosystem. Part 5 was the type seam. Part 6 was concurrency. Part 7 was deployment. Part 8 was tooling. Part 9 was migration cost. Every one of those posts was tactical. Part 10 steps back to the strategic frame, because for a platform bet the strategic frame is the only one that matters.
The tactical arguments were the setup
Each prior post in this series has been a single tactical argument. Hiring is harder. The runtime is from a different era. Types arrived late. The ecosystem's gravity is elsewhere. Type sharing across the seam is worse. Async is awkward. Deployment leans on adapters. Tooling is unopinionated. Migration is cheaper than you think. None of those, individually, is a dealbreaker. Every one of them can be argued down in isolation. That was the point.
The nine tactical arguments were the setup for the strategic frame. Each one is a small tilt in the same direction. Any single tilt is easy to dismiss; the accumulation is not. And the accumulation is not what you evaluate a platform bet against anyway. What you evaluate a platform bet against is the direction the whole picture is moving, over the horizon you care about.
The strategic question a CTO actually faces
Imagine you are a CTO in 2026, deciding what your company runs on for the next ten years. The question in front of you is not "is PHP good enough today?" Of course PHP is good enough today. Millions of applications run on it, WordPress powers a large fraction of the web, Laravel and Symfony are excellent frameworks, the hosting is cheap, the talent (though shrinking) is still findable. Nothing in the tactical picture rules PHP out for the next fiscal year.
The question is different. It is: where will the talent, the libraries, the integrations, the cloud primitives, and the AI tooling be in 2030? That is what compounds in your favour over the horizon that matters. Not "is this good today", but "is this the ecosystem the future is being built into". Those are separate questions and it is a category error to answer the second one with data about the first.
Bet on the ecosystem with momentum
The honest answer is that the momentum is not in PHP. It is in TypeScript, in Python, in Rust, and in Go, each for different reasons. TypeScript is where the developer tools land first, where the new frameworks appear, where the type system and the runtime and the IDE tooling all evolve together. Python is where the AI tooling lives. Rust is where the systems work goes. Go is where the cloud infrastructure is written. Every new category of tooling in 2026 (the AI IDEs, the edge runtimes, the observability platforms, the database SDKs) targets those ecosystems first and PHP fifth or not at all.
Bet on what your future hires will already know. Bet on the ecosystem the AI tools were trained on the deepest. Bet on the runtime the cloud vendors natively support. Bet on the languages the new frameworks land in the same quarter they are announced. Every one of those bets is a bet against PHP. That is not because PHP is bad; it is because the world's compounding attention is elsewhere.
What compounds, and what does not
Some things compound and some things do not. A framework you already know does not compound; the skill is fixed and the framework you know now is not the framework you will be running against in five years. Existing business logic compounds until you throw it away, which is why Part 9 matters: you do not have to throw it away. What compounds most, over a decade, is the ecosystem your team is fluent in and the tooling you can build on top of. A team fluent in TypeScript in 2026 will still be fluent in 2036, and everything the ecosystem builds in the meantime will be a lift-off for them. A team fluent only in PHP will be doing the same work with fewer new tools each year.
AI tooling in particular is worth naming. Every major AI coding assistant in 2026 handles TypeScript, Python, Go, and Rust roughly equally well because those are the languages the training corpus is dominated by. PHP works, and it works well for stable idioms, but the ceiling of what AI can do for a codebase is set by how densely represented that codebase's shape is in the corpus the model saw. That gap will widen. It is one of the clearest ecosystem-momentum effects in the whole picture.
Leaving PHP is not about hating it
PHP is not going away. It will run WordPress for decades. It will run legacy Laravel and Symfony applications for decades. It will run internal tools, admin panels, small businesses, and the long tail of the web. "Will not disappear" is a true statement about PHP, and it is a low bar for a strategic technology choice. The bar for a platform bet is not "will not disappear". The bar is "will compound in our favour over the next ten years". On that bar, PHP loses to TypeScript, Go, Python, and Rust for almost every new project.
Leaving PHP is not about hating it. It is about deciding, deliberately, that your next decade is somewhere else. The tactical arguments in the previous nine posts are the reasons that decision holds up to scrutiny. The strategic frame is why the decision is worth making at all. And the migration path in Part 9 is what makes the decision feasible without a two-year rewrite project.
Closing the series
Ten posts, one thesis: the accumulation of tactical arguments and the shape of the ecosystem's momentum both point in the same direction, and for a decade-scale platform bet in 2026, that direction is not PHP. The good news is that the migration path is now a gradient, not a cliff. You can start on the near end and move at whatever pace fits your team, your budget, and your risk tolerance.
Pext exists to make that gradient smoother. If you have read all ten of these posts and you are thinking about what the first step might look like for your codebase, book a demo and we will walk through it with you. And if you disagree with the thesis, I want to hear that too; the comments and the mailbox are both open.