The Do’s and Don’ts for Early Stage Startup Engineering

How the right Software Development approach can make or break your startup

Startup engineering in the early stages of a new tech venture is tricky to say the least. There are many studies often cited that demonstrate the high failure rate of startups, such as a 92% failure rate within 3 years.

Whilst there are many reasons why startups fail, far too many for this blog post to cover, there is no escaping the fact that product engineering is one of the most critical components of a tech startup, if not the most important.

Fundamentally, early stage startups need to move quickly towards finding product-market fit. Taking the right technical approach is key to this. To be successful often requires a subtly different approach to software engineering than most other types of software engineering.

Having been involved with numerous tech startups for the best part of 10 years, I wish to share some of my thoughts on this subject. I have worked hands-on in various Engineering roles within startups, shipped many MVPs and have a great deal of experience getting early stage tech companies off the ground. These are some of my insights combined with speaking to a wide range of other startup CTOs in the industry.

So if you’re a startup or technical co-founder about to start building your first MVP or in the first few months of your startup journey — then this blog is for you.

Product roadmap vs Product-Market Fit

As an early stage startup, you are pre-Product Market Fit. This makes a world of difference as you are in search of your customer and market, which means deciding what to build next and making a product roadmap is not straightforward and very different to when the product is more mature.

1. Really understand what an MVP is

‘Minimal Viable Product’ or ‘MVP’ is one of those terms that is often branded around but its meaning has become lost along the way and is often misused or understood.

Going back to the fundamentals, MVP is a concept from Eric Ries book the Lean Startup and means a “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

The key takeaways are that the MVP needs to be:

- Minimum: The smallest amount of either work or money required to build it.

- A viable product : It needs to still be a product that works and serves the most basic needs of the person using it in order for it to be a valid test of the concept.

Furthermore, it needs to enable the startup to test the concept and gain an understanding about your customers’ needs without having to fully develop the product and iterate quickly if needed.

2. Prioritise what features to build

Once you have determined the business problem you are trying to solve and how you will measure success, you will need to decide on the initial features that your MVP will contain.

This will likely start as a long list of features of which there will be too many to be included within your MVP. You will need to aim for simplicity and ruthlessly prioritise which features you want to build.

Use a prioritisation matrix to determine the single core feature that you want to build and test first. A good example of this in practice is how Spotify initially focused on the single core feature of streaming music before adding in other features later down the road.

Keep in mind that an MVP isn’t a prototype, it needs to fulfil people’s needs and offer them real value.

3. Build, Measure, Learn

The Build, Measure, Learn cycle is a feedback loop and is one of the core components of the Lean Startup methodology.

The MVP is core to this, as this is the output of the Build phase. After which we collect feedback on the MVP by exposing it to potential customers, known as the Measure phase, before we go into the Learn phase where we analyse the feedback and decide what to do next. Finally, the cycle repeats whereby we iterate on the MVP based on the outcome of the Learn phase.

4. Minimise time through the feedback loop

In order to progress through the Build, Measure, Learn cycle effectively, it needs to happen at speed.

The tricky bit with the Build, Measure, Learn cycle, is that if the MVP phase has become bloated, it will take months before you are able to launch it with users. This in turn will increase the time needed to gather, measure and learn from the users. This will result in the data gathering becoming much more difficult as there will be more assumptions being tested with a bloated product.

In most cases, the main learning from this cycle is not around gathering new ideas for more features that we can build, but whether we are fundamentally on the right track with our underlying value proposition. If we are on the right track, we may want to test the same hypothesis again but using a more sophisticated experiment to increase our certainty or move along to the next experiment.

5. Release early and often

Following on from the previous point about bloated MVPs, in the early days of a startup your first product is likely to be a little bit ugly and rough around the edges, and that’s ok. The key thing at this stage is getting to market and start testing the idea with customers.

However, on the flip side, do not underestimate the importance of making the product look “reputable”. Minimum Viable Design is a good concept to follow as you don’t want your early users liking your product but being too embarrassed to share it because the design and presentation is so bad.

Engineering decisions

Now we’ve narrowed down what we are building, how do we best go about building it?

6. Focus on the short and medium term

The nature of rapidly building an MVP that will be iterated on demands short and medium term productivity, relative to the right way of building systems. By this, I mean architecture that might be a little under-engineered but still miles away from being spaghetti code.

Startup Engineering favours engineers that understand best practices for software development, such as clean coding but are equally able to iterate quickly and are comfortable with hacky code.

For some engineers, particularly those that may have worked in large tech companies where everything is done at scale whilst maintaining high engineering stands, writing hacky code can feel like an act of gross negligence and out of step with what it means to be a good software engineer. However, it is rarely possible to adhere to such high standards whilst quickly iterating new versions of the software at the pace required for a startup.

Technical debt is much less likely to kill early stage startups than being unable to find product market fit. If you’re successful at raising investment, then you will likely have the money to fix the shortcuts you’ve taken and raise the engineering standards.

7. Be pragmatic with your chosen Tech stack

Within engineering teams, there’s often the temptation to jump on the latest shiny technology, whether it’s a new programming language or framework.

However, new frameworks often have their own issues, such as bugs or unclear documentation, which often results in much time spent on getting basic things working. This is a distraction which you just don’t have time for. In this phase of a startup, you need to be able to trust the underlying technology and build quickly.

Therefore, it is important to choose a tech stack that is mature, well supported and widely adopted with a dynamic developer community. Stay away from pre-releases, Alpha, Beta, etc.

Using a widely adopted tech stack will also help when there is a need to find additional developers later down the line, as there will be a much wider pool of experienced talent available. At the same time, you want to avoid old or tech that is considered antiquated or unfashionable as this may discourage developers from working with you.

StackOverflow and GitHub are good places to assess how active a developer community is for a given language or framework and StackShare is useful for seeing which tech stacks other companies are using.

8. Don’t reinvent the wheel when there is a framework

Nowadays there are plugins or modules for most commonly needed features such as user authentication. For example, Ruby on Rails contains many ready-made plugins and modules that allow developers to start building a web app without writing boilerplate code. Similar such frameworks exist for other mature languages such as Django, FeatherJS or Laravel.

Furthermore, there are plenty of third party services that can assist with getting things off the ground quickly, such as Firebase or Heroku. Same goes for analytics and other useful product tools where there are plenty of off the shelf services such as Mixpanel, Intercom, Google Analytics, HotJar etc.

Never in a Startup roadmap should we encounter tasks such as:

- Build analytics and dashboarding tools

- Create A/B Framework

- Build chat messaging platform

(unless that is the core feature of your startup of course 😉)

9. Scale at the right time

There’s a right time and a wrong time for scaling and optimising your product.

In the early days of startup, the main aim will be to deliver a simple product that allows you to gather real user feedback and improve upon. At this stage, the number of users that you will likely have will be relatively low and an optimised product that can handle a large amount of users will be overkill, particularly when it is subject to change anyway depending on the outcome of user testing.

Premature scaling wastes scarce engineering resources that would be better spent on iterating the product particularly when the startup has little cash and few engineers. Scaling should be your startup’s last concern when it comes to building a MVP. I typically advocate using Heroku or any other services that make deployment as streamlined as possible and reduce typical Dev-Ops chores.

Sure, if all goes well then the time will come where you need to scale the product. Typically this may happen when you have reached Product Market Fit, and you will be in a good place to properly predict what level of scale will be required and also have the budget to support it.

There is a great mantra from Y-Combinator on this subject that says “Do things that don’t scale” that applies particularly here and also more generally to the MVP process.

The People and process

10. Hire a multi-functional team

At the start, you want to hire flexible and resourceful engineers that have cross functional skills and are not afraid to move from one area of expertise to another and quickly learn new tools. Look for versatile full-stack engineers vs experts in a particular field (unless the field is the focus point of your startup).

Culture fit is everything. They must have a can-do attitude and not naysay optimistic product ambitions, but also have a strong enough voice to say no to unrealistic expectations. Avoid the “rockstar” Engineers as these types of characters often create friction with other team members and are often only experts in certain project aspects.

Further down the line, once the product is more mature and you have a bigger budget, then you can begin to hire more specialist engineers as and when needed.

I’ve often found outsourcing via sites such as Upwork to be incredibly useful, either for the occasions where you might need to quickly hire someone with specialist skills or ongoing engineering resource that’s more cost effective than making a perm hire in the early days. Just make sure to properly vet candidates.

11. Build an agile process

Everyone has opinions about processes, some good and some bad. With an early stage startup, it’s best to keep this lightweight and agile.

Identify an existing process, like Scrum or Kanban then start small and slow with a streamlined workflow and a consensus on how things should be done. For example, if using Kanban, start with a minimal number of columns on your board, such as, “To Do”, “In Progress”, “Blocked” and “Done”. These stages will cover most of the stages you will need when starting out development.

Bear in mind that these methodologies are not meant to be static. So review regularly with your team to see what is working well and what isn’t. As you progress, you will likely add to the process incrementally, such as adding new columns or limiting the number of items in progress.

Avoid becoming dogmatic about process execution. More time can be wasted debating the minutiae of the process or spending too much time optimising it before it is needed.

12. Keep the team in the loop

As startups grow, it’s easy for silos to form. This can result in part of the team not knowing or fully understanding what the rest of the team is doing. This is very important from a product perspective as you may have a co-founder that is incredibly busy pitching all the time, they need to be kept fully in the loop.

Keeping aligned with co-founders is critical. Particularly, as product ideas are validated with customers, the pitch is likely to change, it’s important to stay in sync with messaging.

This also is another reason for the ruthless prioritisation of your product roadmap, as otherwise it is very easy to exceed the capabilities of your small team and hit delays, it may appear that the engineering team is not performing, when really it is down to not having a clear and narrow vision.

I am a big advocate for both regular product update meetings along with the occasional lengthier session such as Show and Tells or Demo days. Essentially, finding a healthy rhythm for keeping the team in the loop without disrupting the flow of work.

The end of the beginning

Startups are incredibly hard. Engineering Leadership is also incredibly hard. Even with this advice, there’s no escaping the reality that building a successful startup is an immensely challenging endeavour but immensely rewarding too.

Hopefully the advice here will enable you to move faster, pivot quickly and hone in on the right product decisions early on.

Outro

Thank you for reading and if you enjoyed reading The Do’s and Don’ts for early stage startup software Engineering, then please like it or comment below to help improve this article.

I offer consultancy and pro-bono advice to startups and scaleups. You can find out more about me and contact me here mikesmales.com

If this article helped you, then please buy me a coffee (via KoFi) ☕️😀