That's how new ideas are formed: there is already something there, an intuition, but it needs articulation. I'm sure you're about to find out what's really behind the intuition so it's also clear how to think about momentum in these cases.

For some reason or another I think your blog posts are really starting to improve. Posts like "Oppositional Identities" are really insightful, like the inevitable future blog post exploring this intuition. Maybe you have been doing this all along, but for this individual reader they seem to get more profound.

By the way, about faster feedback loops: are you familiar with the military strategist John Boyd? His essay "Destruction and Creation" deals on a very high conceptual level with the importance of fast feedback loops.

Relate it to one of those carnival shooting games. You have X amount of ammo. But if you don't hit this target, you don't get to go on to the next round. You've missed twice already. But the target is moving steadily to the right and is almost to where you can't shoot at it anymore. What do you do? If you don't shoot, you don't waste ammo. But you don't make it to the next round for a bigger prize.

This'll probably be pretty disorganized, because I'm more or less just dumping my thoughts to see what comes out.

It seems like you've got a few up front costs by waiting three weeks to release: #1. You lose three weeks of profit. #2. You use three extra weeks of the programmer's time. #3. You keep people waiting on a fairly long timeline without prior warning -- they didn't see this coming, and now they might worry that there will be future holdups that they won't see coming. They might start to lose faith that the project's actually going to get released, and so be less willing to dedicate resources to it.

But if you've already got it out there, being tested by customers, and making money for you, then you don't have to worry about #3 -- you've got momentum, you've got some more capital to confront problems which may come up, and you'll have a much better idea of what you need to do to improve it, so your programmer doesn't potentially end up wasting 3 weeks doing something that didn't have as much benefit as you predicted.

Sounds to me like I just rephrased what you wrote, but I thought I'd take a jab at it.

who cares, as long as the customer doesn't notice and isn't negatively affected... that should be the primary consideration; will the customer experience suffer in any way and/or will it negatively impact our prospects for growth and expansion down the road...

don't let a technicians desire for perfection and flawlessness get in the way of winning!

I took your post as kind of a thinking exercise, I wrote below what I thought about it. Please don't take any of it seriously. I don't have enough real-world project experience.

If I were in that situation I'd like to say that I would start by asking questions, but it probably wouldn't occur to me because I'd probably be too emotionally involved.

How fast do you expect to grow? Or better yet, what probability do you estimate for growth at different rates?

If you expect to grow really fast then that 1 hour of support /per customer /per month can quickly become a really big liability. Not just in possible upset customers, but in the necessity of bringing in more staff. That means more managers, more communication, and more physical resources. That also means that the quality of staff you bring on board will likely have less qualifications because of the time pressures involved in hiring.

With more moderate growth then your CTO can probably pay off the technical debt after launch. Take care of your CTO during that timeframe, that situation can quickly become highly stressful. Make sure that your CTO gets a really long, good vacation after things have settled down. Burnout is unproductive for everyone involved.

With slower growth, you can easily handle the customer support time. Then your CTO will probably have plenty of time to handle a redesign and elimination of technical debt.

These all assume that you customer support time estimate are correct and that your CTO will still want to do a redesign later on.

How much ongoing programming maintenance do you estimate after the launch?
How much of that maintenance could a new hire/contractor perform?
Taking some of the maintenance work off of the CTO's plate will give them plenty of time to focus on the redesign/reimplementation. This approach has a couple of well known risks associated with it. Malicious individuals, getting the new person up to speed on the code base, etc.

How critical do you consider those three weeks? Do you have a lot of resources waiting on this? Potential competitors that may launch?

If its critical you'll want to launch if you won't have a broken project.
Since it sounds like you have people waiting for this finish (at least 2) then launching it becomes more critical.
Which parts of the project do the next stage people need? All of it? A subset? Can you launch a working subset of the project so that they can get started, and in the mean time let you CTO rebuild the system?

If you can handle the disruption, see if you can cut anything out that will let you do the redesign and lose only a week or two. That way you get a more robust and hopefully better designed system, you don't lose 3 weeks, and you can go ahead with a more limited, but more scalable launch only slightly behind schedule.

Of course both of those approaches really depend on the malleability of the project in question.

What probability do have that the customer support issue will take an hour/month? What happens if it takes a lot more? Or a lot less?
If it takes a lot less then it's no longer a critical problem. You can fix it after the launch.
If it takes a lot more then the redesign may become a lot more useful.

How much future development do you plan? Will this 3 week cost turn into a large savings later on from a more flexible platform?

Final Thoughts: Given that I have no information other than what you've told us. I think that if you have decent risk estimates on everything, you'll want to push forward and launch. The other advantage you get from launching, you find some of the other sticky points in your design.

As a developer I've been in a similar situations that went both ways. One where it worked out, and another where launching ended disastrously. I consider both really good learning experiences, the second one just hurt a lot more.

Good Luck, take the above with a grain of salt, I just found it a fun thought experiment.

I agree, Sebastian, and I add that as that team becomes more successful at launching projects, building them right will be more viable and more important because the problems down the road are real, even if they aren't primary.

To use a baseball analogy, hitting is more important than running to base until the batter has it down, because it comes first. Then running well becomes more important as the number of tagouts becomes the new problem. Then stealing becomes important once getting to base becomes easy...it goes on.

I don't know, I certainly don't have the whole picture here but technical debts the sooner are fixed the better. You think it's easy to translate an app to another language/framework but the reality is you'll always have something more important to do, and at that point you have to hope your programmers will stay with you despite the big technical debt (they warned you after all). And it's actually not that simple to do, and will cause more problems than benefits.

Also three weeks to me don't sound like a lot of time, but again I don't have the complete picture here so I can't judge properly. But if you want my 2 cents, listen to the people who are building your product, if they're saying this to you now they're probably being conservative, and the reality may be much worse.

Here's Rands' take on the/a similar issue:

http://www.randsinrepose.com/archives/2003/08/05/incrementalists.html

I love this website. That guy is clearly very smart.

If it 's a prototype Minimum viable product, yes you are correct in the theory you can fix things later on If you reach market traction.

If it's something that could down the entire business if everything fails in the future... Well.. it depends.

Focus on the priority goals of the system you're building, and if those goals are met, yo're safe.

If things will go your way and you have bugs down the road, I suggest not focusing on the technology stack but thinking out of the box, and trying to find ways around it. Look at facebook. They're still using that database but they haven't really shut down. What happened? They did several work-arounds like Memcache and inventing new technology to cope with the demand.

Cheers,

Joe