Personally get to market fast, fast, fast. Between dreaming and loss of velocity meaning stalling... You just need to keep constantly moving forward.
Ask HN: Would a .Net back-end put off potential acquisitors?
81–90 of 103 posts
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#82I 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.
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#83I 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.
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#84Rob 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.
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#85If 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.
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#86Earlier quoted context omitted.
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...
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#87Earlier quoted context omitted.
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'v…
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#88Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#89Earlier quoted context omitted.
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, Si…
Care to comment on your .Net/pgsql experience?
Re: Ask HN: Would a .Net back-end put off potential acquisitors?
#90Earlier quoted context omitted.
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 thems…
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, Si…
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.