Should you take longer to get the architecture exactly right, or just ship it fast? It depends! The right way to think about this is to divide software work into three types:

1. Experiment
2. Feature
3. Platform

These three things should be approached very differently. This concept was articulated well at Shopify by CTO Jean-Michel Lemieux, and by Tobi.

Experiments

Experiments are for learning something. They might become a permanent feature, or the basis of a feature, but they are at least as likely to be thrown away. Shipping and iterating quickly is the priority above all else. Let the code be a mess if it’s faster, you can plan to rewrite it if you keep it.

Features

Features are the reason people use your product. They’re the things that provide direct business value, and your goal is to ship new features as quickly as possible, while also having them be low-cost to maintain over the lifetime of your product.

This is obvious. What’s not clear is how. There always seems to be tension between shipping something quickly and making the code more maintainable.

The resolution to this dilemma is knowing what’s a feature and what’s a platform.

When built on top of the right platform features become more simple and lightweight, and the internals of the feature itself matter less.

Platforms

A platform is the part of your software that features are built upon. The abstractions that make features easy. Building on the right abstractions can be a huge accelerant, and building on the wrong abstractions can slow you down. Every engineer knows this intuitively.

The platform exists solely to allow you to build features as quickly as possible. Getting it right has huge leverage, it can provide compounding returns for years, and as such it’s worth a large investment.

Seeing engineers spending a large amount of effort on “the infrastructure” can be worrying if you don’t know how to measure the result.

Here’s how to measure it: the success of the platform investment is measured by the speed at which features can be built on it (and the efficiency with which they can be maintained).

If feature work doesn’t become fast, the platform work was a waste.

How much should you invest in the platform? The answer is whatever amount it’s worth to be able to build future features that much faster. For a startup still seeking product market fit, this may be very little. But for a company with a valuable product this could be worth a large investment.

How much was it worth to Meta to be able to launch Threads in only 5 months total? That’s fast by any standard but especially at that scale (100 million downloads in the first 5 days).

The threads team was very lean by Meta’s standards, but they were able to build so quickly by leveraging platforms that already existed: the Instagram infrastructure.

We relied heavily on our internal tooling and frameworks. We leveraged several things from other internal teams, like:

• UI frameworks
• APIs
• Login, privacy, security, integrity infrastructure
• Server infrastructure
• … and much more!

— Meta engineers, from The Pragmatic Engineer

The value of being able to ship a product like that in 5 months probably couldn’t have been quantified in advance while those platforms were being created previously as part of Instagram’s development.

Patrick Collison shows that Stripe understands the value of platforms:

for Stripe, people are on some level purchasing our architecture or purchasing their ability to do certain things and some set of things rather than some different set of things because of what our architecture makes easy and makes possible. … When you get API design and architecture right, it can be so enduring over literally multiple decades and even the face of what are otherwise frenzied evolutions in everything around it. And Unix of course, is another example of this where, yes, Unix has tons of shortcomings, but the architecture has basically worked for now more than around half a century. And so we’re also trying to impress upon people at Stripe the importance of multi-decadal abstractions. And I think people sometimes respond to that thinking that that’s some insanely lofty, implausibly ambitious, I don’t know, hyperbola. But no, I think that’s actually just what happens when you get this stuff right.

And if in fact you get it right, you can just reap these, or really the people building on your platform, can reap these incredible benefits for a very long time.

— Patrick Collison on the Dwarkesh Patel podcast

So, what if you got it wrong? If feature development work is going slowly, perhaps it’s on top of the wrong platform. The wrong abstractions. In that case, Sandi Metz has advice on how to back out of the wrong abstraction, by reintroducing duplication, because “duplication is far cheaper than the wrong abstraction”.

So invest in the platform that makes features simple, and then ship features quickly without trying to perfect their internals.