

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!<p>Help me decide!<p>SCENARIO<p>You are doing a startup. You have launched, you have customers, revenue and some traction. You are growing steadily.<p>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.<p>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.<p>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.<p>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.<p>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:<p>CHOICE 1<p>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.<p>Key advantage = Full 12 months of runway to reach cash flow positive<p>Key disadvantage = 40% of dev is bottle necked through a single developer<p>CHOICE 2<p>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.<p>Key advantage = Once you have rewritten the core tech, everyone on the team can be fully productive on the platform<p>Key disadvantage = Rewriting the core tech probably reduces your runway window by 2 months, giving you 10 months to succeed rather than 12.<p>THE QUESTION<p>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
I specifically avoided mentioning the languages so as not to cloud peoples
judgement of the issue... :-)

Yep I get your point, that optimal efficiency is the preferred path. Good
insight thanks.

~~~
alexro
So, maintaining that technology boosts your runway, but also puts you in
danger of loosing everything if the developer quits. Assuming from your
(positive) feedback to that idea you think it shouldn't happen in the 12
months timeframe.

------
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.

