You will write a framework whether you meant to or not

You don’t need a big framework or a pile of components to build an application. That’s true and it isn’t the end of the argument.

In any sufficiently complex application you’ll end up writing a sort of mini framework of your own because you’ll abstract the things that turn up more than a few times and that’s what abstracting them produces. It might be really nice at the start. Small, fitted exactly to the problem, no concepts you don’t need. Then the project continues and it gets hackier, especially when you’re short of people or time and the abstraction has to bend around something it wasn’t built for.

Eventually you’ll regret not using something standard. If there are more than a couple of developers involved it’ll be something nobody much likes after a year or two, and everybody will have a slightly different theory about which part is the problem.

The effect on hiring is where it really bites. Junior developers won’t want to be on it because from their side it’s old legacy code that teaches them nothing portable and looks like nothing on their next application. That makes it harder to find people who want to join which makes the team smaller and more senior and more attached to the thing which makes it harder still.

Then comes the part everyone can see coming. As recruiting gets harder because the codebase sits on a strange framework nobody knows, there’ll be a large project to move it onto something standard. That’ll probably be React because that’s what people know.

At the same time most of the senior developers will be arguing to scrap the whole thing and rebuild from nothing. They’ll be wrong, in almost every case and it won’t matter because what they actually want is a greenfield project where they get to try new things. That’s a completely human thing to want and it’s not a technical argument and it wins a surprising number of these debates anyway.

This story has played out at every large company building applications internally, and at a lot of startups once they matured enough to need real hiring. It’s so consistent that you can more or less read the year off which stage a team is at.

Which means you might as well skip it. Not because the standard framework is better in any interesting technical sense, and often it isn’t. Because the alternative isn’t no framework. The alternative is a framework you wrote by accident, that only your current team understands, that nobody documented and that you’ll spend three years migrating away from.

The honest version of the choice is between a framework with a community, documentation, hiring pool and upgrade path, and one with none of those that happens to fit your problem exactly on the day you started.

The counter-argument worth taking seriously is that a framework you wrote fits your problem and a general one doesn’t, which is true on day one and gets less true every quarter afterwards. Problems move, and the general framework has thousands of people pushing it to cover new ground while yours has whoever is free that sprint.

There’s a narrow case where writing your own is right. It’s when the thing you’re building is genuinely unlike what anyone else builds, and you can afford to keep a team on the tooling itself for years rather than treating it as something you’ll tidy up later. Almost nobody meets both conditions and almost everybody believes they meet the first.