Ask HN: Looking for feedback on a startup strategy question

[shandsaker]

This is an actual problem we have to decide on with our startup. It is not a hypothetical!

Help me decide!

SCENARIO

You are doing a startup. You have launched, you have customers, revenue and some traction. You are growing steadily.

You have just taken a seed round, which gives you enough runway for exactly 12 months. At the end of that 12 months, you need to be cash flow positive or you may as well pack up your bags and go home.

You have 4 staff, 3 of whom are developers and 1 of whom is the sales and marketing person. You have a board with 1 investor and 2 founders on it.

Your product is an early iteration, which means it meets the needs of some of your target market but not all. It needs continuous development in order to reach "product to market fit", and reaching that fit is an important aspect of becoming cash flow positive.

Your product is built in a particular technology which means that 40% of the development work can only be done by 1 of the developers (development bottleneck). This affects your speed of development. The other 60% of development can be done by all 3 developers.

Now, assuming that the sales and marketing techniques and the focus on the conversion funnel remains exactly the same no matter what you do with your technology, you have two broad choices:

CHOICE 1

Stick with your existing technology platform, and focus on reaching product to market fit. Accept that you will have a dev bottleneck, but do so knowing that it is preferable to have the full 12 months of runway at your disposal in order to maximise success.

Key advantage = Full 12 months of runway to reach cash flow positive

Key disadvantage = 40% of dev is bottle necked through a single developer

CHOICE 2

Spend the first 60 days of your runway rewriting your platform in a way that 3 developers can work on 95% of it, rather than only 60% of it. Spend the next 8 months focusing on reaching product to market fit on your new platform.

Key advantage = Once you have rewritten the core tech, everyone on the team can be fully productive on the platform

Key disadvantage = Rewriting the core tech probably reduces your runway window by 2 months, giving you 10 months to succeed rather than 12.

THE QUESTION

What would you do - choice 1 or choice 2, and why?

[microcentury]

I am a business person rather than a programmer, but I can tell you from my end that I have never seen a rewrite take only as long was as planned. If that two months becomes four months, you have 'lost' one-third of your runway. And there's not going to be much point having a product everyone can work on when there is no money to pay anyone.

[shandsaker]

Yes that is one of the risks of doing the rewrite...if we don't make it in time, it puts us wayyyyy behind the 8 ball.

[ZeroMinx]

Would it be viable to get the other another dev trained in this other language? As has been stated before, having a single point of failure is not good.

Also - are there other reasons why you'd want to rewrite that code?

If it's well written in a language you're comfortable with supporting, I guess you can take on another expert dev in that language as you're growing.

[shandsaker]

Yes that would be possible - sorry didn't mean to leave that out of option 1. To be honest in the time available it would improve our bottle neck, but not get rid of it.

Option 2 would certainly produce the fastest development setup.

I have realised that in trying not to cloud the decision by telling everyone what the tech was, I may have done you all a disservice by not giving enough information!

So here it is: The existing tech is Adobe Flex. Provides great RIA, but not good for iPhone/iPad. It makes up only the front end of the app, with everything else php based.

The new tech would be to re-write the front end in HTML/JS, leaving the backend php as is.

So another reason for rewriting the code is that we will likely want to dump flex at some point.

[ezrider4428]

In this situation the details are actually important. What 2 technologies are being used? Can you cross-train? can you hire more dev's on tech A? Which platform is more sustainable, scalable? What is the pool of talent in your regional area? Are you in the enterprise market or consumer market? Are you integrating with your clients via some kind of API or is it a SaaS model?

All these questions impact your decision. It seems like you are only thinking about the technology but if you are a technology company then choice of platform has wider impacts.

[shandsaker]

Yes I agree the details are important, but initially avoiding mentioning the tech means I hopefully got some less biased answers. I found that valuable.

The backend of the app is PHP, and it already has an API. The front end is Adobe Flex. The rewrite would involve dumping Flex for a HTML/JS approach.

We initially went with flex because our app is quite rich in interactivity, but we could do the same thing in JS now.

It's not an enterprise play, but it is B2B. We could cross-train, but hiring more tech's for Flex would be expensive and hard to do (not a lot around). It is a SAAS model, so my customers don't care at all what tech I use (unless they are a tech firm, at which point they screw up their nose at Flex). But they don't mater, as they are not our target market.

Essentially, changing to JS would double our speed of dev in the last 8 months of the runway. But, it may take longer to do than we expect and we may cut off too much runway to make it worth our while.

It may be better to stick with Flex to the point of cash flow positive....then rewrite.

[znt]

In of the videos of Google I/O, developers were talking about the "bus factor". It basically means if one of your developers were to get run over by a bus, how would the development process of your product be affected? That's why they encouraged documenting the work done etc.

Same principal applies to your current situation too I guess. If that 1 critical developer is run over by a bus / decides to quit / has a health problem / has a baby etc things may stagnate more than you can imagine.

A key advantage of a startup is to be flexible and lean, which means you'll be able to adopt and discard things faster than the "big boys".

So basically rewriting the core to let everyone (especially newcomer employees) get productive on it easily would be a better idea.

[DamonOehlman]

I'm not sure that it's entirely that simple. I don't want to get into any language wars but certainly in some cases the one single developer coding in a language they are extremely proficient in may in fact help use the "runway" most effectively.

The cost of collaboration is not equal to 0, and if it was my money I'd be looking for optimal efficiency over broad accessibility.

My vote would be for option 1, as you have already indicated that this affects only 40% of your product. If you do experience continued steady growth and become cash positive then pull in extra resources to support the 40%.

Given of course, whatever the 40% is written in is considered to be a good language. I won't define good, it means different things to so many people...

[shandsaker]

Excellent point. Thanks for the feedback.

[peteypao]

CHOICE 1: Achieving product/market fit is more important than any technical decision.

As a side note, why can't the developers learn the other technology?!? Only bad developers can't learn...

[shandsaker]

They could learn....that is true.

[maxhenderson]

I think in this particular case, the devil is in the details. But, if we address your question in it's current black/white form...

Start by figuring out how long it's going to take to go cash flow positive. Double that time. If that doesn't leave time to do the rewrite, skip it. Instead, temp or hire a new guy who can back up your bottle-necked development.

[shandsaker]

Yep the time it might take to do the rewrite is the biggest red flag for choosing that path.

[minalecs]

Why not have the 40% dev continue on old site, and maintenance. While have the rest work on the new site, but at the same time allocating resources as needed. I can almost guarantee that the redo will take longer than what you are planning. Take your estimate and double it.

[shandsaker]

In attempting the rewrite, the developer who covers the 40% of the existing tech would be a critical component of the new build....so probably not viable to do both.

[DJN]

Get the one esoteric developer to develop a layer of indirection (or API) for the other two developers to work with.

That way, you may be able to utilise all your developers fully.

As the saying goes "all problems in tech can be solved by an extra layer of indirection"

[shandsaker]

We already have an API...it is the front end of the app we are looking at swapping out (swap Flex for JS).

[sebg]

Is there a reason one of the three developers couldn't pick up the 40% platform/language? I am not sure the situation needs to be so black and white.

[oziumjinx]

Achieve product/market fit and start fundraising for your next round early to extend the runway.

If you have customers paying for the product/service, why pack up your bags and go home? Once you achieve pm/fit you should be focused on scalable repeatable sales/marketing channels.