Once a product teams decides they're going to build something, the natural instinct is to start coding. Even if we use common libraries or APIs, most of the product still gets built in-house.
But sometimes the fastest way to solve customer problems, and to ship real value, is not to build anything at all. I don't see many teams seriously considering this. It's not always viable, but when it is, it dramatically cuts time to market and speeds the point and which you're delivering value to customers and the company.
This isn't about validation. Interviews, pre-selling, design sessions, all of that improves confidence before you decide to build. This is about what happens after you've committed to building the product. Even at this stage, coding it inside your existing system may not be the most effective investment.
White label another product and consider OEM
I ran the market leading product for backups on Shopify. We were many times larger than our competition and had saturated the market. Expanding the product offering made sense: we could increase ARPC and improve NDR by selling more to our existing customers.
There was an obvious adjacent product. We could already recover a store if something went wrong- so what if we could detect the problems before they required a restore?
The challenge was that it would take about two person-years to build something meaningful at our scale
Meanwhile, I'd noticed another product early in the market that solved this. Great product, no commercial founders, very early in revenue.
My proposition to them was to bundle their product, white-labeled as ours, into a suite. We'd share revenue.
It worked, with the suite generating a meaningful amount of revenue in the first year. And it avoided two years of engineering investment.
Teams often default to building even when a perfectly good solution that could be leveraged exists. White-labelling isn't glamorous for product teams, but it often beats rebuilding the same thing.
New positioning, packaging, and messaging
We had a product called 'Copy'. It copied data from one Shopify store to another. It had grown steadily, but slowly. Revenue wasn't meaningful at our scale, but also not low enough to sunset it.
Our flagship backup product had saturated its market. There was some overlap with Copy, but it wasn't obvious to customers. That they complimented each other was too subtle: with the packaging and messaging not helping. It made cross-selling and bundling slow.
Talking to our ideal Copy customers revealed something interesting. One use case: creating staging sites, had much lower churn and attracted more of our ideal customers than the other use cases. And it fit naturally into a narrative of preventing problems from reaching production, reducing the need for restores, which should always be the last resort.
So we renamed the product to Staging, refocussed our messaging and content around that use case, and remove one-off pricing in favour of subscriptions which reinforced the staging use case and filtered out one-off jobs.
Churn fell. Growth returned. Enterprise customers became interested. And Staging became a key product of our suite, raising APRC and improving NDR beyond what the backup product alone could deliver.
Sometimes you already have the right product. It just needs new positioning, packaging, and messaging. And none of that requires writing code.
Has someone else already built it?
Early in my career, as an engineering manager, our CTO handed me a spec for a desktop AdWords campaign management tool. The spec was good: Google's web-based interface was slow and error-prone for managing our considerable ad spend.
I began scoping the build. Something felt wrong. We were an online retailer. Our customer value came from selling the right apparel at the right price, shipped fast. Building a custom AdWords desktop tool distracts from helping us do that better.
And if the problems with Google's web-based tool were real, other marketers surely faced them too. Someone must have built a solution.
I found a desktop AdWords tool that was free and covered most of the spec. When I presented it to the CTO and paid ads team, I heard the response I've since heard many times: "But it can't do X."
This is a classic reflex, especially from technical teams who could build the thing themselves.
Thankfully, I had costed the internal build tool out and figured out small workarounds for the tool's gaps. The choice was a) six person-months of development for the custom tool or b) an additional couple of hours of manual work each month with the off-the-shelf tool.
We made the right decision.
This "almost perfect but not quite" objection is a trap. Teams overvalue theoretical completeness and underestimate the opportunity cost of building the missing 20%.
True MVPs outside of the existing system
It’s good engineering practice to avoid fragmentation. Teams should be cautious about introducing new technologies, and your core platform should absolutely be robust enough to support the demands of larger customers.
But that robustness comes with overhead. It will always take longer to ship a change in that system than it would for a solo developer assembling something from scratch. That’s the trade-off for having a platform that works at scale.
The problem is that this makes MVPs expensive. On a mature system, it might be impossible to get something live in under a couple of months no matter how “minimal” you try to make it. And if there’s already uncertainty over whether the thing will actually deliver business value, or whether the code will survive more than a year, then you should assume the MVP code will be thrown away. Whether the hypothesis is validated or not.
With that assumption in mind: what technologies would you choose for the MVP if you knew the code wouldn’t last?
The answer often isn’t “the core system.” You might reuse some pieces through APIs or libraries, but the principle is to not let the existing system constrain you.
We did this for one product in our suite. We compared building an alerting product inside our existing system versus using a rapid app development platform with light integration for auth and billing. The rapid app platform won easily. It got the suite into the market in six weeks.
If your platform overhead makes even MVPs slow, and you don’t yet know if the idea earns a right to exist, then the MVP should be built in whatever way gets you the learning fastest. Not whatever keeps the architecture tidy.
The goal isn't to build- it's to deliver
Once we decide to build something, the reflex is to start coding. But coding is just one way to deliver a product.
The examples above are great to consider when they're available. It's how I've been able to ship strong customer and business value faster than writing code. White-labelling instead of building. Repositioning instead of adding features. Adopting an existing tool instead of committing person-months. Building an MVP outside the core system when internal overhead makes everything slow.
Avoiding building by default opens up possibilities we often overlook. And some of those possibilities might be the best way to ship more, learn faster, and waste less.
Some of the best product decisions I’ve made came from not building the thing, and getting the value into customers’ hands anyway.