Ask HN: Should one avoid using niche technologies for a startup? | Hacker News Reader

Ask HN: Should one avoid using niche technologies for a startup?

13 pointszaph0d10 comments

I am doing a startup with a small tech. team. We would like to use cutting-edge technologies like Clojure, Erlang, node.js, etc. which are not really mainstream but help in rapid application development and iteration. The problem here is that in case of a potential acquisition by another company, the deal might get canceled because the technology we used is non-mainstream, and the acquiring company might face a lot of problems in maintaining the code-base. So the question here is how do you deal with such issues? Should one compromise speed of development now in favour of an easy acquisition path tomorrow? How do you convince the `elders' in your startup about this?

View on HN

This site would not exist and none of us would be here had pg not been successful with Viaweb, which utilized Lisp. I think that PG and company were probably bright enough that things would have worked out with other technologies too, but Lisp made them happy and more productive, I guess.

"Did it alarm some potential acquirers that we used Lisp? Some, slightly, but if we hadn't used Lisp, we wouldn't have been able to write the software that made them want to buy us. What seemed like an anomaly to them was in fact cause and effect."

-- http://www.paulgraham.com/icad.html

I agree, but not everyone can sell a company to Yahoo! They probably didn't care about re-writing the app in PHP. They did it for del.icio.us too. What about selling to companies which that not so technically competent but would still like to buy your product? It's so much easier to hire Java/PHP/Ruby/Python people compared to Clojure,Erlang,Haskell people.

I can't tell you how many startups I've run across who are deperately looking for programmers who know [insert cutting edge/obscure technology here].

Because they can't find anyone they like, they are stuck making bad/deperate hires or with the prospect of rebuilding the codebase. The list of technologies that are tough to hire for vary by market. In my midwest market, Rails still falls in that group and I know a ton of companies that can't find the talent they need. Do your best to stick with the technology stack that has the largest candidate pool in your market.

True, but that means we will have to stick to Java even though we are Lisp, Python, Erlang guys here. That also means that we will have to muck around with JavaEE crap even though we can build the same thing much faster using something else; all this to be future proof.

I don't have any experience to back it up, but I'd say go for the technologies you want to use: Good programmers can learn a new language pretty quickly, whereas knowing whatever is language du jour doesn't make you a good programmer. Hiring someone just because they know a framework doesn't really strike me as a sensible hiring strategy.

There might not be as many Clojure programmers as Java Programmers, but there's probably a higher proportion of good programmers working in Clojure than Java. Hire whoever you can find who is technically able, passionate about tech and your idea, and I'd wager they will pick it up pretty damn quick.

It's relatively easy to find Python guys; It's harder, but still possible to find someone with Erlang or Lisp experience. It will be a couple more years since I would consider Clojure and friends.

I would say that though it's easier to find a Java programmer than a Python programmer, it's easier to find a _competent_ Python programmer than a competent Java programmer.

Java is NOT the only option.

I don't think acquisition will be as much of an issue as recruiting employees will.

If you think you can find people to work for your company who either know those languages or can learn them quickly enough to not kill your productivity or your product, then go for it. Otherwise, you may want to think about making some tradeoffs (i.e. node.js over Erlang because you're going to be far more likely to find competent js devs than Erlang devs.)

Most acquisitions end up with the founding team contracted to transition for a year or three; during that time the acquiring company either rewrites the IP or ends up with enough qualified people to take it over.

The best path forward is the one that lets you iterate easily and bring a product to market as quickly as possible. Until you have validated your MVP with customers you are burning cash with the risk of zero return.

When and if (and it's a BIG if) companies are expressing interest in acquiring your technology, you can sort out whether you'll need to rewrite portions as part of a deal. But far more likely is that the product will pivot at least to some degree, and you'll be thankful that you're using technology that you can comfortably and quickly modify.

It's probably wise to use a more common framework. Even if you are more productive initially being able to hire people when you're off focusing on some other aspect of the business is important too.

I'm not sure there is a huge productivity difference between the modern frameworks unless you really know nothing about what you're getting into. I'd choose something mainstream that you all know at least a little and can use and then get to work.

Reply on news.ycombinator.com