Ask HN: When to walk away from a toxic project

[BurnerAccObv]

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?

[montrose]

Counterintuitive as it may seem, this startup may be doing things right. If user growth is causing load issues, that means users like the product, and that the company is growing fast, which is the high bit of predicting whether a startup will succeed.

A 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.

[brianwawok → montrose]

> Counterintuitive as it may seem, this startup may be doing things right. If user growth is causing load issues, that means users like the product, and that the company is growing fast, which is the high bit of predicting whether a startup will succeed.

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 ;)

[joeblow9999]

'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.'

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.

[pista]

The real threat for you is becoming the hero that must put ridiculously long hours to keep the wheels running. At that point I would ask for underlings, a big pay or leave.

[gus_massa → pista]

Exactly. How much hour a week are you(OP) working?