Ask HN: Does startups need to focus on execute despite having technical debt?

[nRike]

To give you little context: 230k users since november 2013, 1.4m monthly pageviews, 50% users MoM growth. So at this point we're having discussions whether if we still need to do hacks and monkey-patching our overall system or start doing massive refactors to our core funcionality code. What do you think? Have you experienced something like this?

[throwaway420]

Without having lots of data about your current system, business resources, business health, runway, expected growth, technical challenges, income, expenses, and other constraints it's very difficult for an outsider to come up with an informed decision on how best you can proceed given your unique set of circumstances.

[nRike]

I agree with that. In the more general sense, do you think is a good approach doing monkey-patching, for a startup whose already made their first sales? Lets say we just raised money from an accelerator and no taking outside investment than that.

My main doubt about that is, do you think is a good approach to keep doing crappy code even if we're already doing money with this? And if not, when would be a good moment to start refactoring?

[brudgers]

Somehow I doubt your customers are complaining about the quality of your code and if you are making money there's no business case for rewriting code.

[natdempk]

Its really hard to say without being in your situation, but assuming that you keep growing, it sounds like there's inevitably going to be a point where you need to do some major infrastructure refactoring/quality of life changes. I think that you should plan for that. Looking at your current situation and trying to estimate when you'll need to make these changes for some feature down the line or some major goal should give you an idea of when they'll actually be necessary. That isn't saying keep accruing technical debt infinitely, but rather figure out a natural point of growth/stability where the changes make sense and the debt needs to be erased.

[nRike]

That makes sense. In a personal note, I think doing monkey-patching code is okay in a discovery mode, but now we have a small revenue stream, we should focus on make the platform more reliable, and probably taking our users as the proxy to understand where the product lacks quality.

[brudgers]

Debt provides leverage. If the burden will obviously prevent reaching 2 million page views per month then it might be time to restructure. If it might keep you from hitting 20 million, all the bottle necks on that path havent been built yet. So there's no way to solve that problem now and anyway growing by an order of magnitude is a more important problem to solve.

That's not to say that building a wall around new code to keep the mud out is a bad idea, but that's a response to growth.

[nRike]

I completely agree. I recently started looking for this topic because the feeling I get is that everything is messy and its becoming a nightmare just to think about it. In my case, I'm taking more responsabilities and I think we need to start implementing best practices with our engineering team. Does that makes sense to you?

[brudgers]

Better practices going forward make sense. But rewriting working code should have a business case when the working code solves a business problem. Scaling and maintenance are second order problems. Success is the first order problem.

[sharemywin]

I would set up some kind of performance testing environment of your core pages. Then I would let the numbers guide your decisions.

[nRike]

I like this approach, data cannot be argued.