June 21st, 2014

C# is a wonderful language, with a rich eco system – unapologetically build your startup technology in .NET

.NET Logo

One thing I’ve noticed is very rarely do startups build on the .NET stack. I’ve been lucky to be a part of many startups that have used the Microsoft stack to quickly and cheaply (yes, cheaply <pause for comedic effect> on the Microsoft stack) get stuff done. This is a shame because people are missing out on a powerful option for their startup.

It’s understandable why so many startups are build on the OSS stack. The tools are plentiful and always free to download. The languages are fun. I’ve dabbled with Python. I’ve build Ruby on Rail prototypes. They’re fine tools. This isn’t an attempt to peel people away from the OSS stack, far from it. I want to expose what Microsoft and the community around .NET has to offer for a startup.

.NET is cheap

Yes, it’s cheap to get started with C# in your startup. I feel Microsoft has a reputation (admittedly a deserved reputation) for being expensive and this is the number one reason as to why startups don’t give Microsoft a chance. In reality Microsoft doesn’t want your money until you can afford to give it to them.

By Steve Evans from Citizen of the World (Piggy Bank Uploaded by russavia) CC-BY-2.0 via Wikimedia Commons

  • Visual Studio Express & SQL Server Express

    The first stage of your startup project will be some form of MVP. Before you even commit to doing a startup you can get started creating a prototype/MVP with Visual Studio Express. VS Express is simply a free version of Visual Studio. And Visual Studio is hands down the best IDE/debugger I’ve ever used. If there is one positive thing I’ve heard my OSS friends say about C# is that they wish they could use Visual Studio.

    There are a few features missing from VS Express. Most of the missing features won’t become a pain until you grow out your team, and grow out the code base. If upgrading to a newer version of VS makes sense for the current state of your startup the feel free to upgrade, the code you create with Express is compatible.

    If you require a database Microsoft also has a free version of SQL Server. There is also nothing preventing you from using MySQL, PostgreSQL, or really any RDMS with your C# project.

  • Azure

    Azure is Microsoft’s cloud offering and it’s really good. Getting started is easy, and it makes the licensing costs reasonable. Personally I even do my development inside an Azure VM. With any sort of MSDN subscription there is $150 monthly credit for using Azure. Again there is also nothing stopping you from using another cloud provider, like Amazon, with your .NET projects. Things are just a little bit easier if you go with Azure.

  • Bizspark

    Simply put, Bizspark is amazing. Free access to Microsoft tools for 3 years for startups. Bizspark isn’t as well known as it should be. Microsoft will also help promote and support your startup when you are in the Bizspark program. This Bizspark program also gives you an MSDN license so you can use the aforementioned Azure credit.

.NET is Popular (outside the startup world)

C# in particular is a very popular language in the professional world. Popularity matters because it’ll be easier to find developers fluent in the language, and rarely will you be blazing a completely new trail.

By Fire_breathing_2_Luc_Viatour.jpg: Luc Viatour derivative work: Amada44  talk to me (Fire_breathing_2_Luc_Viatour.jpg) CC-BY-SA-2.5-2.0-1.0, CC-BY-SA-3.0 or GFDL, via Wikimedia Commons

The more popular the language that the code is written in, the easier it is to find people to work in that language. You’ll be able to find the person with the skill set in the right level for what you need. Have some entry level work? Since it’s a popular language there are people itching to get experience in C#. Have some hard core problems? Since it’s a popular language there are people with 10+ years experience in C#.

A popular language/toolset has a plethora of people who are dealing with the same issues as you are, and people who solved them. The library support for .NET is amazing and getting better every day. Sure writing an OFX parser in Rust is fun, but wouldn’t it be better for your business to just download a library and get more important stuff done?


Yes, you should not pick a language/toolset solely on the promise of it easily scaling to bazillions of users. However all other things being equal wouldn’t you prefer a solution that doesn’t require architecture acrobatics after your first big burst of success? I’m being slightly facetious. The fact is Microsoft’s done a lot of the hard tuning work and put it right into the CLR.

Turning Torso 3 by Väsk - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons

Turning Torso 3 by VäskOwn work. Licensed under CC BY-SA 3.0 via Wikimedia Commons

It’s been my experience that out of the box .NET code has the ability to scale far enough for most startups that performance becomes a non-issue, particularly at the early stages. This is just another thing to not think about as you are growing your company. Currently at eMoney advisor there are 2 middle of the road servers that can process millions of transactions a day. All the code for the processing is written in C#.

The .NET languages, and in particular C# also have design decisions built into the language that enable the CLR to do some pretty fantastic optimizations.


Another argument I’ve heard against the .NET stack is people fear vendor lock-in. I’ll concede that this was an issue a decade or 2 ago. Today Microsoft plays much more nicely with other tools/platforms. Microsoft is even moving in the direction to be more open.

She left the door open by Hartwig HKD. Licensed under CC BY-ND 2.0

She left the door open by Hartwig HKD. Licensed under CC BY-ND 2.0 via Flickr

Go look at Github and CodePlex to see how many open source C# project there are. The projects are not only open, there are a lot of good open source projects.

Microsoft also has a whole "open center". The center is dedicated to showcasing Microsoft’s community efforts. If that’s still not open enough for you, there is also Mono that let’s you run .NET applications on Linux and Mac machines.

Microsoft’s made great strides in providing a robust, fun, popular community around it’s technology. More people in the startup world should embrace it.

Agree? Disagree? Drop me an email blog [at] sirchristian [dot] net or message me on twitter @sirchristian

March 15th, 2014

TLDR – Don’t over architect.

As a technical person I tend to think about how code and systems will be structured. I start geeking out over folder structure, object hierarchy, separation of concerns, testability, mutability, scalability, etc, etc, etc. However THIS. IS. WRONG..

Software architecture must first be thought of in terms of what the business is trying to do, then architect from there. Let’s take a journey through the stages of a typical startup product and explore what kinds of architecture is appropriate for that stage.

Product Discovery

This stage is the hardest for a software engineer turned entrepreneur. There should be no architecture at this stage. That’s right. NOTHING.


Put your coding tools down before someone gets hurt. You need something that can show off an idea so people can get some idea of what you are doing. For this use WordPress, Simplpost, LaunchRock, etc. Something that allows for quick iterations and capturing of something (hint: email addresses are great to collect) that can validate your idea. Before there are any ideas of downloading a CMS and hosing it on a home built linux server, or spinning up a shiny new instance in the cloud. No. Use a tool hosted by experts. There are a billion free options out there. Pick the first tool that looks good enough. Don’t sweat the details.

Beside some sort of landing page and tools to build one the only other tool you are allowed during product discovery is a spreadsheet. Spreadsheet are great to keep track of whatever your business needs to keep track of.

Minimally Viable Product (MVP)

Congratulations. There is some inkling that your idea may actually be worth pursuing.


Before laying out the architecture for the MVP make sure you aren’t lying to yourself, just so you can use your comfy dev tool. Take 5 minutes and think about it. Are you really ready to build the MVP for your startup? I’ll wait while you think about your answer.

For your Minimally Viable Product the architecture should really be something quick. You will be building the wrong thing at first and it will need to be thrown away. Once you are on track to be building the right thing, that product also will be thrown away. Don’t burn up all your time on something that will be scrapped later.
High level architecture should not be a concern when building an MVP. This is creating Technical Debt. Starting a business takes SOME investment. It’s okay to take on Technical Debt now.

Creating an MVP is all about quickly getting something in the hands of potential customers so then can test it out.

Here is an outline of the architecture to use.

  • Use the language you are most comfortable with.
    Any language will do for an MVP. This is not the time to learn a new language. Learning a new language is great, and side projects are the perfect place to learn a new language. Early stage startups are not the right place.
  • Use SQL.
    Do not use NoSQL. Software engineers like myself love the idea of using a NoSQL data store. There is an elegance to NoSQL. NoSQL has its place, just not now. Do not think about WebScale while building your MVP. The data you get from having your MVP out in the wild may be the most valuable thing you get out of your MVP. SQL insures that the data is there, and since it is relational you can query data out into different forms depending on how the business evolves.
  • No Unit Testing
    Unit testing at this stage will slow you down. Yes there will be bugs, nobody will care.

That’s all the guidelines needed for an MVP. Again MVP is all about quick, lean, and discovery.

Beta Product

Once you have customers, now you can build your beta product.


Here is where you can start tackling some of the technical debt left by the MVP. If you really truly kept your MVP barebones, from the tech stack point of view, you can start a new codebase. Most likely though your MVP has moving parts that will be hard to write over from scratch. Plus a full rewrite normally isn’t the right answer. (Yes, the MVP section said we’d be throwing out the MVP, that was a little white lie to make you write your MVP faster.) Writing a beta is taking the technical and business lessons learned from the MVP and migrating them to a more stable, slightly more scalable package.

What kinda of things should be include in the beta product?

  • Measurements and metrics.
    Building a business isn’t a static thing. Events are always in motion. Being able to measure and analyze technical and business metrics will be critical to growth. Now is a great time to put some thought into how you will capture and report on this data. Don’t go crazy measuring. Pick a few critical metrics and start there. This may or may not include an A/B testing framework
  • Use SQL.
  • Automation frameworks.
    Much like the MVP a beta product will constantly be developed and released. Investing in automating some of the technical processes will help with continuous deployment.
  • Testing
    By now SOME of code base has become “core”. Using unit tests sparingly in the core part of the application will allow for some confidence when moving parts around the core need to change. A word of caution, unit test too much and development will slow down. Pick your critical application parts carefully.

A beta product is where some more “traditional” software development processes start to be acceptable. This is also a time where you may want to look for additional technical help. Be it a permanent addition to your team, a contractor, or extra time for you to spend on product.


Going from Beta to v1.0 will be less of a clear line than it was between MVP and Beta.


You may arrive at v1.0 quite organically. Arguably it would be better to arrive at v1.0 after doing multiple iterations of your product based on customer interviews, metrics, and internal dialogs. A v1.0 product needs a balance of features, stability, and flexibility. Your v1.0 product may not completely pay back the technical debt left over by the MVP, however some of that debt will start becoming a headache at this point. There needs to be at least a plan to tackle that technical debt.

Product scalability should be thought about it this stage, not implemented. This means architecture hooks can be put in place for future scalability. It means you can design for easy migration to a more scalable product. Scalability should not be the main focus.

Architecting a v1.0 product is going to be fairly comfortable for a traditional software engineer.

  • Tackle technical debt.
    At least have an eye toward how you will tackle the technical debt
  • Still use SQL
  • Enhance your automation suite
  • Enhance your metrics


Now your product is “real”.


People know about you. Congratulations you are now thrown into the bucket of “successful startup” (even though failure is still a real possibility). At this point you may even get to use NoSQL! Business and technical scalability will be a real concern. There is no real set of bullet points of a product like this. This is what all those programming courses and blog entries have been training you for.

Agree? Disagree? Drop me an email blog [at] sirchristian [dot] net or message me on twitter @sirchristian

November 6th, 2013

I’m convinced that Powershell is the way that .NET web applications should be installed on the server(s). In the past I’ve created a separate executable file to do setup for me. Recently I’ve found executing an exe through Powershell (particularly when using Powershell for your deployment script) takes away from the Powershell goodness.

On pretty much every project I’ve needed to use a database on in the past 5 or 6 years I’ve used the excellent Insight Micro-ORM as my ORM. As a companion to the ORM @jonwagnerdotcom has also released Insight.Database.Schema that can automatically install the DB schema and upgrade the schema.

Insight.Database.Schema is a .NET dll so we can reference it through Powershell.

function InstallDatabase([string] $ConnectionString) {
	Write-Host "Installing Database"

	# Get the insight schema dll
	# Make sure the DB Exists

	# Connect to the DB
	$db = New-Object -TypeName System.Data.SqlClient.SqlConnection -ArgumentList $ConnectionString

	# Get the sql files to install
	$sqlFiles = Get-ChildItem .\Database
	# Create the schema by looping through our sql files
	$schema = New-Object -TypeName Insight.Database.Schema.SchemaObjectCollection
	foreach($sqlFile in $sqlFiles) {
		Write-Host "Adding SQL from $sqlFile to schema"
	$schema.StripPrintStatements = $true

	# Install the schema into the DB
	$installer = New-Object -TypeName Insight.Database.Schema.SchemaInstaller -ArgumentList $db
	(New-Object -TypeName Insight.Database.Schema.SchemaEventConsoleLogger).Attach($installer);
	$installer.Install("SourceInquiry", $schema)

	# Cleanup
	Write-Host "Finished installing Database"

Doing it this way requires only management of the SQL files and Insight does the rest! Leave any questions in the comments or reach out to me on Twitter.