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.
v1.0
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
v.Next
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
