Ask HN: Would a .Net back-end put off potential acquisitors?
102 comments
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.
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.
I think you've tied your entire response to SQL Server rather than the .NET stack so I'll do the same from an ASP.NET aspect..
ASP.NET is moving at an incredible pace, the new vNext bits are planned to be officially cross-platform and you can support any number of database backends from a .NET codebase.
I also challenge your assertion that better people seem to use other platforms. You can find people marketing themselves as one thing but preferring another in any stack. This is not indicative of anything more than someone needing a job and meeting the requirements of a posting.
Licensing costs can vary. Between BizSpark, DreamSpark and other programs you can get dev tools out of the way quickly. They also provide Windows licensing for the period you're in the program.
The areas where you can get in real trouble as a startup with Microsoft are the add-on product stacks like SQL Server and BizTalk (shudder). I would avoid these in a new product but do not fear building with the .NET platform.
ASP.NET is moving at an incredible pace, the new vNext bits are planned to be officially cross-platform and you can support any number of database backends from a .NET codebase.
I also challenge your assertion that better people seem to use other platforms. You can find people marketing themselves as one thing but preferring another in any stack. This is not indicative of anything more than someone needing a job and meeting the requirements of a posting.
Licensing costs can vary. Between BizSpark, DreamSpark and other programs you can get dev tools out of the way quickly. They also provide Windows licensing for the period you're in the program.
The areas where you can get in real trouble as a startup with Microsoft are the add-on product stacks like SQL Server and BizTalk (shudder). I would avoid these in a new product but do not fear building with the .NET platform.
SQL server is pretty much inevitable otherwise you have to deploy on Linux (don't get me started on pgsql/mysql on windows). Then you have two disparate skill sets to maintain at great cost. Startups need to stick to heterogeneous platforms to keep costs low.
Asp.net v.next is currently a bag of promises. I wouldn't put a product near it for a long time. I back this assertion up with the promises of Velocity, EF4, SilverLight and WF4, all of which were disasterous piles of immature crud that disappeared after a bit leading to massive rewrites. Even MVC has a patchy history and numerous problems in it now (crazy API churn, attribute lifecycle/scope, memory ceiling, routing performance etc are all ones that I've spent days on...). Generally the entire web and enterprise teams have knocked out low quality rubbish for years.
People who advertise themselves as .net developers (as I do) know how to get paid a lot, not necessarily deliver the best solution for the money. There are those of us however who have fingers in many pots who know how greener the grass is and how organisations would benefit from a change and are taken on to fix the tech stack.
Agree with your assertion about BizTalk but mno further.
Asp.net v.next is currently a bag of promises. I wouldn't put a product near it for a long time. I back this assertion up with the promises of Velocity, EF4, SilverLight and WF4, all of which were disasterous piles of immature crud that disappeared after a bit leading to massive rewrites. Even MVC has a patchy history and numerous problems in it now (crazy API churn, attribute lifecycle/scope, memory ceiling, routing performance etc are all ones that I've spent days on...). Generally the entire web and enterprise teams have knocked out low quality rubbish for years.
People who advertise themselves as .net developers (as I do) know how to get paid a lot, not necessarily deliver the best solution for the money. There are those of us however who have fingers in many pots who know how greener the grass is and how organisations would benefit from a change and are taken on to fix the tech stack.
Agree with your assertion about BizTalk but mno further.
Why is deploying psql on linux a problem when running an ASP.Net service? Are you avoiding to manage different operating systems?
It isn't and we do that but its not desirable for a startup to do that. Someone with tangible expertise on both platforms is hard to find and expensive (me :-)
>crazy API churn
Can you go into this a bit? I just upgraded a MVC2 site to MVC5 and didn't have to change much.
I know the DI bits changed from MVC2-3 but all the existing extensibility methods worked.
Can you go into this a bit? I just upgraded a MVC2 site to MVC5 and didn't have to change much.
I know the DI bits changed from MVC2-3 but all the existing extensibility methods worked.
Care to comment on your .Net/pgsql experience?
I just finished a project with ASP.NET MVC over PostgreSQL via NHibernate. Worked great. Just out of curiosity, I actually even set it up so I could change it over to SQL Server with a config change. While it was a small and relatively uncomplicated data model (20 tables or so), it encouraged me to consider doing this combo more often. This project is hosted on AWS with AWS RDS for pgsql. Made it easy to use the basic Windows servers on AWS and not have to manage the data servers for pgsql.
Thanks for replying, been meaning to use ServiceStack/pgsql on a side project...
Unfortunately we don't mix the two. Npgsql is available though and I understand there is an NHibernate dialect available.
> 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.
Oracle? SAP?
Oracle? SAP?
It works out about the same as Oracle now from SQL 2012. Azure is the only way to cut costs but the managed SQL services are awful. Both are equally hassle-some. SAP is different - you're not paying for a product, you're paying for consultants on subscription and a product...
Oracle tooling I.e. JDK, Netbeans, Oracle Linux (repackaged RHEL) etc is 100% free. VS isn't.
Oracle tooling I.e. JDK, Netbeans, Oracle Linux (repackaged RHEL) etc is 100% free. VS isn't.
This entire argument breaks down if you go for e.g. Postgres and Mono/Linux. We do exactly this and it works great. The parts where .NET really shines are all open source (or have a good OS implementation, such as Mono).
Yes I agree there entirely. But you might as well use java and get the better tooling and staff availability then...
You can use emacs + ommisharp. Tooling is surprisingly awesome.
Thanks - will look at that!
>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?
How can this happen if you already have the software licensed? Shouldn't the result be that you owe them $0?
The terms are conflicting across the board so they get to choose the interpretation that suits them best.
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.
I work on a .Net stack now and we are slowly moving over to Mono with Open Source alternatives to the MS specific stuff. Not because of investment fear but because the MS stack is both expensive and sub par. Most of the world has moved past them and there are much better options out there. C# is a wonderful language but the MS tooling needs a lot more work to get on par with what else is available. Especially the build tooling.
In our specific case, thought the expense is nice, it doesn't really matter. Security, on the other hand, is the driving reason we're migrating away from Windows.
Most dev licensing are covered with an Action Pack for less than 500$, and once you gain some traction as a Silver Partner. SQL Server, while expensive, isn't that bad compared to similar supported RDMS, and in any case, nothing prevents you from using a free RDMS in place.
We were a gold partner. There are no reasonable discounts over what you pay. Add to that the support isn't any better than the pay per incident support.
Action pack is reasonable value but you can't use it to deploy production kit on. Not only that the definition of internal use is so vague it's a risk.
We got an audit. It wasn't cheap to sort out what we thought was in compliance.
Action pack is reasonable value but you can't use it to deploy production kit on. Not only that the definition of internal use is so vague it's a risk.
We got an audit. It wasn't cheap to sort out what we thought was in compliance.
Of course you cannot use the software from a partner program externally. It was only concerning development licensing.
We were informed ambiguously that some development is production.
At that point we stopped playing word games and threw our devops infrastructure on Linux.
At that point we stopped playing word games and threw our devops infrastructure on Linux.
I do not know who told you that, but MS are pretty clear on what you can and cannot:
Internal use licenses are for use in a production environment for general internal
business purposes and not for any type of commercial purpose. For example, installing
the Windows Server operating system and Microsoft Exchange Server to set up an email
system that you can use to send business-related email is acceptable. However,
production use for external commercial purposes, such as hosting a commercial website,
is outside the scope of these rights.
Customer demonstration licenses can be used for demonstration purposes only by partners.
Sales and marketing employees of the organization can use this software to showcase
products to your customers, but demonstration products cannot be installed on customer
hardware or infrastructure and must be used with partner supervision.
Internal-training licenses can be used for training internal employees only. These
licenses cannot be used for customer training or for any commercial purpose.
MSDN subscriptions allow designated employees of your organization to use the available
software for the design, development, testing, and demonstration phases of application
development.Can you install JIRA on that copy of windows 2008 server R2 and access it via VPN?
Straight away we have ambiguity.
Can you run your staging site on it for demonstration purposes?
More ambiguity.
All it takes is a small mis-step.
Straight away we have ambiguity.
Can you run your staging site on it for demonstration purposes?
More ambiguity.
All it takes is a small mis-step.
Can you install JIRA on that copy of windows 2008 server R2 and access it via VPN?
Can you run your staging site on it for demonstration purposes?
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.
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.
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.
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!
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!
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.
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.
99% of startups simply will never hit the performance problems you seem to be talking about.
Yeah but its the ones that matter, that do? The successful ones with traction.
Indeed. We thought it was the same and nearly lost two big clients because we didn't see it coming.
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.
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.
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.
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.
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.
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.
> +10% productivity covers the tools
That's a bold claim to say using MS Dev tools are sure to increase productivity by 10%. Have anything to back that up? [e.g. studies, not your opinion or anecdotes].
And +10% productivity compared to what? Using C#/.Net without MS tools? Or compared to using a different stack (which seemed to be the OP's question)?
That's a bold claim to say using MS Dev tools are sure to increase productivity by 10%. Have anything to back that up? [e.g. studies, not your opinion or anecdotes].
And +10% productivity compared to what? Using C#/.Net without MS tools? Or compared to using a different stack (which seemed to be the OP's question)?
I'd say the assertion was under the assumption that the devs in question know the .Net stack well enough to gain at least a 10% productivity gain over using a stack they are less familiar with.
Still salary is paid out over time. Tools cost up-front. In a lean startup that could sink you?
>lean startup
You mean a bootstrapped startup?
http://steveblank.com/2009/11/02/lean-startups-aren%E2%80%99... http://practicetrumpstheory.com/2010/03/bootstrapping-a-lean...
You mean a bootstrapped startup?
http://steveblank.com/2009/11/02/lean-startups-aren%E2%80%99... http://practicetrumpstheory.com/2010/03/bootstrapping-a-lean...
The tools are free for a few years via BizSpark. A lot of companies find the bill at the end of the BizSpark period pretty painful, but you should usually at least be out of lean startup mode by then.
Just as a data point: http://meta.stackexchange.com/questions/10369/which-tools-an... Web Framework ASP.NET MVC 5 with MiniProfiler
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.
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.
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.
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.
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.
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.
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.
It's all about the product and users.
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.
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.
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."
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."
> 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.
Any choice may put off early employees. By sheer numbers, choosing .NET gives you a much larger hiring pool than, say, Haskell or NodeJS.
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.
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.
There's a reverse of this going on as well. I really like the C# programming language, and I'd rather work with it than with Node.js. But if I look around what kind of companies hire .net developers, and the sort of products they build, I get the feeling I'm very lucky to have joined the Ruby community early and have a nice spot in a cool company in which engineers are king and the tech is bleeding edge.
If pressed for work I'd even work sooner in a Node.JS shop, even if I feel that Node.js is attracting the sort of developers the Ruby community tries to break away from (i.e. the PHP and Java guys)
If pressed for work I'd even work sooner in a Node.JS shop, even if I feel that Node.js is attracting the sort of developers the Ruby community tries to break away from (i.e. the PHP and Java guys)
Observer bias.
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.
I'm sure there are good .NET engineers out there, but hiring/finding them is more like finding a needle in the haystack.
The sheer numbers are for the legions of ho-hum programmers building CRUD data-entry systems for e.g. aluminum can factories. The majority of startup-oriented engineers are a different group and I agree that .Net may be off-putting to them.
I disagree on the numbers you mention. There a amazing number of .NET engineers not writing CRUD apps. That is an over generalization. Take a look at the Unity crowd.
Also the vast majority of startups not building tech can get by with basic CRUD like apps for most of their business processes. Whatever gets you to market fastest. You will end up rewriting everything 3 times over probably in your company's life as I've learned but you won't get to do that unless you ship something.
Also the vast majority of startups not building tech can get by with basic CRUD like apps for most of their business processes. Whatever gets you to market fastest. You will end up rewriting everything 3 times over probably in your company's life as I've learned but you won't get to do that unless you ship something.
For what it's worth, I agree that .Net could be a viable and good tool for many startups, in principle. I just think that it isn't very popular amongst Silicon Valley startup types, and one should take that into account if we're talking about hiring issues and so on.
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.
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.
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.
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.
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.
Sign up for Bizspark and you don't have to worry about licensing for 3? years.
Nitpick, but Hotmail was Solaris for the backend (which I think was the hardest part to migrate)
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.
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.
Personally get to market fast, fast, fast. Between dreaming and loss of velocity meaning stalling... You just need to keep constantly moving forward.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
Is Mono viable for server these days?
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.
Nancy+OWIN+Mono+nginx is a very good stack.
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.
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.
The new stuff (ASP.NET vnext) will be highly mono compatible and like the current OWIN stuff, entirely decoupled from IIS.
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!
Should be a fun week!
I'd like to know some performance and language/standard library differences between mono+linux and .NET+Windows (e.g. support for entity framework was not even planned for mono last time I used .NET, which is a lot of time ago).
I always liked C# but windows server for me is a complete showstopper, I'm too comfortable in unix envs for sysadmin/devops. Well also for desktop actually :)
I always liked C# but windows server for me is a complete showstopper, I'm too comfortable in unix envs for sysadmin/devops. Well also for desktop actually :)
Mono is about 25 to 50% slower on computational stuff, which is negligible in almost any business application that has a multi-server topology.
We use C# for business logic (API). One of the first building blocks was to create an open framework for defining and running services that both compatible with .Net and Mono. We've been using that now for a quite a while. While VS is still our primary dev environment for the API, Xamarin Studio is becoming more and more appealing. One of the obstacles when developing with mono is that not all functionality is available or identical. It's of course always possible to contribute a fix or missing code, but sometimes it's just easier to work around it (once you know where the hole is). In production, everything runs on Linux and we use vagrant provisioned VMs to replicate the latest release locally. It works quite well for us now, but it took some effort.
That said, we chose this setup because we liked C#, not because we wanted WCF or ASP.Net. We actually don't like most of the heavy frameworks, including ORMs. Instead, use rely on HttpListener for web-services, PHP for HTML page composition in-front of the API and straight-up MySQL queries for all DB-related stuff. It makes it much easier to evolve a running system when you know what the bits do all the way down! Just my $0.02 cents.
We use C# for business logic (API). One of the first building blocks was to create an open framework for defining and running services that both compatible with .Net and Mono. We've been using that now for a quite a while. While VS is still our primary dev environment for the API, Xamarin Studio is becoming more and more appealing. One of the obstacles when developing with mono is that not all functionality is available or identical. It's of course always possible to contribute a fix or missing code, but sometimes it's just easier to work around it (once you know where the hole is). In production, everything runs on Linux and we use vagrant provisioned VMs to replicate the latest release locally. It works quite well for us now, but it took some effort.
That said, we chose this setup because we liked C#, not because we wanted WCF or ASP.Net. We actually don't like most of the heavy frameworks, including ORMs. Instead, use rely on HttpListener for web-services, PHP for HTML page composition in-front of the API and straight-up MySQL queries for all DB-related stuff. It makes it much easier to evolve a running system when you know what the bits do all the way down! Just my $0.02 cents.
The problem is that it will be really hard to convince managers to run Mono/linux against .Net/wserver when all resources and external support is for and based on the second one
It's going to be supported as a backend in the next version of ASP .NET (currently called vNext).
Details here: http://blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-g...
Details here: http://blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-g...
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)
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)
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.
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.
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.
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.
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.
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.
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!
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.
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.
Yes, it probably won't affect your revenue. Your profit however is likely to be affected; how much depends on your architecture and scale.
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.
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.
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.
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.
[deleted]
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.
For that reason .net doesn't seem to fly much in the B2C area, but is quite common for B2B stuff.
It doesn't matter at all. In general investors have no clue about coding.
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.
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.
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.
.NET is an advantage not a disadvantage. HN can be utterly bizarre sometimes.
Start with the end in mind.
> So in your opinion should I bite the bullet or go with what I know?
Yes.
Yes.
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.
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.
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.
Would this put off potential suitors? My gut instinct is that it probably would to an extent, but I'm not sure it'd outweigh my personal advantage of experience. If it makes any difference, I am funding this myself initially.
So in your opinion should I bite the bullet or go with what I know?