How to solve messy startup code in tech startups

The short answer: Don’t. Not right away.

As the Navy Seals say, get comfortable with being uncomfortable.

The longer answer: Wait until your audience validates what you’ve created. Features and single pages can also be looked at as a minimum viable product.

When Twitter launched, it famously had serious uptime problems. The core app was whipped together in literally a weekend, using Ruby on Rails. As usage grew, they stabilized, cleaned up – and tweaked direction using real-world use data.

At – my startup – and more specifically, SwiftCRM and Swift Marketing, my CTO / lead programmer is frequently not happy with the specs given, and/or code that has a bit more duct tape than he likes.

For better or for worse, this is startup life. Perfect is the enemy of done. Slap it together (provided you’re not leaving security holes and/or destabilizing core functions) until your clients are truly getting value.

If everything seems under control, you’re not going fast enough. — Mario Andretti

As the audience grows, code will get rebuilt and refactored for stability and real-world needs. In other cases, the UI and needs evolve after some real-world use, and everything gets tweaked anyway.

Buffer aims for about 10% of their time to be spent on refactoring, and I think that’s a good loose guide. More practically, it gets balanced into priorities, and when we refactor, it’s usually for a specific reason – to make things higher performance (i.e. faster to the page), add features, solve a bug or mis-configuration, etc.

After we’re clear the function is valuable, and in use, and not likely to change much, only then do we go back and develop the nice clean waterfall style specs every coder dreams of.