Archive for the ‘Startup’ Category

Sunday, November 12th, 2017

After reading Scott Berkun‘s excellent book on Making Things Happen. I started to think through how I approach projects and mapped the topics covered the book to my approach(s).

When tackling “things to do” or projects I tend to put on a pragmatic lens of getting things done. However when I think back through all projects that have been successful in my past they all went through basically the same stages. The scope of the stages change with the size of the project, however a little request such as “can you build this query for me” to large projects such as “build the realtime data pipeline”.

Project Phases

Beginning Phases

The beginning of the project is usually brimming with questions. Why are we doing this? What exactly will we be doing? Who’s doing it? There is always a discovery piece in the beginning. To address these questions and bring clarity to the project there needs to be 3 things.

  • Vision
  • Scope
  • Timeline

These things can be large and formal, or small and informal. The point is in successful projects they exist.


A vision is the “why”. It is deceptively hard to have a good vision. Many times a vision creeps in as the answer to “what” instead of “why”. A good vision will allow you to stand behind the work that will get done as part of the project. Everything that gets built needs to be able to look back to the vision and see it’s role in the project.

Bad visions:

  • To be in line with the industry we’re going to build a realtime data pipeline
  • Mary wants an answer by Friday
  • Pink is the best color, so all images on the website will be a pink hue.

Better visions:

  • Faster insights into our operations will allow for intra-day corrections in the business.
  • Mary is trying to find out how much money we spend weekly on lunches, next budget deadline is Friday.
  • Latest report showed people are mad when navigating our website.

There are always reasons why we are doing a project/task. Once those are known it allows for discovery on what is going to be built. Also inevitability at some point during a project (particularly larger projects) there will be roadblocks and frustrations. A good vision allows people to ask “why are we doing this again?” and get a reasonable answer.

It seems simple, but in my opinion a good vision is critical to a projects success. People feel like there is a meaningful goal and empowered to make their own decision as they line up with the vision. You’ll know you have a good vision when you find yourself and other repeating it..constantly.

A vision doesn’t necessarily have to be written down, but it helps if it is. It could be a document by itself, a section in a document, a email, a tweet, anything that’s searchable and reference-able.


The scope is more “what” are we going to build. There is usually a set of documents, or artifacts that come out of the scope phase. Scope is where you would write down the requirements, specs, and how we know the project is over.

Again the coming up with scope can be a large formal process that in and of itself takes a while to complete the documents for everything. Or it can be smaller items written down in an email, whiteboard, etc.


After you have the general scope you will should get a sense on how long this will take. Are there milestones along the way. Your timeline will be the most externally communicated item in a project.

Note on “Agile”

Maybe if you are on an “agile” team you’ve already given up on this article (“sounds like waterfall, ugh”) and and never got to this point. If you haven’t given up yet though, I want to say this article is compatible with the agile process. Agile is a way to deliver on projects. A well run agile team will have the documents and phased already broken down into smaller chunks so the whole process can get iterated on and get done faster.

Mid Phases

The middle phase is what most people thing of as “work” this is when the concrete tasks of completing whatever you set out to complete is getting down.

  • Design
  • Building
  • Testing

Again depending on the scope of the projects these phases can take varying amounts of time. From weeks to minutes.


Design can start at the beginning phases, however in the mid phase design is really about thinking completely through what is getting built. What trade off will there be. What needs to be done. There may have been specs already, designing here will take those specs and really do a deep dive onto what those specs really mean.





End Phases

There gets to be a transition point toward the end of the project where things are “close” but not “done”. This is the toughest part of every project. If you read any sort of project management literature you’ll see some sort of chart like like

Where in reality I think it’s something more like (forgive my crude free form drawing skills)

There is a hump of effort right at the transition from Mid-End. This is where there usually the most time pressure, there may be a few late nights, tensions are usually the highest as well. The phase at the end are.

  • Winddown
  • Testing
  • Exit

Work is still happening at the start of the end phase, but there should be a mentality shift. From building to shipping.




Testing shows up again… (TODO)

Exit Criteria


Why is this project inception?

I didn’t really talk much as to why I called this “project inception”. The thought behind “project inception” is that bigger projects will need to be broken down. All the pieces that are broken down should follow the same basic steps.

  • Vision. Scope, Timeline
  • Design
  • Building
    • Vision, Scope, Timeline
    • Design
    • Building
      • Vision, Scope, Timeline
      • Design
      • Building
      • Testing, Wind down
      • Exit Criteria
    • Testing, Wind down
    • Exit Criteria
  • Testing, Wind down
  • Exit

The outer projects would have formal documents, timelines in terms of months or even quarters, then they get narrowed down to the inner projects where items are documented in emails, or project management software, or GitHub issues (my personal favorite) and the timeline is in hours or days.

Projects are always ebbing and flowing, there is pragmatism throughout these stages. Nothing is ever set in stone, you can always go back, revisit and revise (granted some things will be much hard to change at a certain point). Successful project, large and small, do go through them and are cognizant of the fact that there are stages and which stage the current project(s) is in.

Saturday, 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

Saturday, 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