Beta launch · Product launch

Should I launch MVP with poor code base or rebuild & launch?

Jose Galindo Founder at MoneyMio

April 27th, 2016

We are building personal finance website for Latinos.

In order to test our idea we decided to build an MVP/prototype using wordpress to shorten development time and cost.

I recently hired a new development team as prior engineer quit and was noticed that the code was not up to par. We have been operating without a CTO given that our technology is simple (to the likes of a credit card comparison site) and thought we could build MVP while taking the time to find the right CTO.

The new development team is suggesting to build from scratch because:

  1. They estimate it might take them two months to build from scratch and estimate it could take them just as long to finish wordpress work.
  2. They are afraid a lot of bugs and issues will surface as they finish work on wordpress. The site would not be good to launch to public as some users could have a poor experience.

The new development team comes highly referred from other startup CTOs and they would be equity partners so economic interests are aligned (no true incentive to try to gain a few extra thousands from us...I hope).

I am approaching this more from a business perspective. Even if the site is not code perfect but operates decently I want to launch to determine product market fit and save time and money.

Some users could have a poor experience but want to validate the idea. Thoughts?



You have an idea. Now it’s time to turn it into a brilliant and beautiful product. In this course, you’ll learn specialized tactics to study your user, create testable wireframes, and transform them into fully functioning features and products.

Bill Lennan Red Rope Social - everyone is an influencer.

April 27th, 2016

Launch now!

I've done more new launches than I can count. 
Every time we had known issues. 

We also had a boatload of business hypothesis - of which a significant portion were ultimately found to be incorrect.

You can spend the time and money to write great code wrapped around bad business assumptions and that's just a loosing game. 

You can always do an invite only launch - start with 100 people. See what works, what breaks, what they completely miss. 

I love elegant code - but all the elegant code in the world won't save you from a bad business hypothesis. 

Michael Brill Technology startup exec focused on AI-driven products

April 27th, 2016

If you trust your new technical team and you said:

  1. They estimate it might take them two months to build from scratch and estimate it could take them just as long to finish wordpress work.

..then you're not going to get to market faster with your existing crappy code. If you truly trust your team, they've already made the decision to rewrite it because finishing the existing code doesn't get to market faster. 

It doesn't sound like you really trust them though.

Dan Meier

April 27th, 2016

In my experience, development teams, no matter how good, are typically lousy at estimating project duration. My rule of thumb has been "estimate and triple" -- I get my developers' best "gut instinct" estimate, then triple it to get a realistic project duration. (Don't, however, let your developers know you've tripled their estimate, else they'll take even longer!) This has consistently resulted in "real-world" estimates that are pretty close without spending a ton of time analyzing project design and architecture to get a better, more informed estimate.

One more thought. Developers -- particularly the best ones -- tend to have a "not invented here" mentality. The code is crap if they didn't write it. They may well be right. However, if you're always re-writing everything (because developers come and go), you'll never release anything. Particularly for an MVP, "good enough" is the key consideration. You need to get feedback from your customers, and the sooner the better. There will always be time to "optimize" the code later...if you have a viable product.

Duc Duong

April 27th, 2016

I would go with rebuilding from scratch. Honestly, developers hate to continue to work on a mess created by others. When they are not happy, they will not be productive.

I bet you already have all the UI design, database schema, workflow,... Rebuilding should be quick, probably less than 2 months if you have a good team. (I'm talking about normal MVPs though, I don't know how big your MVP is)

Jake Carlson Software Development Manager at Oracle

April 27th, 2016

Maybe I'm missing something, but exactly how close to complete is this project? Devs always want to write everything from scratch and make it their own (I'm speaking as a dev). If there is hardly any code written, let them. As other have said there is value in making them happy, as they will be much more productive that way. If it's close to completion, this is not the right move. Have them slog on and finish it up, learn from the MVP, *then* build from scratch when you have learned enough to make it worth it.

Edward M. Yang

April 27th, 2016

Perfect is the enemy of good.

If I remember correctly from Lean Startup by Eric Ries, it advocates validating a product idea as early as possible, regardless how polished or finished it is.

David Albert Founder & Principal at GreyGoo

April 27th, 2016

"Perfect is the enemy of good."

Absolutely agree--but the principles of Lean Startup are to launch with an MVP, not code that is buggy, sluggish or unstable. There's a difference between polished and finished vs. buggy--the latter risks turning people off depending on the severity of those bugs. That's the judgment call you really have to make.

Michael Barnathan

April 27th, 2016

Others have given you good advice, including the desire most developers have to start over regardless of the existing code. Your new CTO will want to start over when seeing what the contractors are writing too.

I'm just going to say "find a tech person you trust, and involve that person in the day to day technical decision making, not just as an implementor". You're coming at this with the "engineering resource" mentality, and as a result, you're not understanding how to recruit, retain, and deliver. Writing code is important, but understanding how a technical project is shipped and planned is equally important.

I hear a lot of sob stories about CTOs who had left startups. In almost all cases, some questioning revealed that the rest of the founding team didn't understand that that role is about way more than writing code, and the CTO getting fed up with technical micromanagement, which in a team with one developer equates to being everybody else's whipping boy.

David Albert Founder & Principal at GreyGoo

April 27th, 2016

It depends on the extent of the issues and bugs. I agree with Bill that things don't need to be perfect, but launching with something unusable is going to hurt you more than help prove out your model.

If that's the outcome you fear, as someone who has been through this numerous times in working with and consulting start-ups, build from scratch. You'll likely regret it if you don't. Obviously that's my advice from just the information from your post and an accurate recommendation would require true due diligence, but 9 times out of 10 just licking your wounds and rebuilding is the best route. We've had startups launch with bad code, had early wildfire success and ended up creating a bad reputation and pissed off customers because they couldn't patch the mess fast enough once they had paying users.

Duc Duong

April 27th, 2016

I had a comment above and want to add:

Your prior engineer left and said the quality is sub par, it's the red flag.

If your MVP has too many issues and crashes frequently, how would you know if users don't like your idea or give up because of the inconvenience. MVP doesn't need to be perfect, but needs to be usable.