Transitioning From Prototype to Production
Your team moves fast! My team does too. You work on a number of large production systems, and deviating from the process can be a source of innovation.
When starting something new or experimental it is helpful to break out a team and hack. Amazing and innovative work comes from the teams closest to the ground when they come together to solve problems.
Too often though, once the magic has been revealed, it becomes imperative to launch those tools and products to the world.
But how can something built in a day be ready for production?
How can one engineer’s side-project deploy to millions of active users?
You need a plan to get your application from prototype to production as quickly as possible. Here is how you get there.
1. Identify Neglected Stakeholders
You had the application developed in the dark. Or, best case, over a day or two during a hackathon (Hey! At least it wasn’t in secret). Despite how it was built though, more than the engineers at hand have a say in how your product goes out.
You need to identify everyone with a stake in what you are building. You don’t need them to all agree on the direction you are doing, but everyone with a say needs to know what’s going on.
They need to make sure that what you’ve built won’t negatively affect any current or future metrics or strategies. They need to make sure it is not duplicative of something else in-flight. And, in some cases they need to ensure that it meets compliance.
I’ve had projects done this way that have fallen significantly short of legal requirements or ADA compliance. This has been a massive blessing.
If your company’s legal team sees gaps in what you have built, it can often alleviate pressure from the product side of the business and give your team the time it needs to make sure everything is in order.
2. Rally Support Teams
More than just software engineers build software. Other functions such as QA or DevSecOps professionals add valuable insight. Get these teams in as soon as possible.
Actually, it’s even better if you looped a few into your covert operations. While cutting corners may have been needed to prove the value of what you created, these people need to be cut in as soon as it becomes real.
If your company has a QA team, they are often the closest to understanding the importance of what a company is trying to deliver.
Talented testers ensure that the business delivers value and that its brand is protected, not that your work is bug-free. You built your app to add value and they can make sure that it does.
Those individuals dedicated to infrastructure alternatively can help plan for how to get your app into the shape it will need to be to handle traffic at production scale.
Worst case, they say you all did an amazing job and you get an extra-solid sleep that night.
3. Augment Engineering Work
I’ve seen apps that have been built fast and reckless. They all lack tests.
It requires extreme discipline and experience to write unit tests for code when trying to just get something out. This is even more true when pressure is applied.
A codebase without tests is a non-starter for production. Unit, integration, and scalability-related tests are essential.
More than that, don’t doubt the power of old-fashioned manual exploratory testing to uncover unique cases and bugs you wouldn’t have thought of.
However you and your team got this far, it was for the sake of adding value to your company. Don’t hurt the bottom-line or your brand’s prestige by releasing something riddled with bugs. And don’t rely on others to catch them.
4. Productionize Environments
Depending on the speed you built you prototype at, it might just be running on an old iMac kept under someone’s desk.
But it’s 2020. Go back and make sure your app infrastructure is abstracted into code. Set up a build system and get yourself, at a minimum, a staging and production environment.
5. Plan the Launch
Even if you built your app directly to prod and just prayed no one found it (or thought it would be easier to apologize than ask for permission), have a meeting to plan your release.
This is even more important if it was already done. Getting the team together to walk through what a solid release would look like lets you see the delta from what you should have done, to what you did.
If you haven’t released yet, it sets up to plan not just the technical part, but the communications as well.
I suggest re-releasing your product/feature if you go through this after the fact. It may sound superficial but I promise it will give a greater sense of resolution.
Deviating from the norm is a must for innovation. This is especially true within larger organizations.
Sometimes, history and prestige slow down delivery. But just because you broke from tradition to do the extraordinary doesn’t mean you need to abandon greatness when it comes to delivery.