1) The code is broken. If it's broken, a rewrite is preferable to an involved patch. What constitutes "involved" depends on time constraints and personal taste.

2) I'm about to build on top of the old code. If I'm going to extend or build on top of something I know is crap, I'll rewrite it (time permitting). Fixing it later will be substantially harder the more it's used, so it's best to fix it now.

I've also become more restrictive in what I consider bad code. Bad architecture and interface design are killer. It's nearly impossible to write something good on top of a crappy framework.

For example, if a method body sucks, but the parameters and return type are fine, I'll leave it be. The implementation can be rewritten later if needed.

However, if when writing some new code I find myself using a bunch of switch statements when the strategy pattern is more appropriate, I'll fix it immediately. It's infinitely easier to fix such things when you're adding the third concrete strategy than the sixth.

Also, on a completely unrelated note, if you can implement everything they've done "in a couple days," you'd better be getting founder equity. Furthermore, if the code really is bad and they won't acknowledge it, I'd high tail it out of there. You'll be fighting a constant battle because new code won't be any better.

As with all startups, it's more important to release something - anything - (well ok, not anything!) than to produce perfect code.

http://www.joelonsoftware.com/articles/fog0000000069.html

I have basically sworn off PHP-using companies, because this is nearly always what you find. It works, but it's a horrid mess that they expect you to develop with rapidly, when all you want to do is take it outside and burn it.

You must be prudent in this situation; any sort of rewrite/refactoring will not show visual progress with the product, so while things may be getting better on your end everyone else thinks that the development is stagnating.

Always be weary of actions where the end user won't see results. Refactor on the fly as best you can. Nobody will care (except for you) when you emerge from your cave a few months later and proclaim "The code is nice and clean; now we can proceed!"

In my experience, the only way to have a Rails app that is responsive and reliable without spending most of your time on deployment as opposed to on development, is having someone like EngineYard host it. But that costs 100s of dollars per month, which might be ok in your case, I don't know.

Maybe you want to go with Symphony instead.

I'm not so much against big rewrites, you just have to figure it out yourself if you think it makes sense.

Very easy to deploy as well given that it's written in PHP.

Sounds like a no-brainer. Go for it. Of course, you'd better be sure you can really pull it off in a couple of days. Programmers are notorious for under-estimating these things. But in general, if you're going to be doing something for 2 months or more and you can do something up front that saves you ten percent or so -- do the math. Don't get into "always rewrite" or "never rewrite"

If you can recreate what they're doing that quickly, you're not that far along the development path anyway. There's a whole different answer if they've spent 3 months plugging away at it and already have paying customers. But it doesn't sound like you are there.

Great idea. And ask them about their severence benefits when you do this.

cool new startup ... I think I could do the whole thing myself in a couple days

How cool could it be if their technology is so simple?