Build Infrastructure, Not Features
Ask 'what has to be true so anyone could build this in an hour?' and build that instead.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
A product-engineering decision model that sorts every build into experiment, feature, or infrastructure, and biases toward infrastructure. Instead of shipping a point solution, you build the platform layer beneath it so that the specific feature (and countless unforeseen ones) becomes trivial for anyone to build later. It's slower today and vastly faster forever after.
Origin
Toby Lutke's operating principle at Shopify, relayed by Thawar. Toby reframes 'you could write this in a day' as 'what has to be true so you could write this in a day,' and calls building the platform layer 'putting gas in the tank.' Toby even writes client code against APIs that don't exist yet, then implements the server to match.
Core principles
- 01Sort every build into one of three buckets: experiment, feature, or infrastructure.
- 02A feature exploits existing infra; if it's not cheap to build, the right infra doesn't exist yet.
- 03Building infra takes longer today (months vs weeks) but lets everyone build on top of it quickly forever after.
- 04You can't predict what people will build on a platform, so the platform's optionality is the value.
- 05'Putting gas in the tank': infra is fuel others drive on for a long time.
How to run it
- 1
Classify the build as experiment, feature, or infrastructure
Before building, bucket the work. An experiment is a learning probe. A feature takes advantage of existing infra. Infrastructure is the platform layer others build on. The bucket determines your time horizon and approach.
- 2
Reframe the ask as 'what has to be true'
When someone says 'you could write this in a day,' interpret it as 'what has to be true so that you could write this in a day, and what infrastructure do you need?' The real question is the platform beneath the feature.
Pro tip Toby writes code against an API that doesn't exist yet, refines the ideal client interface, decides it's correct, then implements the server to match. Design the desired interface first, build the substrate to satisfy it.
- 3
Choose the platform layer over the point solution
When asked how long a specific feature takes vs a platform that lets anyone build that feature in one hour, build the platform even though it takes 2-3 months instead of 2-3 weeks. You don't know what use cases will emerge on top.
Pro tip Estimate both paths explicitly (feature: 2-3 weeks; platform enabling anyone to do it in an hour: 2-3 months) so the trade-off is visible.
Watch out This is genuinely slower today; you must be willing to accept a 2-3 month cost for compounding future speed, and resist shipping the quick point solution.
- 4
Force more options before committing
When you arrive with 'we can do A or B,' expect the answer 'go back and generate more options.' Toby's principle: there are ~10,000 right options and everyone stops at the first; spend your time finding the optimal one among them.
Pro tip A or B is just two of ten thousand options; don't stop at the first right one.
In the wild
During the crypto boom, merchants demanded NFT gating (buyers need a token to see products/prices and check out). Thawar estimated 2-3 weeks to build the feature directly. Toby asked how long to build a platform layer exposing APIs so anyone could build NFT gating in one hour; Thawar guessed 2-3 months. Toby said do that, because you don't know what people will build on top.
→ By building the infrastructure layer ('putting gas in the tank'), Shopify enabled many more emergent use cases beyond the single NFT-gating request, at the cost of a few extra months.
Shopify runs a 'delete code club' and hack days two or three times a year with a team dedicated to deleting code, even with a manual on how to find deletion candidates. They can almost always find a million-plus lines to delete. Thawar tweeted that the impressive metric isn't Copilot writing a million lines but AI deleting a million lines.
→ A simpler codebase makes resiliency, performance, reliability, and maintainability 'much much easier'; Thawar wants Shopify off the top-10 Ruby codebases list, aiming for number 100, not number 1.
Common mistakes
Shipping the point solution because it's faster now
Building just the feature (2-3 weeks) feels efficient, but it locks you out of the unforeseen use cases a platform would have unlocked. The infra path costs months today but compounds speed forever; skipping it is a false economy for platform businesses.
Stopping at the first right option (A or B)
Thawar arrives with two options and Toby sends him back to generate more, because there are thousands of right options and the first one is rarely optimal. Presenting a binary choice under-explores the solution space.
Measuring engineering by lines of code written
Celebrating that Copilot wrote a million lines (or that '25% of code is now written by AI') ignores that code is a liability. The right question is how much was deleted; volume is not value, elegance is.
Is it for you?
Best for
Platform companies and engineering leaders deciding whether to serve a specific merchant/customer request directly or build the reusable layer beneath it.
Not ideal for
True experiments meant only to learn, and situations where you genuinely need a point solution in market fast and optionality has little value.
From the transcript
“how long would it take to build build like a platform layer which exposes apis so anyone could build nft gating in one hour”
“what has to be true so that you could write this in a day what infrastructure do you need”
“he calls it putting gas in the tank if you put the gas in the tank people could drive on that gas for a long…”
“are you building an experiment a feature or infrastructure”
“there's probably 10,000 right options but everybody stops at the first one”
From the episode
How Shopify builds a high-intensity culture
Farhan Thawar (VP and Head of Eng)