One Stack, Ten Repos: What Changed for Developer Experience
Why timing mattered when consolidating our codebases, and how AI turned it into a job one developer could finish.
When I joined, I noticed that almost every repo was set up differently.
Some used npm, some used yarn. Some were written in Flow, some in TypeScript. Every repo ran a different Node version.
Each repo worked fine on its own. The trouble started when you moved between them.
10 repos, 10 ways of working
Nothing was broken. Builds passed and features shipped. Each repo reflected when it was created and who worked on it at the time.
But picture a developer who works across several of them in the same week:
- Which package manager does this one use? Which Node version do I need? Why is the lockfile complaining?
- The commands I typed from habit a minute ago don’t work here.
- The test, build and CI setups all differ.
Each issue is small, but they add up on every context switch.
Developer experience is head space
I think of developer experience as one question: how much of your head is left for the actual problem?
When the repo is a puzzle, the answer is “less than you’d like.” You spend the start of every task re-learning how this repo works before you can touch the business logic. No sprint report shows that cost, but the team pays it on every task.
New joiners feel it most. Instead of learning one way of working, they memorize ten and keep track of which repo follows which.
Maintenance multiplied by N
Every improvement also has to be made once per repo. A Node upgrade becomes N upgrades. A security patch becomes N patches, each with its own quirks. A CI improvement gets rewritten for N setups.
Work that costs N times as much often doesn’t get done, so the repos drift further apart.
Picking the moment
I didn’t start this on day one. Pushing standardization before you understand where the team hurts tends to fail. [NEED: what made it the right time, e.g. a specific incident, release or onboarding.] Once that was clear, we set one rule: one stack, the same in every repo.
Get Sabrina Miao’s stories in your inbox
Join Medium for free to get updates from this writer.
The target stack:
- Language and runtime: TypeScript, React 19, Node 26, pnpm
- Build and test: Vite, Vitest, Playwright
- State and CI: Zustand, GitHub Actions
I worked through the repos from most to least active. The busiest repos had the most people feeling the pain, so they got relief first and the payoff showed up where activity was highest.
Where AI fit in
Deciding what “standard” meant took longer than writing any of the migration code.
Once the stack was locked, the work was repetitive and well defined: move to pnpm, convert Flow to TypeScript, swap in Vite and Vitest, align GitHub Actions. AI handles that kind of refactoring well. With the target fixed, each repo took about 2–3 weeks with one developer.
A consolidation like this used to sit in the “someday” backlog because the cost never seemed worth it. With AI doing the repetitive parts, one developer could work through the whole list once the timing was right.
People decided the standard, and AI helped carry it out.
What changed
Developers move between repos with less friction: same package manager, build tool, test runner and CI shape. If you’ve written a test in one repo, you can write one in any of them. Nobody spends the first hour of a ticket figuring out how to run the repo locally. Dependency upgrades and security patches are now predictable and scriptable across all repos.
Running a technical uplift in your team
- Wait until you understand the friction points across the team.
- Decide the stack before touching code. The decision is the hard part, and the rest is execution.
- Start where the pain is highest, with the repos your team touches daily.
- Keep the standard small and boring so nobody has to think about it.
- Use AI for the repetitive middle, and keep architectural decisions with people.
Closing
None of this is glamorous. Nobody ships a user-facing feature because lockfile formats match across repos. But every feature on our roadmap is now built by someone who didn’t have to relearn the codebase first.
How consistent are the repos where you work? Tell me what has worked, or failed, for your team in the comments.
