Building software is one thing, but getting it in the hands of your customers is a whole different story. 

One of my first management positions was as a Release Manager for a software product. My job was to make sure we developed, packaged, and tested the right features. I worked there for over a year and oversaw only three releases. 

These days, we go all-in on Continuous Integration and Deployment. We push a change to our main git branch, and the newest increment of our product gets deployed automatically within minutes. CI/CD is a technological marvel. 

Silicon Valley startups have been preaching the gospel of daily releases. The more a team can go to production, the faster it can collect valuable feedback. The combination of flexible infrastructure and agile software development puts the team in a position to innovate constantly.

But Continuous Deployment isn't for everyone. Just because something is technically possible doesn't mean we should do it. Many teams have good reasons not to go live all the time.

Some teams work in highly regulated environments. Releasing a new version involves a significant overhead of red tape, QA gates, and documentation. Healthtech startups can't move fast and break things. Breaking things means losing your license or harming a patient. 

Fintech startups can't fail fast, either. Regulators will close your shop before you can roll back those thousands of faulty transactions.

Life sciences, defense contractors, aerospace companies... None have the luxury to push to production twenty times a day. That doesn't mean they are stuck in the eighties, though!

There's a wide spectrum between the traditional V-model and Move-fast-and-break-things. Getting the balance right for your product is crucial. We want as little red tape as possible without treating regulation or security as an afterthought. 

Here are a few tools to use to accelerate your development cycle if you can’t CI/CD.

CI/CD to staging

While you can't continuously deploy to production, you can set up CI/CD to a staging environment. Some early integration is far better than none. Build your product continuously in the staging environment and switch to the more traditional release processes once you have a good release candidate.

The staging environment gives developers all contemporary tools and lets them capture early feedback from business stakeholders. You can apply all the fast, agile software development techniques before switching to more formal quality gates and UAT sessions.

Sprint to the gate, and then take your time.

Mock that legacy system

Let's say a Fintech startup needs to integrate with a bank's ancient COBOL platform. That's three million lines of code that have been piling up since the eighties. You can't just throw that in a Docker container and run it locally. These kinds of legacy systems are brittle, unwieldy, undocumented, and on-prem. It creates a challenging development experience with difficult tests and a slow feedback cycle. If you're developing an app that integrates with such an environment, you need a tool to speed up your development experience.

A great way of integrating here is by mocking the legacy interface. Build a system that behaves like the legacy platform without impacting customers. A lot of these old-school interfaces are file-based, which lends itself well to Golden Master testing.

Mocking a legacy system takes time, but it's a great investment into developer productivity. Legacy systems are stable by definition, so the mock doesn't require much maintenance. Such mocks can become pretty complicated over time. Don't let that scare you. The team invests in development experience while documenting edge cases by uncovering and mocking weird behavior.

You don't need to rebuild the entire legacy system but can gradually build the mocks you need to support your features. It's one of those 80/20 things.

Automate red tape

In some industries, releasing a new product version comes with filling out forms and compliance documentation. These documents are vital for the regulators, and mistakes or omissions at this point are often show-stoppers.

While some human input will always be required, it truly makes sense to automate this red tape as much as possible. A startup I once worked with autogenerated about two-thirds of their compliance documentation, shaving days off every release.

Developers put time and effort into speeding up their test automation. The faster tests run, the more likely they are to be executed. Startups in highly regulated industries should take the same approach to their paperwork. Put in the effort to autogenerate these documents to minimize their impact on the release cycle.

Not every team has the luxury of Continuous Deployment. Some teams need time for formal testing, documentation, and compliance. That doesn't mean they are stuck using the outdated V-model. 

Find the sweet spot on the spectrum that allows you to go live as fast as your industry allows you.