8 ms·

Ask HN: Would a .Net back-end put off potential acquisitors?

• _random_ 12y ago
  > So in your opinion should I bite the bullet or go with what I know? Yes.
• pm 12y ago
  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.
• danabramov 12y ago
  Is Mono viable for server these days?
  • pionar 12y ago
    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 12y ago
      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 12y ago
        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 12y ago
          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!
    • scotu 12y ago
      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 :)
      • bjorg 12y ago
        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.
    • yulaow 12y ago
      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
  • stephen_g 12y ago
    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-generation-of-net-asp-net-vnext.aspx http://blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-g...
• speg 12y ago
  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.
• onion2k 12y ago
  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 12y ago
    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.
• chaostheory 12y ago
  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.
• srb24 12y ago
  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 12y ago
    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 12y ago
      99% of startups simply will never hit the performance problems you seem to be talking about.
      • JoeAltmaier 12y ago
        Yeah but its the ones that matter, that do? The successful ones with traction.
        • allegory 12y ago
          Indeed. We thought it was the same and nearly lost two big clients because we didn't see it coming.
• frou_dh 12y ago
  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!
• plasma 12y ago
  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.
• lukasm 12y ago
  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.
• chx 12y ago
  Just as a data point: http://meta.stackexchange.com/questions/10369/which-tools-and-technologies-are-used-to-build-the-stack-exchange-network http://meta.stackexchange.com/questions/10369/which-tools-an... Web Framework ASP.NET MVC 5 with MiniProfiler
• bhouston 12y ago
  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.
• DanielBMarkham 12y ago
  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.
• allegory 12y ago
  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.
  • justin66 12y ago
    > 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?
    • allegory 12y ago
• us0r 12y ago
  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 12y ago
    Nitpick, but Hotmail was Solaris for the backend (which I think was the hardest part to migrate)
• silverbax88 12y ago
  It doesn't matter at all. In general investors have no clue about coding.
  • tlogan 12y ago
    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 12y ago
      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.
• tlogan 12y ago
  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 12y ago
    Yes, it probably won't affect your revenue. Your profit however is likely to be affected; how much depends on your architecture and scale.
• rbanffy 12y ago
  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.
• nkohari 12y ago
  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.
• programminggeek 12y ago
  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 12y ago
  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.
• nbevans 12y ago
  .NET is an advantage not a disadvantage. HN can be utterly bizarre sometimes.
• opless 12y ago
  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.
• hpagey 12y ago
  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.
• throwawayforob 12y ago
  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 12y ago
    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.
• joshuaellinger 12y ago
  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.
  • frostmatthew 12y ago
    > +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)?
    • germano 12y ago
      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.
  • JoeAltmaier 12y ago
    Still salary is paid out over time. Tools cost up-front. In a lean startup that could sink you?
    • 12y ago
• fidotron 12y ago
  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.
• jenandre 12y ago
  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.
• dennybritz 12y ago
  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 12y ago
    > 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 12y ago
      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 12y ago
        Observer bias.
        • dennybritz 12y ago
          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.
• ridruejo 12y ago
  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)
• sheetjs 12y ago
  > 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 12y ago
    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.
• deleted 12y ago
  [deleted]
• ruebenramirez 12y ago
  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.
• personZ 12y ago
  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 12y ago
    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.
• kross 12y ago
  Start with the end in mind.
• dannyr 12y ago
  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.
• sourc3 12y ago
  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.
• teapartyBS 12y ago
  No, but that's not going to stop everyone here rehashing everything you have ever heard about lock-in, licensing costs, and how bad all .Net programmers are. Businesses actually look at business. They would see licensing as one factor among many. If you have a good business it wont matter. People on HN will tell you it does, but it doesn't. Why is that you may ask? Because people still feel like they need to advocate for linux, node, go, ruby etc...they are raging against the machine. It's not enough to be interested in technology and coding... You have to be invested in their mindset and believe in their superiority. For some reason it requires constant affirmation... Which is weird seeing as how it's so superior. The people on this site will always tell you something that justifies the geek chic zeitgeist. Asking the opinions of the masses has one problem though... Most of them aren't successful and never will be no matter how "pure" their technology choices were. (At the startup game. Maybe they will successfully peddle their brand of bullshit from place to place but it sure seems like all these guys know an awful lot about startups. It's enough to make you question the statistics about startups failing.)
• goofygrin 12y ago
  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.
• fauigerzigerk 12y ago
  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.
• bdcravens 12y ago
  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.
• jezell 12y ago
  Any time you build a large application, you need to be able to choose the best language and platform for any given part of the system. It doesn't matter if you like Node.JS, sometimes Go is a better solution. It doesn't matter if you like Ruby, sometimes you need a little C++. If you get yourself so caught up in .NET that the entire solution needs to be built with it, you are starting out with a terribly and broken architecture, that either will fall apart in the future when you realize .NET isn't the best tool for a certain part of the system, or severely limit your ability to add new features because you never come to that realization. If you stick with a pure .NET stack, your app will not only be more expensive to maintain, but also have less functionality. The thing you have to realize is that the benefit of using something other than .NET has more to do with how many lines of code you don't have to write than it has to do with how many lines of code you have to write. It doesn't matter if right out of the gate you may be slower with a new platform, because: a) that won't last long b) the amount and quality of open source code on the .NET platform is laughable compared to just about any other platform, and that's a very big deal. Open source moves fast enough to overtake giants like Microsoft, use that to your advantage. Your competitors certainly will be doing it. So what tool would I recommend instead of .NET? Your brain. There is no silver bullet. Choose the correct platform for every part of your system. Embrace open source. Don't reinvent wheels that don't need to be reinvented. Perhaps there will be parts of the system that make sense to write with .NET, but certainly it won't make sense for all of them. There are tools like mono and Xamarin that will allow you to have a bit more platform flexibility while still using .NET. At the very least, get off of Windows and don't pay money for databases like SQL server when there are free alternatives that will better address your needs. Build your backend with something like microservices so that you are free to use something other than .NET when it makes sense. Force yourself to build a part of the system with something else to validate your architecture works even if it is a small part of the system.