1) There is no way to "determine" this directly. Launch is when YOU (you being the company) say it is.

2) Not necessarily IME, but expect a management shakeup if funding does occur. Your current leadership may be considered unfundable, but if the product is viable the company (legal entity) may be fundable, albeit with some chaos.

3) You can't, however if you've learned things and can articulate how you have learned and grown from the experience (on paper and in person) you should be fine.

4) This is an unlikely outcome on your current path. You would need to have shown some exceptional leadership and insight skills to get to an EIR role. It is possible to do that in the next 6 years, but you would need a launch in the next 12 months, then 3-4 years of steep growth, with yourself playing a highly active role in managing a large aspect of the business through that growth curve. IE: you need to deeply experience the growth and success of a company, be involved in the details, and have clear responsibility for key decisions. You would likely be best off seeing this through and then founding/co-founding something on your own (and taking that corp to an equity event that is considered a success).

</2cents>

1. There are certain milestones we have to meet before we can launch. We have a great product, but we have some holes we have to fill. I can't get more specific here.

2. The leadership of the company is excellent. We're in trouble (in my estimation only) because no startup can afford to have a key person take a dive, and every developer is key.

3. Thanks.

4. Why is it this way? My understanding, and I could be mistaken, of the EIR role is that it's someone who works at startups while sponsored and mentored by the VC firm. I would be excellent in such a position, not now (and possibly never) as an EIR-to-CEO, but as an EIR-to-senior developer (if such a thing exists).

I'll go one step further; in a followup, the author said "[T]he leadership of the company is excellent" when that is demonstrably not so. Just sticking to the technical management part of things, the leadership of this company has known, and should have realized what it meant, that for that last year they had a key coder who was producing unmaintainable code. For the last half year this guy has been melting down and is now non-functional. Yet he is still a "co-founder".

They don't seem to have then necessary sense of urgency about this emergency ("We're in trouble (in my estimation only) because no startup can afford to have a key person take a dive, and every developer is key.").

This is an existential crisis for the venture and there's probably nothing more important for them to do at the moment than resolving it with a good plan, which I just don't get the impression is happening.

We believed that the unmaintainable code problem would be less of an issue after launch, and that this person knew his codebase well enough to keep it on life support until that point, at which we could hire people to fix the problem, possibly with aid of post-launch funding. We assumed it was benign "technical debt" -- a bad technical situation that can be paid off later when resources are less scarce.

What we didn't count on was the meltdown of the person responsible for the problematic code. In hindsight, we should have seen it coming, but it seems like there are always things going wrong in a startup, and everything seems urgent.

I've wanted for a while to fire this guy, throw out his code, and rebuild everything from scratch, but have been under the impression that we don't have the time/turning room to do this. I'm not experienced enough to know the externals (e.g. how hard it is to get funding, etc.) and whether or not this is the case.

If your company had been reviewing his code it would have soon caught him violating his APIs and it's leaders could have taken corrective measures 10 months ago or so.

And you really do have to review the code of people you don't know very well. E.g. at one startup I worked at I finished the ... outsides of a custom tree database (designed deal with misspellings quickly). At a certain point long after it should have came to that, I reviewed the guts of the tree database and found to my horror that the author's undo list for transaction aborts (or power failures, etc.) was entirely in memory....

Otherwise the problems his work represented were of the technical debt variety and due to very good modularization I was able to fix many of them as appropriate. But if the venture had taken off, the above problem could have been a very nasty time bomb (only mitigated by the external parts that recorded all incoming transactions and that allowed for reply).

That company was also a great example of how not to do Customer Development and Lean Startups and a failure to do the lean part of that killed the company just when it took off (new angel investors turned out to be devils).

I once worked on a project where the main developer was fired after 3 _years_ of failing to get the product out the door. There was a lot of code, and it was colossally bad. Worse than anything I had ever seen on The Daily WTF. I and another developer that were put on this project to take it over begged and pleaded that it just had to be rewritten.

We were denied. They didn't know how bad it was, surely. We tried going over heards. We made presentations. We e-mailed around particularly egregious examples, but this was a codebase where the total awful was greater than the sum of the individual horrors, so to speak.

Anyway, over three years this guy, bad as he was, must have worked hard. There was lots of it and we were just expected to 'fix it' since it was 'almost done.' Nevermind that nothing worked. Slowly, steadily, whenever we'd go to fix a bug we would (in stealth) rewrite whatever section we were in. Eventually we started writing adapters to help the new cleaned up code communicate with the bad, bizarre, inconceivable horrors or API design that the old code had. Eventually, like replacing the handle of an axe on one occasion and the head on another, we had a whole new code base that we had come to be proud of.

The lesson I took away from this is it's sort of limitless what this kind of refactoring can accomplish, even if it's not the most enjoyable way to go about fixing a mess. With something like your situation, it's how I'd recommend going about fixing it, since these sorts of things are hard to understand in the aggregate anyway.

Most bugs in any piece of software are concentrated in relatively small proportions of the code. Start there and you might be able to launch with much of his code intact, with the most damaging removed or repaired, and fix the rest in transit.

Or not. You know your situation better than I possibly could, but it's something to think about.

Although you're asking for the advice of VCs or entrepreneurs and there's definitely a personal aspect to the problem, what I'm getting here is a sense that the major hurdle being faced is technical: the code sucks, there's a lot of it, and nobody understands it.

I have found from personal experience that fixing a big, complicated code base is possible. What it will take is some smarts and determination, both of which I'm sure the author of the original post has plenty of. And if you want to end up with a good design, keep it centralized by owning it as the architect with the final say, but leverage your team because they provide invaluable feedback that you can incorporate into the design or disregard as you see fit.

Involving the team in the design also means that you're not the only person who understands the general architecture of the newly designed, refactored system. But you having final say means that someone's responsible for it, someone's on the hook for it, the design is coherent, and that it gets done.

In my case, it was our entire payments system, which was (and continues to be) critical to our business. At the time, the site was live and was taking payments so it was working -- but only like it had been held together with duct tape. Querying our data for insight was maddening, because database tables weren't even named according to what they contained! The guy who was in charge of it before had just been fired, and nobody really understood his code.

Which left us in a precarious situation, like the one you describe. More so, because we were already live. I started off by fixing small bugs here and there, which was a pain at first since I had to learn the inner workings of this deeply flawed system. I took the risk of slowly going insane as I slowly built up a mental map of these poorly named, poorly organized data tables until I could navigate around them as if I had written it myself.

After a while, even a jacked-up architecture starts to make sense in its own crazy way.

But it's dangerous to stay in that place mentally for long, because then you get used to thinking that way.

So I volunteered myself for the task of refactoring it.

Everyone thought I was a psycho for taking it upon myself -- which made it much easier to get everyone to agree to give me final say. The thinking was, "Hey, if you really want to hurt yourself like this, go ahead." But since the messed-up payments data model was affecting the ability of the team to do their jobs, I knew I could count on their input to be as helpful as they knew how.

So, I hit ArgoUML and LaTeX hard as I planned out the redesign. (Those are my preferred tools for architecting and planning. Unusual combination when a Rails project is involved, I know.)

I went through several drafts and ran it by our DBA, who also wears the business intelligence hat, and he told me about really basic metrics he wanted to measure, but couldn't with the old data model. My immediate supervisor, also experienced in architecting, offered suggestions but made it clear that I had final say. Another roll-up-your-sleeves Rails engineer also threw in a few suggestions for how we'd represent the various payment schedules we offered our customers.

This input was crucial and several times pulled me out of the thinking that I had become accustomed to with the old data model. It was scary how willing I had become to keep certain messed-up aspects of the old data model, but that's where exposing the design to the fires of peer review came in. I could have just disregarded everyone's suggestions, but having to give an explanation for why I wanted something to be a certain way forced me to really think about everything.

As for your situation, it sounds like you've got at least some semblance of a good team there to email around these samples of bad code; they can be invaluable in reviewing any proposed design. I know that my team was.

In some way, you'll have even less of a burden should you choose to redesign or refactor. Since you're not live yet, you don't have to worry about data migrations for older data. About half my time on this project was spent thinking about how to move existing live data to the new data model. If you can avoid that, count yourself lucky so that you can focus more of your effort towards building a really clean data model, knowing what you know now.

One thing you haven't mentioned at all is whether you think you will launch and have a revenue stream. How are you going to make money? Do you have customers lined up or just some hopes and prayers that people will flock to your product/service once launched? The reason I ask is that I also firmly believe (again an opinion) that when you do launch, you probably have another 2 or 3 years before you'll get your head above water financially.

I started a business when I was younger and failed (quit gracefully but the trajectory was never headed up). I was hired by somebody I did business with; and trust me when I tell you that on paper I am the prototype of mediocrity. It was actually my mom who suggested that "maybe I stick it out in a real company so I gain some experience". It was a comment that at the time was piercing and hurtful but ultimately right. I did really well at that job, realized I was better at some things than I expected, and that I was worse at some things than I thought I was. I treated it as a learning experience, and the money didn't hurt either.

A lot of companies would be happy to hire you. In their minds, you may not have made it as an entrepreneur, but you'd make a great intrapreneur: someone who is entrepreneurial minded and can succeed within the confines of a safe sandbox which is the company.

But starting a business means actually having to sell something. It's one thing to develop a product or service. It's an entirely different thing to sell it. Once your product/service is on the market, you have to deal with a whole bunch of problems that the first group of people who merely start a "business" but don't actually sell anything, will never have to encounter.

First and foremost, you actually will have customers. Customers are needy. Some are jerks. Some are wonderful and will send you cookies because you've brought a little sunshine to their life. But all customers have expectations and those expectations need to be serviced. Developing an idea into something tangible is in part a measure of somebody's ability to anticipate market needs. Dealing with customers is about how well you can react and fill in the things you did not anticipate or didn't get entirely correct.

Additionally, you'll have competitors. While your customers are pulling you in all sorts of directions with their own needs and wants, your competitors will be sizing you up in their sniper scopes. Having competitors is probably only one of a handful of things in modern life that resembles being prey. You know how fidgety squirrels are and how they are constantly scouring for food only to store it away for future use? Having competition is kind of like that. You will have to balance being a squirrel that is too safe and consequently gets mired down in fear with being one who is so haphazard that she gets mowed down by a car she forgot to look out for while running across the street.

If you have ever started a startup but never actually sold anything, you will never have encountered any customers. You might have encountered some competition that was so overwhelming that you never made it out of the womb, so-to-speak. And in that case, life is just unfair but you'll never know how well you would have stood up given equal footing. Regardless, having experience with customers and competitors are to me, the fundamentals of business. I think a lot of startups are great at developing things, but things are not products or services until they're actually sold.

If you like to develop things and are doing so at the moment, that does not make you a startup or a business. It means you like to develop things. Employees can do that. Employees can get paid very good money to do that. As an employee, you can even form your own little team and manage people like you would in a startup or a business. You can launch products and services as an employee too. But until you've found a way to sell that thing you've developed, I personally don't think you've started your business. A hotdog vendor down the street is way ahead of you in that respect.

Not next month, every day spent in the current setup is a day wasted in the longer term, you need to change direction towards some form of launch, even if it is with an incomplete but minimally viable product.

The 'one more feature' or 'one more milestone before launch' mentality is the most certain way to get killed. If you can't launch before you've completed those milestones and you have internal troubles your chanes of survival depend on the depth of your pockets, and the speed with which you can get the situation resolved.

Your company seems to have two founder problems, not just one, both a developer-founder and the CEO are not currently functioning as they should.

If you are the CEO call a meeting of your co-founders, outline your issues, put up a plan of action and ask for a vote of confidence, if you are not the CEO then try to get your CEO on board. If he won't acknowledge the gravity of the situation you have a real problem.

What I really don't understand is how you've managed to hold out this long without any source of income or funding, 2 years is a long long time.

I wish you much good luck and wisdom, you will need it by the looks of it.

I realize that I'm saying this from an outsider's perspective and I don't know the insider's scoop. Part of being a successful startup requires discovering your MVP (minimum viable product) early. This will then allow you validate your business model and focus on customer development. I highly encourage you to research Steve Blank (if you haven't) and his Customer Development model. Read "Customer Development" [http://en.wikipedia.org/wiki/Steven_Gary_Blank]

I wish you the best of luck and good success.

I think that you would have a great story to tell to future interviewers if you can get the bad code under control and launch the product (even if the startup fails). I would have more confidence in someone who overcame adversity than someone who never faced any problems.

The "+2.5-3 sigma technical and +3-3.5 sigma big picture" stuff would be a big turn-off to me. There's a lot of really smart and talented people in this industry.

Great point. Thanks.

The "+2.5-3 sigma technical and +3-3.5 sigma big picture" stuff would be a big turn-off to me. There's a lot of really smart and talented people in this industry.

Sorry, I guess that does sound arrogant. To be fair, there are a lot of +3, +4 sigma minds in technology. Most of the programmers I've worked with I would put in the "+3 sigma technical" category (because I've worked with some awesome people at great companies). My "sigma" estimates were relative to the white-collar world in general. My point is that I have more than enough to make a great VC, EIR, et al with sufficient mentoring, not that I'm any kind of stand-out (relative to the HN-sphere, I'm definitely not, as there are a lot of people smarter than I am here).

From what I understand, it must be some way to asses someone's intelligence, like the IQ, but I've never heard of it.

Come to think about the IQ, it follows a normal distribution, and sigma is how we note standard deviation. Is this the kind of sigma you are talking about?

LOL. How do you come to that conclusion?

If you don't launch, you're risking everything.

If you do launch, albeit it not 100% ready, at the very LEAST you have a case study on your hands that will help you in other venture and employments. At the very MOST, the people (consumers and investors) see the value proposition in your product and decide to give you a try.

Don't burn the assets, launch with what you got and do whatever it takes to land prototype in front of the right people.

Also, you need to address the co-founder problem right now before it get's more complicated.

> Address the personnel conflict. This conflict may be resolved working with a neutral party in a facilitated meeting or a mediation. Bring all co-founders together and deal with the anger and frustration that’s been accumulating, decide upon a fair settlement with the co-founder that addresses his performance and the quality of his work (whether he stays or goes), then work together to plot out an action plan, assign responsibility for the unfinished code, and agree how to get to the finish line. Several other commenters have given opinions about how to salvage the work and get the code out the door.

> Recruit some pilot customers. Finding some early adopters will give you invaluable insight about your market. Creating a product that fits the market’s needs is more important than making something perfect before it gets a debut. In my experience at other software companies, products significantly improved once we had a small core of users that let us know what their priorities were. We thought we understood the market, but found that it was very challenging to gain insight about rapidly evolving business needs without working directly with customers. You don’t need many, but find two or three companies that will be enthusiastic pilots.

> Reframe your thinking about the experience you’ve gained. If you do not resolve the conflict and must abandon the business venture, you can work with a neutral person to debrief what you learned over the past two years. I have worked for many different businesses over the course of my career. The size and success of the company was not a deciding factor in my professional development, my work was. However, when I had strong feelings about my experience at a company it was often difficult for me to be objective and capture the points where I developed and grew professionally. Find a neutral coach who can draw the positives out of this experience. It will be a springboard to help you see your current situation in a positive light and that will energize you.

Taking these steps will help you get resolution about the company so you can move on, either as a viable business or as a recruitable talent in the startup community.

I just try and salvage as much as I can and try to fit it into a story that communicates my overall goals.

If you've been working for a year and a half and still haven't launched, that, to me, indicates that your product will almost certainly need another year of iteration at least before it starts making any money. Probably 50-90% of the work that you've done so far will be scrapped when you figure out what your customers really want. (yeah, everybody thinks they're different, but they're not)

Combining that with "we're about to run out of runway", and this results in a really bad picture.

I don't know what exactly is right for you - you'll have to make that judgement call yourself - but if I were in your place, unless there is some really significant information you're not telling us in this post, I would revise your estimate of "I 'm at a startup in New York that has, in my opinion, an excellent product that is near launch" - you're at a startup that has a product that's probably 1-3 years away from being able to make significant amounts of money, unless you have a crazy awesome sales force that can sell ice to an eskimo.

In view of that, you should definitely take every step to plan for the likely failure of this start-up. If you've built a product that needs to be perfect from day one, you've built a product that's probably going to fail (and if that's an inherent requirement of the product category, then it's not a good product category for a start-up).

So, looking at your specific questions:

1) Assume it won't launch at all. What can you salvage? Well, actually, you do have a lot to show for it. If you worked at a large corp and built a product for them that they never launched, you wouldn't have "nothing to show for it". You must have learned a lot on the way. I know (from personal experience) it's hard to be positive when your startup is falling apart, but it's really a matter of perspective. Discuss this with a positive, can-do friend who'll help you bring out the positives if you ever need to interview.

2) See earlier comments. You can't recover from that damage - you need to launch and iterate. If you can't launch and iterate, you're dead in the water.

3) That's all a matter of how you sell yourself. I would suggest looking for other start-ups to join though. They definitely won't look down on your experience as "worthless". Some corporate departments might - but those are probably not the ones you want to work at anyway. Others are desperate to hire "entrepreneurial people". If you sell your experience right you should be able to make it worth your while.

4) That's not really related to the rest of the post. Forget about that for now and focus on the cataclysm unfolding around you. You'll need all your wits on the present moment.

PS: Feel free to come hang around in #startups on freenode for further discussion of this.

As for the 40k lines of his code and his component; write up tests, refactor it where need be and if the worse comes to the worse launch with buggy code and update after it's out there and you know if it's worth fixing!

You waited too long to handle the cofounder developer problem. Cut your losses now and get your second wind and attack the other startup ideas in your mind

Honestly, the current venture, minus the bad apple and the rickety code he has written, is still (in my estimation) better than any other ideas in my mind. We still have excellent people and a great idea.