Ask HN: Looking for feedback on a startup strategy question

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

Excellent point. Thanks for the feedback.

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

They could learn....that is true.

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.

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

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.

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.

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"

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

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.

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.