Ask HN: When to walk away from a toxic project
Few months into a consultant job with a young A-round start-up job here in the states, i have discovered that several bad architecture decisions were made years ago by senior programmers that means their product wont scale without massive amounts of re-engineering. Simple stuff, lack of cloud architecture, zero capacity planning, low test coverage, no redundancy/load-balancing.
As the customer base grew, my daily job has moved from building out functionality, to keeping the server going for 24 more hours in the face of load issues, and the development team seem transfixed on building out new features instead of addressing the underlying rot.
A lot of me is fearful that the company is buying time until the founders can exit, and pass the problem on to the new owners.
In this position, do you stay, and hope the company wakes up to its scaling issues (that management are more than aware of), do you take it on yourself to engineer the fix with no support and risk owning the new design, or do you walk away from the project, knowing its doomed to fail if it carries on its current trajectory?
5 comments
[ 2.0 ms ] story [ 22.6 ms ] threadA startup with a product users love but creaking infrastructure is better off than one with excellent infrastructure and a product that's a dog.
Startups with both a product users love and excellent infrastructure? A lot rarer than you might think, especially at this stage.
Yes this. In a perfect world, you have a perfect design and lots of growth. In the real world, sometimes you have a lot more of one than the other. Trust me when I say you would much rather be running an app with 100k users and scaling problems than an app with 3 users that can handle 1 million users.
That said, what are you doing to fix the root problems? I bet they could use someone to take ownship of the large issues. Come up with a 1 year plan to resolve the issues. Maybe 6 bigger projects of 1-3 months each. Present them to the owners, and try to get buy in to do them over the next year. I bet you could work 50% on firefighting, and 50% on making big changes - and get the app to a good place in a year. I run a tiny startup, but I would love any employee that did that ;)
That is exactly what is happening. Leadership us under no illusions about their platform. However, an exit strategy like this is typical and not necessarily bad for anyone. The buyers often don't care about platform quality as they are going to rewrite most of it during integration.