
Ask HN: Would a .Net back-end put off potential acquisitors? - topbanana
I know the .Net tech stack very well, warts and all. I feel I could get to market quicker than if I were to build out using something JVM based or even node.js.<p>Would this put off potential suitors?  My gut instinct is that it probably would to an extent, but I&#x27;m not sure it&#x27;d outweigh my personal advantage of experience. If it makes any difference, I am funding this myself initially.<p>So in your opinion should I bite the bullet or go with what I know?
======
allegory
I've been in this situation a couple of times before.

It won't make a blind bit of difference initially but if you expand, so will
tooling and deployment costs and investors don't like that. Anything that
takes off the bottom line is a problem. Microsoft licensing, particularly dev
tools and SQL is _incredibly_ expensive and an order of magnitude more
expensive on deployment and diagnostic time than anything else.

We're like that now. Our SQL licensing is shaping our architecture not on
technical merit but avoiding core license costs. That is beyond bad but we
can't justify a £200k spend on licenses and kit to get rid of 2008R2.

Inevitably bits of Python are now appearing around the edges of the product
and trying to stab the core. There are a couple of postgresql machines doing
ancillary work. All the staff are slowly moving their operational task over
because there isn't a purchase process.

This is the price of success though :)

Edit: just to add that the last two companies I worked for are
Python/java/postgres houses now after being end to end MS outfits. The staff
change over the lifecycle of a product. You can afford better people after
time and better people seem to prefer to use other platforms even if they
market themselves as .Net people.

Edit 2: also once you're locked in, volume licensing looks cost efficient.
Then after a couple of yeara you get a call from the sales guys at MS who want
to do a 'soft audit' (which it says they can so in the VL agreement). Then
battle commences between MS, yourselves and the disty who handles your VL over
how much you owe. This usually starts at £150k-ish for an SME and your ops
team will be down for days whilst they work that down. Our liability was less
than £10k which is within the VL safe zone but other companies are less lucky.
Also the VL settlement says you can't discuss it but fuck them - the company
this was against is dissolved.

Actually I look at my post and I couldn't possibly recommend it. If we'd
started differently we could afford to be employ and sponsor postgres core
team staff for example and gave second to none support and a positive impact
on the community. Instead, pockets are lined elsewhere.

~~~
phaus
>Then after a couple of yeara you get a call from the sales guys at MS who
want to do a 'soft audit' (which it says they can so in the VL agreement).
Then battle commences between MS, yourselves and the disty who handles your VL
over how much you owe. This usually starts at £150k-ish for an SME and your
ops team will be down for days whilst they work that down.

How can this happen if you already have the software licensed? Shouldn't the
result be that you owe them $0?

~~~
yulaow
I think he means that the licensing of MS is so much fucked up and
confusionary ( It is basically the only thing I really hate of MS) that in the
end even trying to do your best to have a perfect coverage, you end up with
something wrong.

------
onion2k
Thinking about potential problems with an exit before you've even started
building something is frankly ridiculous. _Just start._ What anyone might buy
in a few years time if you're successful will be _very_ different to what you
build now because you will learn things about what the customer wants along
the way. Whether that's shifting to a more appropriate language is something
that only time will tell.

~~~
sinamdar
Completely agree. Remember, PG and team wrote Viaweb in Lisp because that is
what they were comfortable with. They got acruired by Yahoo because they had
the users and the best product in the market. The fact that it was built in
Lisp did not deter Yahoo at all.

Stackoverflow is built on .Net and nobody is questioning that now.

It could turn out to be an advantage that the others keep writing you off as
'destined to doom' because you are on the .Net platform.

------
srb24
If you have a great product that you can get live quickly and works then it
won't matter if you even write it in COBOL (don't write it in COBOL though) -
ASP.Net & SQl Server (even the free version) also work very well together and
have great performance.

There are of course licensing costs if you run on Windows and don't use MONO
but these shouldn't really be an issue in comparison to all your other costs

Also there are a lot of ASP.Net/C# developers around (just look at odesk)
which will help you build your team faster (unlike Ruby or Scala developers,
which are great languages, just harder to recruit and also attract higher
wages).

My advice... build a proof on concept as quickly as possible - if .net is your
thing then use that vs. wasting time learning something else. The chances are
that your concept may need to be reworked so why waste time...

Good luck!

~~~
allegory
I'd caution against the performance claims. Yes its very good and can take a
serious beating but there's a brick wall that requires a pile of tuning and
tool purchasing to get over.

Oh and the instrumentation and debugging past the bits of code you wrote and
the .Net runtime core libraries is utterly horrible.

See some of my earlier comments about this matter.

I'd rather build on the JVM now thanks to tools like VisualVM and profilers
that can be deployed across the team for free.

~~~
mattmanser
99% of startups simply will never hit the performance problems you seem to be
talking about.

~~~
JoeAltmaier
Yeah but its the ones that matter, that do? The successful ones with traction.

~~~
allegory
Indeed. We thought it was the same and nearly lost two big clients because we
didn't see it coming.

------
throwawayforob
We're a company with a .net stack that is being acquired right now.

It didn't come up until their senior engineer said we should rewrite
everything in Angular.js and Java. The tech management guys quickly said,
"Sure, maybe, but for the foreseeable future, we will SSO between the two
systems and plan for deeper integration later."

Hands on engineers care a lot about tech choices and sometimes have actual
good reasons. At the business level, nobody cares as long as you can meet the
business need.

~~~
sixothree
Speaking of SSO.. I work in .Net and we have sold our product to companies who
didn't have a single Windows server until the purchase. They SSO in and
couldn't be happier.

------
pm
As much as I don't like the .NET stack myself, you should go with what you
know, unless you're specifically looking to learn something new. There's
enough risk in starting up as it is without burdening yourself with learning
an entirely new stack.

------
joshuaellinger
Don't worry about suitors - worry about hiring people. Team matters much more
than Tech.

But, as perspective, MS Dev tools cost about $10K per dev + $3K per year per
dev after the first. Engineers costs $100K+ per year. +10% productivity covers
the tools. If it costs you a month to retool or saves you a little on salary
or lets you hire a little easier, you have paid for the tools. So what matters
are things where you get x3 productivity or x3 better ability to hire.

Also, I think you are asking the wrong question. The problem you are trying to
solve drives the platform decision and language (even DB) are only a small
part of the equation. Amazon works just fine with C#/.Net and it is cheap to
free at first. To get a fair comparison at scale, you need to include the
price of EC2 instances against a dedicated self-hosted database server.
Depending on your application, you'll get very different answers.

In your shoes (based on limited info), I would try to get into the BizSpark
Cloud program. It is free MS software plus a big credit on Azure for three
years. Then count on the price war between Amazon/Google/Azure to keep prices
in line.

~~~
JoeAltmaier
Still salary is paid out over time. Tools cost up-front. In a lean startup
that could sink you?

~~~
bnjs
>lean startup

You mean a bootstrapped startup?

[http://steveblank.com/2009/11/02/lean-startups-
aren%E2%80%99...](http://steveblank.com/2009/11/02/lean-startups-
aren%E2%80%99t-cheap-startups/)
[http://practicetrumpstheory.com/2010/03/bootstrapping-a-
lean...](http://practicetrumpstheory.com/2010/03/bootstrapping-a-lean-
startup/)

------
chx
Just as a data point: [http://meta.stackexchange.com/questions/10369/which-
tools-an...](http://meta.stackexchange.com/questions/10369/which-tools-and-
technologies-are-used-to-build-the-stack-exchange-network) Web Framework
ASP.NET MVC 5 with MiniProfiler

------
nkohari
I have experience with this. We started a company based on a product written
in C#, and were acquired by a company by a company whose product was
predominantly written in Java. It was never really a concern during the
acquisition.

The software world is so diverse now that you could never predict who would be
interested. If you ended up writing your product in a JVM language, you may
end up with a Ruby suitor, etc. It's always best to just use the tool that
you'll be most productive with, and will result in the best product.

------
opless
No investor cares about what language your product is written in. No client
does either.

Use what gets the job done, think a little about scalability and modularity
from the start. Don't optimise until you have plenty of data. Over thinking
things like this will prevent you from the initial release.

If it works, great. But like all projects, you might have to throw away
significant portions of your system away to grow. Being too tied to one
specific technology _will_ defeat you.

------
rbanffy
You should never forget your licensing costs if you ever need to scale to
"internet scale". However, it's more important to get a product out the door
than to have a hugely scalable thing. If .Net is the best tool for your team
to do it, then use it and work out the scalability issues later (you may
consider keeping an eye on migration costs - it's easier to add app servers
than to scale a RDBMS) and always having a plan on how do you turn what you
have into what you'll need. You may even be very successful and not need to
change too much: the Stack Exchange folks run a lot of their infrastructure on
Windows.

I make my PoCs with Python on Google's App Engine. It's zero management and
any individual idea is far more likely to fail than to be an overwhelming
success, so it's reasonable to think about costs if and when the idea gains
traction.

Another thing you should consider is how the stack you pick will affect your
ability to hire great talent in your region.

Note: I really hate .Net (and Windows) but these are not decision one makes
based on passion.

------
speg
I wouldn't think so. Your tech stack is going to be one of the last things
they care about. Besides, .Net is very well established so if anything they'll
take comfort in that.

It's all about the product and users.

------
plasma
Write your product in the language that you know best and is suitable (which
is .Net).

You don't want to be struggling to show hello world on a page with an unknown
framework compared to building your actual product with a language you know.

I've written many projects in PHP and .Net.

My latest startup is all .Net and the right choice.

------
dennybritz
I'd like to raise a related point. While I think it's too early to worry about
acquisitions, a .NET stack may put off early employees. Many engineers want to
work with "hot" technologies for professional development reasons.

For example, I would not work for a company whose stack is built on top of PHP
or .NET, regardless of pay. Not because these are "bad" technologies (in fact,
they are a lot more stable than the hot technologies, often resulting in
shorter time to market and cheaper labor), but simply because working with
these technologies doesn't benefit me as much personally/professionally as
working with some of the upcoming frameworks. I probably wouldn't enjoy my
work too much either. To quote rubiquity from another HN thread, "people that
work for other people aren't trying to build that business, they're trying to
build themselves within that business."

~~~
sheetjs
> a .NET stack may put off early employees.

Any choice may put off early employees. By sheer numbers, choosing .NET gives
you a much larger hiring pool than, say, Haskell or NodeJS.

~~~
dennybritz
Yes, but it's not about the size of the hiring pool. It's about the "quality"
of the hiring pool (HN likes to call them 10x engineers).

I don't have any hard numbers to back this up, but based on personal
experience almost exclusively all of the best engineers I have worked with
prefer to work with open source technologies and would not touch .NET. One can
think of several reasons for this correlation that make intuitive sense.

~~~
JoeAltmaier
Observer bias.

~~~
dennybritz
Perhaps that's true, but my sample does indeed include quite a number of
startups whose stack is built on .NET. Their engineers are usually much less
experienced (and are often lacking theoretical foundations. E.g. they know how
to use MS tools without knowing how stuff actually works) than those of
typical SV startups.

I'm sure there are good .NET engineers out there, but hiring/finding them is
more like finding a needle in the haystack.

------
programminggeek
I think it wouldn't hurt and if anything would allow you to find developers
easier than if you did it in Rails, Node.js, Scala, or Go.

There are a ton of developers doing .NET or Java EE for large companies
everywhere. Having that talent pool available is more convenient than having
to recruit in more obscure platforms.

------
doobiaus
My short answer is, go with what you know, it's better to have a solid working
product than a flakey pile of learner spaghetti.

I'm a .net dude at a startup though and to be fair long term costs should be
factored in, but can be mitigated. For one BizSpark is an absolute must to get
started, and once you graduate there are the Action Packed for a few hundred
dollars a year.

I would however suggest you look rather at using oss where possible even from
. Net. We have used MySQL, Mongodb and redis on Linux because it keeps scaling
costs down, and to be frank they' re better supported on the platform.

We also leverage BitBucket and TeamCity rather than TFS for cost reasons.

Having said that both Azure and AWS have fairly scalable windows and SQL
hosting services.

------
us0r
I don't think it matters. Just look at some of Microsoft's buys: Yammer
(Java), Skype (not sure but not .NET), Hotmail (FreeBSD), etc. Traction is the
key.

Sign up for Bizspark and you don't have to worry about licensing for 3? years.

~~~
toast0
Nitpick, but Hotmail was Solaris for the backend (which I think was the
hardest part to migrate)

------
goofygrin
We're .net devs, not looking to get acquired right now, but most of our stuff
is migrating to angular on top of web API (with breezejs) so our hiring has
been for the JavaScript side since we already have enough .net to deal with
the very thin c# layer that exists with that stack.

Personally get to market fast, fast, fast. Between dreaming and loss of
velocity meaning stalling... You just need to keep constantly moving forward.

------
lukasm
The is a possibility that some MS hater would refuse to buy on that basis or
made it an excuse to buy someone else. It's close to zero though.

------
sheetjs
> If it makes any difference, I am funding this myself initially.

The primary concern, if you are funding this and building this yourself, is
getting to market. Each day is coming out of your pocket. Choose the
technology stack that gets you off the ground fastest. A suitor is not going
to reject your company because you aren't using the "hot" technologies.

~~~
JoeAltmaier
But 'off the ground fastest' is an algebra problem - cashflow rates are what
matter, not time so much. So early expensive tools MIGHT be better,
considering your rent and grocery bills over time.

------
bdcravens
Invision is written in ColdFusion, a language far less accepted than the .NET
stack, yet they just closed a $20M+ series B.

Rob Walling's HitTail product was for the longest time an classic ASP app, he
purchased, revised, and iterated on the product without switching the stack.
Only recently did he rewrite the app in Rails, when it made sense to do so.

------
hpagey
Try to find product/ market fit as quickly as possible. My personal rule of
thumb is to find 10 paying customers before you can declare product/market
fit.

The stack really doesn't matter and should be least of your concerns at this
stage. I used to work for company whose stack was .NET. They got acquired a
year back for 1.6 B dollars.

------
bhouston
Ship the product and get traction. The back end doesn't matter unless it hurts
you achieving these two goals. Maybe other backends will help you achieve your
intended results? That is the only real question that matters. Traction is
hard to achieve and is paramount.

------
danabramov
Is Mono viable for server these days?

~~~
pionar
Mono is, yes. If you use a non-Microsoft stack to host an ASP.NET site (OWIN,
Nancy on OWIN), then even more so.

Nancy+OWIN+Mono+nginx is a very good stack.

~~~
pit
I agree, Nancy is a lot of fun to use with Mono. However, I've been stuck
trying to get a WCF (older ASP.NET) application running on Mono for a while
now, and it's been a huge pain.

~~~
PallarelCoedr
Forget about older ASP.NET and WCF on mono. The core of ASP.NET (System.Web
assembly) doesn't feature in next version of ASP.NET. WCF hasn't seen any
effective development in years.

The new stuff (ASP.NET vnext) will be highly mono compatible and like the
current OWIN stuff, entirely decoupled from IIS.

~~~
pit
Thank you, that's extremely encouraging. I think we can effectively migrate
the web service to Nancy while keeping our C# business logic as is.

Should be a fun week!

------
ridruejo
A startup is mostly about managing risk. Assuming that your product is SaaS
(i.e. your customers don't know or care what is written on), then in general
the risk that your product will not be successful is probably bigger than that
it is successful and you have problems with an acquisition. I would worry more
initially about what you can be the most productive on and also whether you
have access to talent for that particular stack (to grow the team if it starts
to take off)

If you are truly successful at some point you will need to rewrite and you can
change to a different stack then if it makes sense (it will be painful, but
hopefully by then it means you will have the resources to do so)

------
fauigerzigerk
It's all about growth.

I don't think a potential suitor would be put off by your choice of
technology, but if your choice of technology slows your growth, then that will
definitely put off a potential acquirer.

You don't want to put yourself in a position where you have to buy another SQL
Server license instead of hiring a developer, or use the developers you have
to invent contrived architectures in order to reduce licensing costs.

If there is any chance you might run into that kind of problem before getting
acquired, I would rather bite the bullet now and get started on a platform
that doesn't artificially limit my architectural choices.

------
chaostheory
They won't care about your tech stack if you have the users. If a large
company like Google acquires you they'll just eventually recreate the entire
site in their preferred language and preferred frameworks anyways.

------
sourc3
Build with what you know while understanding the operating costs.

I am currently working on a start-up where we started with .NET running on
Azure and SQL server with Android and iOS clients.

After going through some realistic usage patterns and the cost of licensing,
we ended up deciding to switch over to MongoDB/Python and Linux VMs.

It was painful to do the switch and the time we lost was not insignificant.
However, in our case the time lost was a fraction of the future operating
costs so we bit the bullet.

The stack you know is the best stack to use. After that, the stack that costs
you the least is the best one to use :)

Good luck.

------
jenandre
I would be more worried about the costs of licensing as a startup. What kind
of sprawl will your architecture have? Do you have to pay for SQL server?
Acquisition is sooo far ahead of where you are.

------
frou_dh
Most likely this is major overthinking and your energy is better spent back
here in the present day on first-order concerns like making people receptive
to the actual product!

------
ruebenramirez
Minimum viable prototypes should be built as quickly as possible to test your
idea. If the market doesn't like the idea it doesn't matter what you built it
in.

------
tlogan
If you are technical founder then go with what you know. No questions here.
Regarding licensing, you will anyway then run on Azure so licensing costs
might not be so terrible.

If you not a technical founder and your goal is being acquired than technology
does matter. For example, if you are in the market where, Oracle or Salesforce
are potential acquirers then do not use .Net. Be more SQL / Java oriented.

And if your end-goal is getting revenue and profit, then it does not matter.

~~~
tankenmate
Yes, it probably won't affect your revenue. Your profit however is likely to
be affected; how much depends on your architecture and scale.

------
dannyr
Facebook was initially built on PHP.

If you have users, lots of it, it trumps everything.

I have friends who hated PHP ended up joining Facebook.

Get to market ASAP.

Getting acquired is the least of your worries.

------
DanielBMarkham
No, but a discussion around the tech you're using might.

It's about making something people want -- even if you have to do it using
clipboards, rubber bands, and duct tape. If they want it, you can figure out
the tech later. That's the easy part. The hard part is connecting with people
you can help.

------
fidotron
It depends on your product/service. If your business model is dependent on
rapidly scaling using a cloud based backend then .net isn't the way to go. If
your revenue per customer is much higher, and there are fewer actual customers
then it can work.

For that reason .net doesn't seem to fly much in the B2C area, but is quite
common for B2B stuff.

------
silverbax88
It doesn't matter at all. In general investors have no clue about coding.

~~~
tlogan
They do hire "deal breakers" (experienced programmers which work in a basement
of a VC firm whose only job to convince VC not to invest :-)). At least they
had them in early 2000s. Not sure if that is case now.

~~~
silverbax88
I've been one of those guys on contract, but only for really big deals, not
really the ones I've seen on HN. The last one I worked on was a deal which was
funded by Morgan Stanley and a few others - they put in about $800 million, I
believe.

They bought the platform (mostly written in Oracle) and we recommended they
re-write their external APIs (which were written in Java). They did both, re-
wrote the APIs in .NET, which is what we recommended (because they had no Java
programmers but they had 6 really solid .NET guys already on staff...honestly,
companies have no idea of what assets they have in house). Company went public
last year. Just hit $1B in revenue just before going public.

If we had walked in and seen a bunch of No SQL or some fad junk, we would have
told them to bail. You can't play around when you are playing with these level
of businesses.

------
nbevans
.NET is an advantage not a disadvantage. HN can be utterly bizarre sometimes.

------
kross
Start with the end in mind.

------
_random_
> So in your opinion should I bite the bullet or go with what I know?

Yes.

------
personZ
Quite a few of the replies are practical, but unfortunately reality isn't
always practical. Instead we often use technology for signaling, and the truth
remains that the Microsoft stack (even if you talk up open source equivalents
like mono) is an anti-quality signal. This is not judgmental (I have used and
abused the MS stack for years), but is observational. And that tendency is
often based upon experience -- the bulk of .NET programmers are enterprise
inhouse developers usually building dated, poor quality solutions.

This hits hiring as well. Someone mentioned the quantity of .NET programmers,
and while this is true the quality is extremely, extremely poor on average.
Having had to hire .NET programmers, the best success we have had, result
wise, is to hire !.NET programmers (e.g. the hiring process started being
about abstract problems that could be solved with anything, etc) and let them
loose with C#/etc. If we limited ourselves to the .NET skillset we got tonnes
of applications, almost all of which were terrible.

~~~
JoeAltmaier
I'd suggest that since the .NET hiring pool is vast, then you see lots of
programmers of every quality? It could be sampling bias.

