Junior developers just can't write clear, simple code. They accidentally over-complicate everything, in the most unhelpful way possible. If you have a senior developer that does that, I would consider them a mid-level developer at best.
I've seen this play out in 2 large companies I've contracted for so far.
At the start of a new project, recruitment look for developers with the lowest daily rate they can find and end up with a team of recent grads / people switching careers within the company etc. That's all fine as long as you add a good measure of developers with >5 yrs relevant experience to the mix. But as these people are twice as expensive, they often start without them.
A few years later the product "almost" works. But it's full of bugs, it takes months instead of days to make minor changes, and it still requires an enormous team of people who are all irreplaceable (they possess the "secret" knowledge about the product that usually would be embodied in clear code intentions, past jira tickets, commit history, basic documentation etc.)
Meanwhile a new competitor in the market has developed a much better product.
This situation can last for years (because some companies are a bottomless money pit, despite being tight with it)
Eventually some expensive people get hired to put the "finishing touches" on the product and they start the long slog to fix it up (or just quit in horror after a few weeks)
So far: 1) retired the entire project after years of development 2) company got bought out and the product scrapped after several years of investing money on it 3) is in progress (company has enough money to fund the situation for years, but time will tell if we manage to untangle the mess before it kills the project)
It's not even necessarily their fault; they just need piles of time and mentorship and direction that you can't afford to give yet. Worse, you'll quite possibly end up firing them when you eventually start reigning them in and they don't like being told how to build things.
Trust me, it's been an extremely painful experience.
Had this exact thing happen at my company. It's tough when you have to start doing this, but even tougher if you don't. There are times I certainly think we'd have the same output with half the people if we'd kept the bar higher.
The startup I'm currently working for has the same story. A junior wrote most of the code, but we got hired at the first round. It will take months to solve the spaghetti, but it might work, but I'm very experienced handling even huge and terrible code bases (300-500 thousand of lines of legacy code).
The hardest part is explaining to the owners why it's so expensive to fix everything. They don't understand how it was so cheap to build yet so expensive to maintain.
But a team bigger than 3 developers where no one has any solid experience is a recipe for disaster IMO
With the exact outcome that you describe.
Senior v. Junior is not the problem here. Developing according to your stage and future is. Build things that can be thrown away next week when your product shifts. (ie. low coupling, simple, avoid abstraction adventures).
_Maybe_ "senior" devs are more likely to understand that. I'd argue it's rather devs with any multi-year experience at an early stage startup, regardless of skill level.
- Junior: somebody who is happy that they found a working solution. Most code what they write doesn't even work or they don't know yet how to approach problems.
- Normal / mid-level: developers who can easily find working solutions to problems, but not always the best or easy to understand. Should be able to handle edge cases and errors properly.
- Senior: How to solve problems is not even a question for them, they can come up with multiple ways solving the same problem, but their chosen solution will be flexible, easy to understand (even for Juniors) and maintainable in the long term. When they make a technical debt, it is a conscious decision and not a fatal mistake.
I imagine that after a month, when the senior developer(s) laid down the foundations, it should be possible to find work for the juniors (not all at the same time, but adding them gradually). They just cannot be assigned tickets at random.
They can make things work, but they don't have the experience to avoid tech debt even in the short term.
I have seen this as a CTO, unfortunately I came too late and the company broke.
The terrible management played a bigger part, but the code base was so terrible and the tech debt so big they couldn't ship even very simple features in a timely manner. Testing and release was insanely slow.