Make It Work, Make It Right, Make It Fast
Throughout my career, I’ve often heard variations of the phrase "Make it Work, Make it Right, Make it Fast." as being an approach for building software. On a surface level, I understood its meaning, but as my experience grew, I began to appreciate the deeper layers behind this approach.
Here’s how I break down the meaning of each part of this phrase:
Make It Work
The first priority when building software or implementing a new feature is to quickly validate that your theory holds. Establishing functionality early helps identify issues that can only surface through practical implementation and often reveals additional requirements for a comprehensive solution.
On a product level - Let’s say you come up with a new idea for a social media application for pet owners. Initially, you might imagine building numerous features to make the app perfect. But unless you’re working on a high-stakes or costly project, like health or space technology, the best approach is often to test your concept with users as soon as possible. This typically takes the form of a Minimum Viable Product (MVP).
A personal experience highlights this. A few years ago, I was working with friends on a startup to revolutionize e-commerce for small businesses in Nigeria. After a few pivots, we settled on building a platform with shipping integrations to help businesses scale. We spent nearly three years developing it, only to realize too late that we hadn’t tested our ideas with real users. At one point, after receiving feedback from a YC application, we built a simple MVP with Google Forms, Notion, and Zapier, and gained our first users within 48 hours. This revealed several issues that would have affected our full-scale platform with over 12 microservices. Though the startup didn’t ultimately succeed, this was a valuable learning experience.
Releasing an MVP should not mean releasing an unfinished product as MVPs should retain core functionality to test the main idea while omitting non-essential features.
For already established products, this principle still applies. Using techniques like A/B testing* to experiment with customers or breaking down large features into smaller, quickly shippable parts can accelerate feedback and validate assumptions.
*A/B testing is a method of comparing two versions of a product or feature (A and B) to determine which performs better based on specific metrics or user responses.
On a feature implementation level - When coding, it’s easy to get caught up in writing clean code from the start. Often, however, the most effective approach is to focus on getting the code to work, even if it’s repetitive or involves temporary hacks. You can then assess how to modularize and optimize it. I’ve often found that initial attempts to abstract functions end up adding unnecessary complexity.
“If you are not embarrassed by the first version of your product, you’ve launched too late” - Reid Hoffman
Make It Right
Once the MVP or first draft is live, it’s time to refine things. "Making it right" can mean various things: adding features that enhance usability, refactoring code, or expanding test coverage. Improving based on real-world insights is far more effective than making adjustments based on assumptions.
For products, feedback from an MVP or insights from an A/B test reveals what really needs attention. For feature implementation, it’s easier to identify improvement areas when a solution is already working. When solving Data Structure and Algorithm (DSA) problems, for instance, trying to find an optimal solution right away can lead to overly complex designs. Often, starting with a brute-force solution clarifies what optimizations are truly needed.
Iterating to make things right is rarely a one-time process. Building software is an iterative journey, where making improvements involves weighing trade-offs. As the saying goes, "It depends." Deciding what to fix or enhance at any stage should balance impact and resource constraints.
Make It Fast
The first car built by Karl Benz in 1885 had a top speed of about 10 miles per hour (16 km/h). By contrast, today’s Formula 1 cars reach up to 230 mph (370 km/h) on certain tracks. This is obviously not a very fair comparison as the speed of the first car made also reflects the limits of early automotive engineering, but the point here is highlighting the importance of having to show that building the automobile in the first place was more important.
Once things work well enough, it’s time to ask:
How much faster can we make the system?
Can we achieve the same results with fewer resources?
Are there unnecessary steps we can eliminate?
What are the system’s limits, and how far can we push them?
How much scale can the platform handle before it breaks?
Improving performance can address immediate issues or prepare for anticipated growth. It can also spark innovation by pushing boundaries and revealing unforeseen limitations.
Do these steps always work?
These insights are based on my six years of professional experience in building and using software, with plenty learned from both successes and mistakes. Not every scenario is the same, but this approach has served as a valuable guide.
“Make it Work, Make it Right, Make it Fast” as I see it, embraces iteration, real-world testing, and continuous improvement. This approach enables adaptability, learning quickly from users and code, and ongoing refinement. By focusing first on functionality, then on quality, and finally on speed, we create products and solutions that grow sustainably and deliver impact at every stage.