If you are a cofounder and your #1 priority is to rewrite the application then you are their code monkey.

If the offshore team works just stick with it so you can focus on technology strategy.

It's more than rewriting the application -- it's ensuring the foundation is sound.

It would be irresponsible to not be very skeptical of the code as it's usually trash, and trash code will scare away any and all future tech employees. The annual turnover will be >100%, guaranteed. No company can sustain that level of turnover.

> If the offshore team works just stick with it

That is a big "if". A good technical cofounder will identify the latent technical debt that exists in an outsourced prototype and if that number is too high, a rewrite can be justified.

I worked at a company where the founder had started with some local contractors to build an initial version of the product.

He hired a CTO, who took a look at the current code, list of bugs, and new features desired, and made the call to do a complete rewrite.

In retrospect, this was absolutely the right call. It can definitely be wasteful, but sometimes starting with a completely new design is the right thing to do.

But usually what happens is the offshore prototype is junk, _but_ the (non-technical) founders ship it because it's "good enough". Then they want it to be iterated on even though it was supposed to be a prototype.

Every time I have to use an iPhone app with broken non-standard UI components and UX it makes me sad.

That is what non-technical co-founders hear all the time, though -- throw something together that is "good enough" for an MVP, and iterate later.

I find that the real key is working with coders who can refactor one component at a time, without requiring a re-write from scratch. Then you actually can iterate on a junk codebase.

This only works if you've built the software to be a MVP vs. a prototype.

A prototype is something that you build and then throw away, a MVP is the minimum feature set that can be given to customers, developed with the same quality and values as your eventual product that can be expanded upon.

So be clear what your trying to built at the start, and make sure you build the right thing.

I think MVP ≠ prototype. To me prototyping is about the quality of the code, and MVP is about trying to find the minimum feature set.

I think it's a mistake to not throw away a prototype. You could be starting day 1 with so much tech debt that it would take longer to fix it all vs. design and develop an MVP properly in the first place.

Surely he just means he wants a green field to work with. I mean do you really want to start as a Technical Co-founder at a new startup and have legacy systems already.

I think probably a better middle ground would be "have the authority to rewrite it all from scratch". If you're the technical cofounder, you need to drive the technology, and part of the technical side is knowing and being able to throw out junk at the expense of time and money lost if needed, while your cofounder side should be carefully balancing up the value of doing so.

If the offshore stuff works, great, build on it. If it doesn't rewrite it.

If the architecture is good, but not the implementation, incrementally swap out what you can, as you need.

Nothing is a worse conversation than an engineer trying to rewrite all the code for no business critical reason. I definitely understand that working with crappy offshore code is a pain in the ass (doing that now!), but if it works, it works. I've worked on enough crappy code bases for successful companies (as in $100M/yoy revenue on "prototype" code) to realize that these worries we have as an engineer really don't matter. The only thing that ultimately matters for the business is having something that people want to use.