i’ve joined a lot of projects mid-flight. as a freelancer, as a tech lead, as the person someone calls when things aren’t moving anymore. some of those projects were humming along nicely. most were stuck. after a while you start seeing the same patterns everywhere.

here’s what i’ve seen.

the build takes 10 minutes

this one is so common it’s almost boring to mention. but it matters more than people think.

when your dev server takes forever to start, when saving a file means waiting 30 seconds to see the change, when CI runs for 20 minutes before telling you a semicolon is missing — developers stop experimenting. they batch up changes into big, risky commits instead of small, safe ones. they stop refactoring because it’s not worth the wait. they dread touching anything.

i’ve walked into codebases where the team had collectively given up on hot reload. they’d make a change, go get coffee, come back, check if it worked. that’s not development, that’s archaeology with extra steps.

fix your build first. it’s the fastest win you’ll ever get.

nobody knows what “done” means

“can you make this page look better?” — sure. what does better mean? “you know, more modern.” great, i’ll get right on that.

i’ve sat in sprint plannings where tickets said things like “improve the dashboard.” no mockups, no acceptance criteria, no definition of done. the developer builds something, the stakeholder says “that’s not what i meant,” and we’re back to square one. three sprints later the ticket is still open and everyone’s frustrated.

the fix here isn’t complicated: write down what done looks like before you start. a sentence or two is enough. “the user can filter the table by date range and export the results as CSV.” now we know when to stop.

the codebase has layers of archaeology

every project accumulates history. that’s fine. what’s not fine is when the codebase has three different state management approaches, two abandoned migration strategies, a folder called utils_new_v2, and patterns from a framework the team stopped using two years ago.

i once inherited a project where the previous team had started migrating from REST to GraphQL, got halfway through, and then left. so half the app talked to one API, half to another, and there was a translation layer in the middle that nobody fully understood. every feature took three times longer than it should have because you had to figure out which universe you were in.

you don’t fix this all at once. you pick a direction, document it, and clean up as you go. but someone has to make that call first.

the team is a bus factor of one

there’s always that one person. the one who set up the infrastructure, who knows why that weird cron job runs at 3am, who wrote the auth system from scratch. everyone else routes questions through them. they’re in every pull request. they’re the bottleneck, but nobody says that because they’re also the hero.

this is a people problem disguised as a knowledge problem. the fix isn’t documentation (though that helps). the fix is deliberately spreading ownership. pair on things. rotate who reviews what. let other people make mistakes in areas they don’t know yet. it’s slower in the short term and essential in the long term.

people problems wearing technical masks

this is the one nobody wants to talk about.

“we need to rewrite the frontend” sometimes means “i’m burned out and i want to work on something new.” an architecture debate that goes on for weeks is sometimes two people who don’t like each other expressing it through technical opinions. someone who’s checked out and only doing the minimum — that’s not a performance problem, that’s usually a management problem.

i’ve seen teams stuck for months on technical decisions that were really about trust, or autonomy, or someone not feeling heard. you can’t fix those with a better tech stack. you fix them by talking to people, one on one, and actually listening.

no one is making decisions

five open pull requests, no merges. two competing proposals in a google doc, both with good arguments, no conclusion. “let’s discuss this at the next meeting” for the third week in a row.

sometimes projects stall because nobody is empowered to — or willing to — just make a call. not every decision needs consensus. not every choice needs to be optimal. a good-enough decision made today beats a perfect decision made never.

i’ve unstuck teams just by being the person who says “let’s go with option A, we can revisit in two weeks if it’s not working.” that’s it. no magic. just someone willing to decide and take the heat if it’s wrong.

getting unstuck

there’s no silver bullet, but if i had to boil it down:

fix the developer experience first. fast builds, fast feedback, fast deploys. this gives you momentum and makes everything else easier.

make requirements concrete. even a single sentence describing what done looks like saves hours of back-and-forth.

spread the knowledge. no single points of failure. rotate, pair, document the weird stuff.

talk to people. the technical problems are often symptoms. find out what’s actually going on.

make decisions. someone has to. it might as well be you.

most stuck projects don’t need a rewrite or a new framework or a bigger team. they need someone to walk in, look at the whole picture, and start making small, deliberate changes in the right order. that’s the work i do.

---

if your project is stuck and you want someone to help get it moving, get in touch.