5 ms·

Ask HN: Is it a mistake to base my company on the MSFT stack?

• davidcrow 15y ago
  Check out BizSpark http://bizspark.com http://bizspark.com for a Microsoft marketing program that gets startups access to the stack for zero upfront costs (yes that's carefully worded). Microsoft has a history of acquisitions, but they tend to be based on talent, shared customers, market access or defensible technologies. Don Dodge covered this a while ago http://dondodge.typepad.com/the_next_big_thing/2005/10/microsoft_will_.html http://dondodge.typepad.com/the_next_big_thing/2005/10/micro... You bring up a good question about the risk tolerance of potential hires. No opinion on it.
  • anonymois 15y ago
    I'm not worried about licensing costs at the moment, thanks to BizSpark. My product isn't in an industry that Microsoft seems very interested in, nor do I feel like it'd be wise to have the only potential acquirer be Microsoft (which is why I made the point about being concerned about acquisitions).
• burgerbrain 15y ago
  Building your company on a MSFT stack might be affordable when you are still in the startup stage, and it might be doable when you're at the multi-national stage, but in between it is going to be expensive. On the other hand, developers for a MSFT stack tend to be pretty cheap. Quality varies of course, but there are lots of them..
• maxdemarzi 15y ago
  Finding "excellent" people to work for any start-up is very hard. You already know the C# is going to make it harder to find risk tolerant folks. People working on Scala are most likely doing it because they WANT to, and would want to do it at a start-up. The acquisition question is business pre-optimization and any large acquirer probably won't care. Just build your prototype and get it out the door, don't worry too much about the details.
• jfdi 15y ago
  There's an old video of Steve Jobs circa 1997 where someone in the audience puts him in the hot seat about some 'hot' technology at the time. As I recall, his response was something along the lines of --- maybe we missed an opportunity to use a neat technology in the product, but the product will win in the long run because we remain focused on our customers, and work backwords into the tech. You can typically use whatever tech you want to power the thing. If you use open and well documented communications API/infrastructure then others (including your team) can extend your product with lots of different technologies. For #1 - You can find good C# coders. But you can find great developers who know C# among other things. For #2 - Generally there are two camps in acquisitions (strictly regarding tech). The Microsoft camp, and the other camp. The two camps have their own large ecosystems and there is some overlap. I think for this you just need to understand (just like you understand your customers) which potential acquirers may come along and what they care about. Many times they'll want to rewrite some things anyway and better understand your roadmap (which can always evolve!!!). Long story short, stop building prototypes. Avoid optimizing prematurely as they say. Get one prototype working well, get great developers and you'll make the right tech decisions as a team. If you don't, you get to change them. Good luck!
• e1ven 15y ago
  The biggest mistake, IMO, if you actually want to SHIP, is using anything except the software you already know. Let me explain- Too often, projects are started pie-in-the-sky, and using everything perfectly, using the de jour framework.. You spend 80% of your precious time trying to learn it, for marginal benefit. Yeah, it might be cheaper when you have 1M users. Deal with it then. For any software project, you'll probably need to expand a bit, that's a given, but don't go out to far; Go one village over... Try moving from MySQL to Postgres. Or perhaps involve Mongo if need be. Don't fly in technology from the other side of the universe unless you have an actual business need to. The odds are against you finishing your project; Keep that in mind, and work to maximize chances of shipping. This means using the stuff you know now.
• NY_USA_Hacker 15y ago
  Good question. You asked it, so now I don't have to! The comments are good. So, yes, for my startup, I'm using the Microsoft 'stack'. But for C#, I'm not using it! Haven't touched it! Instead I'm using Visual Basic .NET and .NET, ADO.NET, ASP.NET, Windows Server, etc. For 'training' people, my guess is that 'basic' Visual Basic .NET will prove to be super easy for nearly any reasonably talented, interested hire to learn. Why? For nearly everything I'm doing, nearly all of the the syntax and semantics of Visual Basic (the current .NET version) couldn't be easier to read and type. I also like the Visual Basic compiler, just as shipped with the .NET Framework (version 4.0). The Visual Basic compiler is right there as file VBC.EXE, and to run it just use a command line or some scripting language (I am using ObjectRexx) to type the command line. The command line syntax is short and easy to understand. The compiler is fast and generates remarkably small EXE files. The error messages are from good to quite nice. So far I've found no bugs at all. I'm thrilled. My view is that the syntax of C# is more difficult, and so far I see no reason to struggle with it. So, for my startup, so far it's just Visual Basic and .NET. For typing in software, I just use my favorite text editor KEdit with a lot of macros. And I make heavy use of just the ordinary desktop 'windowing': So, when typing, typically I have about 15 windows open, 'tiled' with the upper left corners running from upper right to lower left (can always see at least the top or left side of each window and can rearrange the Z-order without moving any windows). So, I have windows with pieces of my design, software, testing, documentation, etc. all readily available. It's nice. I'm also thrilled with how ASP.NET works when I just type in Web page software with KEdit. So, when a browser displays a page under development, if there are Visual Basic errors then get a nice page in the browser making clear what the errors are. NICE. When the compiler errors are gone, then at the bottom of the Web page is a NICE description of all the work ASP.NET did with a 'control tree', various ID values, some sizes in bytes, some timings in milliseconds, etc. NICE. When finally understand from 5000 feet up basically what ASP.NET is doing, then it's fairly simple and clear and okay. Why I am staying with Microsoft: (1) What I Knew. I got started on that path to Microsoft and stayed on it. So I did a lot with OS/2, and when I changed to Windows it was, of course, similar. (2) Documentation. I am finding that my code is heavily just some 'glue' to call code from Microsoft, especially their .NET. So, I do more reading documentation than writing code. So, I care a lot about the quality of the documentation. The Microsoft .NET documentation is enormous. I have about 2400 Web pages of Microsoft documentation on my computer, abstracted, and indexed, and I put as comments in my code the file system tree names of relevant documentation and with one keystroke KEdit will display the Web page. Nice. But that's a LOT of documentation. Writing such documentation is EXPENSIVE. In simple terms, the quality from Microsoft is high. More deeply, often the writing quality of the real 'content' needs to be improved. I'm afraid that, without the big bucks of Microsoft, alternative documentation would be worse. (3) Support. If my startup is successful, then I will want a lot of technical support. I'll be willing and able to pay for the support. I am hoping that going with Microsoft I will be able to get some good support. So far I've gotten some surprisingly good support for free from various experts at Microsoft via various Microsoft fora. Of course, to get a good response, tend to need to have done some good homework and actually ask a good question! The free support is so good that I am looking forward to some nice help when I'm able to pay. For Unix flavors, I'd be afraid on each of these three points. Afraid? Yes. Well informed on Unix? No!
• NY_Entrepreneur 15y ago
  Good question. You asked it, so now I don't have to! The comments are good. So, yes, for my startup, I'm using the Microsoft 'stack'. But for C#, I'm not using it! Haven't touched it! Instead I'm using Visual Basic .NET and .NET, ADO.NET, ASP.NET, Windows Server, etc. For 'training' people, my guess is that 'basic' Visual Basic .NET will prove to be super easy for nearly any reasonably talented, interested hire to learn. Why? For nearly everything I'm doing, nearly all of the the syntax and semantics of Visual Basic (the current .NET version) couldn't be easier to read and type. I also like the Visual Basic compiler, just as shipped with the .NET Framework (version 4.0). The Visual Basic compiler is right there as file VBC.EXE, and to run it just use a command line or some scripting language (I am using ObjectRexx) to type the command line. The command line syntax is short and easy to understand. The compiler is fast and generates remarkably small EXE files. The error messages are from good to quite nice. So far I've found no bugs at all. I'm thrilled. My view is that the syntax of C# is more difficult, and so far I see no reason to struggle with it. So, for my startup, so far it's just Visual Basic and .NET. For typing in software, I just use my favorite text editor KEdit with a lot of macros. And I make heavy use of just the ordinary desktop 'windowing': So, when typing, typically I have about 15 windows open, 'tiled' with the upper left corners running from upper right to lower left (can always see at least the top or left side of each window and can rearrange the Z-order without moving any windows). So, I have windows with pieces of my design, software, testing, documentation, etc. all readily available. It's nice. I'm also thrilled with how ASP.NET works when I just type in Web page software with KEdit. So, when a browser displays a page under development, if there are Visual Basic errors then get a nice page in the browser making clear what the errors are. NICE. When the compiler errors are gone, then at the bottom of the Web page is a NICE description of all the work ASP.NET did with a 'control tree', various ID values, some sizes in bytes, some timings in milliseconds, etc. NICE. When finally understand from 5000 feet up basically what ASP.NET is doing, then it's fairly simple and clear and okay. Why I am staying with Microsoft: (1) What I Knew. I got started on that path to Microsoft and stayed on it. So I did a lot with OS/2, and when I changed to Windows it was, of course, similar. (2) Documentation. I am finding that my code is heavily just some 'glue' to call code from Microsoft, especially their .NET. So, I do more reading documentation than writing code. So, I care a lot about the quality of the documentation. The Microsoft .NET documentation is enormous. I have about 2400 Web pages of Microsoft documentation on my computer, abstracted, and indexed, and I put as comments in my code the file system tree names of relevant documentation and with one keystroke KEdit will display the Web page. Nice. But that's a LOT of documentation. Writing such documentation is EXPENSIVE. In simple terms, the quality from Microsoft is high. More deeply, often the writing quality of the real 'content' needs to be improved. I'm afraid that, without the big bucks of Microsoft, alternative documentation would be worse. (3) Support. If my startup is successful, then I will want a lot of technical support. I'll be willing and able to pay for the support. I am hoping that going with Microsoft I will be able to get some good support. So far I've gotten some surprisingly good support for free from various experts at Microsoft via various Microsoft fora. Of course, to get a good response, tend to need to have done some good homework and actually ask a good question! The free support is so good that I am looking forward to some nice help when I'm able to pay. For Unix flavors, I'd be afraid on each of these three points. Afraid? Yes. Well informed on Unix? No!
• allwein 15y ago
  No mistake at all. I write iOS apps both for myself and as a contractor. All of the web services that my apps run off are done in C# on Windows. As many others mentioned, the best tool is the one you already have/know.