A startup’s guide to software delivery

One of the biggest factors in the success of a startup is its ability to quickly and confidently deliver software. As more consumers interact with businesses through a digital interface and more products embrace those interfaces as the opportunity to differentiate, speed and agility are paramount. It’s what makes or breaks a company.

As your startup grows, it’s important that your software delivery strategy evolves with you. Your software processes and tool choices will naturally change as you scale, but optimizing too early or letting them grow without a clear vision of where you’re going can cost you precious time and agility. I’ve seen how the right choices can pay huge dividends — and how the wrong choices can lead to time-consuming problems that could have been avoided.

As we know from Conway’s law, your software architecture and your organizational structure are deeply linked. It turns out that how you deliver is greatly impacted by both organizational structure and architecture. This is true at every stage of a startup but even more important in relation to how startups go through rapid growth. Software delivery on a team of two people is vastly different from software delivery on a team of 200.

Decisions you make at key growth inflection points can set you up for either turbocharged growth or mounting roadblocks.

Founding stage: Keep it simple

The founding phase is the exciting exploratory phase. You have an idea and a few engineers.

The key during this phase is to keep the architecture and tooling as simple and flexible as possible. Building a company is all about execution, so get the tools you need to execute consistently and put the rest on hold.

One place you can invest without overdoing it is in continuous integration and continuous deployment (CI/CD). CI/CD enables developer teams to get feedback fast, learn from it, and deliver code changes quickly and reliably. While you’re trying to find product-market fit, learning fast is the name of the game. When systems start to become more complex, you’ll have the practices and tooling in place to handle them easily. By not having the ability to learn and adapt quickly, you give your competitors a massive edge.

One other place where early, simple investments really pay off is in operability. You want the simplest possible codebase: probably a monolith and a basic deploy. But if you don’t have some basic tools for observability, each user issue is going to take orders of magnitude longer than necessary to track down. That’s time you could be using to advance your feature set.

Your implementation here may be some placeholders with simple approaches. But those placeholders will force you to design effectively so that you can enhance later without massive rewrites.

Very early stage: Maintain efficiency and productivity

At 10 to 20 engineers, you likely don’t have a person dedicated to developer efficiency or tooling. Company priorities are still shifting, and although it may feel cumbersome for your team to be working as a single team, keep at it. Look for more fluid ways of creating independent workstreams without concrete team definitions or deep specialization. Your team will benefit from having everyone responsible for creating tools, processes and code rather than relying on a single person. In the long run, it will help foster efficiency and productivity.