In practice, what everyone cares about most (both acquirers and investors) is who has the most users. If you're growing fast, they want you, period. And if not, not, period. So while investors and acquirers may grumble slightly about peripheral stuff like what language you chose, or where you're physically located, or the structure of your company, it's the sort of grumbling people do as they reach for their wallet to pay for something.

As a counterpoint, I was told that Yahoo, when they went to pick a fantasy sports site to acquire, decided that since they were Yahoo whichever one they chose would instantly have the most users, so they didn't care about user base. In fact, they chose the one that had the most compatible tech so that they could integrate quickly, and the fact that it had few users at the time just meant they got to purchase it for far less. CBS shelled out a bunch later for commissioner.com (the market leader before Yahoo bought their way in, and which Yahoo had passed on) and now is a distant third.

That clearly wouldn't apply to something like YouTube, but I wouldn't be surprised if even Google's logic is sometimes similar when acquiring small companies. Look for the product that's easiest to integrate and use their marketing muscle to push it to number one.

That's an interesting position you bring up, but I'm not sure how well it would work for most types of acquisitions. For example, there are tons of sites that are far, far better than YouTube, but it grew fast due to its popularity on the outset.

If Google acquired something better, like Vimeo (even long before youtube became so popular), I doubt even their marketing muscle would have been able to push it to the market leader.

The reason most large companies acquire smaller ones is because of two things: the userbase, or the talent that developed the app. As far as your example with fantasy sports-- there must have been something else of value in the acquisition.

The app itself is easy to create. No one buys code.

Sometimes companies acquire others because they want to be in the market and it's easier to get a higher-up to sign off on an acquisition than it is to just build it themselves. In that case, they just want to minimize the headache of integration.

I'm not saying you should base your site's design on that, as you probably shouldn't even be thinking about an acquisition from the outset. I'm just saying it happens.

Certainly that's right, in the archetypal beating-the-odds startup situation. If you're a YC company, stop reading.

But isn't it different for acquisitions done to integrate with an existing platform or are T&T (talent and technology) exits? Call them the "let's see if this works" offer. Yeah, I know, not the investor's desired scenario, but not so bad for founders, especially bootstrappers.

There seem to be a lot more of those deals out there which would be attractive for young entrepreneurs. And frankly, it might make sense based on that to try to use popular technology in clever ways.

Honestly, it's not that exciting to discuss. But if you don't have explosive growth, well, it's something you think about.

We wrote our product in Smalltalk, and our company was bought a few weeks ago. In the eyes of our acquirer, the speed with which we could implement features far outweighed any disadvantages (and was one of the main reasons they were interested in us). The "problem" that Smalltalk has a small user community never really arose.

It's worth noting that the buyer, Live Current Media, is based in Vancouver, BC. Anecdotally, that area seems to have a large number of Smalltalkers.

Just curious, what made you switch from Lisp to Smalltalk? Assuming you put quite a lot of work into Croma.

Care to tell what did you build in ST?

It was Auctomatic. Thats Patrick from Auctomatic. The only person i know who would dare to use an obscure framework and be a major contributor to that movement.

On three seperate occasions, startups I've had key roles in lost or complicated deals because of technology decisions, including:

* Relying on a nonstandard runtime environment to run an xp codebase on Unix and Windows.

* Using Tcl anywhere in our product.

* Shipping an appliance on BSD Unix instead of Linux.

My markets tend to be different from YC markets. For a web app, your stack may not make much of a difference. Or it might. I don't have data points on people not caring that you're using Araneida to deliver a web app; in every bizdev situation I've been in, the technology stack has been a topic of discussion.

Write in whatever gets you the largest amount of marketshare the fastest. If you're making big $$$ or pulling in redonculous amounts of eyeballs the acquirer won't care if you wrote it in assembly or cobol. More importantly, don't worry about acquisition - concentrate on a business model that makes $$'s. Acquisition is for the lucky few and she's a very fickle suitor.

I think making something that is valuable is most important. Viaweb is one example. Microsoft buying Hotmail is another.

At Scriptics we did everything in Tcl and still got bought.

I heard Interwoven bought Scriptics mainly so they could totally screw over their competitor Vignette, whose whole system was totally dependent on Tcl at the time. Kind of like the way Oracle bought InnoDB to screw MySQL.

Did Interwoven actually end up doing anything with Scriptics/Tcl?

I would guess that it'd matter if the language poses a problem for when your acquirer tries to integrate you. Of course, this can be greatly outweighed by the value added of your product.

My whole point with Hotmail is that it was so valuable that Microsoft bought it despite the fact that the entire infrastructure was Unix.

Technology can be ported. User base doesn't care about the underlying technology, if they get value from using your service.

Good read from 2000-era

"This white paper discusses the approach used to convert the Hotmail web server farm from UNIX to Windows 2000"

"Hotmail has grown from 9 million accounts when it was acquired by Microsoft, to 100 million in July 2000, without significant changes in the hardware or software architecture"

"The most challenging, and anticipated, problem with converting from CGI to ISAPI derives from the forgiving nature of the CGI..."

[PDF] http://tonnerre.users.bsdprojects.net/doc/facts/microsoft/Ho...

you're talking about a huge acquisition here... if you want to sell the company for 5-15 million, language will matter a lot more.

What makes you think so? I'm not saying you're wrong, I just don't see why this would be an obvious conclusion.

at 5-15 and even more so at the 1-5 range (where we've seen a decent amount of activity lately), user base isn't the defining factor in the acquisition. in the not-very-well-named "hiring bonus" style exits (who receives a hiring bonus of $1.5M anyway??) certain acquirers will be paying attention to the language you're written in. others might not.

OK, I guess if we keep going lower and lower, I can see at some point the language/infrastructure transition costs become a significant portion of the acquisition.

It'd depend on the product, I think. A half million line codebase would cost millions to translate, while 40k lines would cost a max of tens of thousands (assuming languages of similar capabilities--like Ruby-Python-Perl). But, a half million lines of code isn't going to go for $1.5M except in a fire sale.

But, I reckon this has some bearing on folks building on Google App Engine. That's a bigger form of lock-in than most, and since the apps being built there will be quite small for the foreseeable future, it makes the barrier to exit much higher for folks who might have been willing to sell for $1.5M but could only get an offer of 1M from GOOG or 800k from somebody else (because they would then have to port the application, even if they don't mind it being in Python).

So, I obviously buy your reasoning once you get down into the single digit millions (or sub-million) acquisition prices, and I also buy your reasoning that those kinds of acquisitions are becoming a lot more common.

Users, users, users. (or even better: Customers, customers, customers)

Whatever language gets you the best product (and hence the most users) is the best language.

"Once you've got a lead in terms of a subscriber base, that is unassailable ... it would've been easy to pick 15 [Microsoft] guys from 16,000 and build this product. But I knew we had that momentum behind us and that is very hard to replicate."

-- Sabeer Bhatia (hotmail), in Founders at Work

Since it is much more expensive and difficult to create traction on a product and to win customers than to port an existing product on another platform or technology, it should not be a show stopper for a large aquirer. Things may be different, when a small company considers to acquire a project in early stage.

a bit of inside knowledge here of multiple recent acquisitions and acquisition talks: being in an acquirer's preferred language definitely helps. as everybody mentioned, there are dozens of factors that can be more important -- you can't argue with 100 million users. but given situation (a) where you're written in PHP and situation (b) where you're written with GWT or in python, all other things held equal, Google will value your startup much more highly with their preferred languages.

Yahoo Stores rewritten from Lisp to C++ and Perl http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=s...

So if you made it to sell it, you might wonna avoid really unpopular languages.

Ruby compared to PHP have a lot smaller user community, but nowadays, one would never call Ruby unpopular.

So there is a different between unpopular lisp and unpopular Ruby

Lisp is not just unpopular, it's also really different from anything else, so harder to get in to.

Yahoo Store was rewritten in C++ by the programmers at Yahoo who inherited it after we left, years after the acquisition.

Neat. How did you do it? I have a pet project in mind and I want to use LISP.

Just getting here?

I think of this differently. Assume that there's a situation where your language has to change, whether because of acquisition or scaling or hosting or lack of developers or licensing or whatever.

How do you switch? And, more importantly, can you do it in a granular manner?

From Spolsky:

"First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code."

Think about your system as a series of pieces and keep the as (appropriately) decoupled as you can. Then, when you find a technical/business/legal bottleneck that is tied to a language issue, you can swap out that piece and keep moving.

I love being able to confidently say:

"Well, our integration point is always through the db, so if the mixer needs to be faster or rewritten in C++ we can do that. If retrieval needs to be pulled out onto another machine, we can do that. If you need it rewritten in Python, here are the five big pieces, and each one can be moved over independently."

I can see where the language and platform could have an affect on an acquisition. Both for ease of integration, and scalability. If you have a small app written in .NET, and an acquisition would suddenly increase your userbase by an order of magnitude or two, this could be a cause for worry to the acquirer.

Also, as more and more web-based platforms are going to cloud computing architectures, ability to slide into a LAMP environment would reduce cost and make integration much easier (MHO only).

I'm sure that much of this depends on the size of the company doing the acquisition. Google or Amazon probably have more overall resources and ability to deal with oddball platforms than a much smaller company, ex: if LinkedIn were to buy another social networking site based on .NET.

Bottom line, everything matters. Language, office location, user base, founders, team, etc. However different things matter differently in each situation, so it's difficult to structure yourself for easy acquisition once you get much beyond the "3 founders in the basement" stage. So, work on building a strong company that can stand and scale on its own. Make smart decisions to the extent you can, and hope for the best.

Of course it does. All other things being equal, you're more likely to be bought (and at a higher price). Of course, if you're much better with Lisp than other languages, you'll likely make something much better with Lisp so all other things won't be equal.

While I don't think language is a big thing to overcome, do realize that you will have to be just that little bit better if you've chosen an unpopular language.

I think that decision is much broader than that. Companies are concerned not only about the product itself, but the market share and the image. They'll rewrite your product from scratch if they have to (and they will eventually sooner or later anyway) in order to get your market share and image.

If you dream or desire of being acquired by Google, strongly consider Python

"Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language" said Peter Norvig, director of search quality at Google, Inc

"Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers" said Cuong Do, Software Architect, YouTube

http://www.python.org/about/quotes/

It looks to me like Google has bought web apps from every stack. FeedBurner was a J2EE app!

If you have a zillion users or a key feature Google wants, I have a hard time believing Python is going to be a major issue.

Java is probably the heaviest-used language at Google for consumer-facing web apps.

More surprising (if this sort of thing surprises you) is Writely, which was in C#/.NET.

In any business discussion, it is critical to separate issues from details at the outset. In most cases, revenue, market presence, customer service, profitability, and financial status are issues. In most cases, your language is a detail. The problem is that many business people don't know the difference between an issue and a detail (in this discussion and many others).

In my experience, those who were concerned with what language something was written in were also concerned about a lot of other details instead of the real issues. Exercise caution with such people.

Uh...I'd wager Sun has more staked on Java than MS does on any of the languages it supports.

Sun has been the most ardent corporate supporters of Rails. They were even before JRuby.

Plus, Sun isn't really a big dog in the acquisition game.

It takes a pretty big dog to buy MySQL.

I should have said:

"Sun isn't really a big dog in the startup acquisition game."

MySQL wasn't a startup.

Sun makes plenty of acquisitions (mostly startups):

http://en.wikipedia.org/wiki/Sun_Microsystems#Acquisitions

In the past 5 years they've mostly been one of:

1) Hardware

2) Giant

3) Enterprisey

None of which are very applicable to the original question, which is about web software startups.

"None of which are very applicable to the original question, which is about web software startups."

You must have read a different question than I did. The original post mentions "startups", not "web software startups". Many News.YC readers are building things that Sun would find interesting, so I think Sun's acquisition history is relevant to our interests here at News.YC.

They've been doing a lot of non-hardware, non-enterprisey stuff in the past 5 years too. Primarily Solaris 10/OpenSolaris and DTrace among (many) other things.

DTrace continues to blow my mind.