Build it once, use it everywhere

Early on, it's tempting to build exactly what the customer in front of you is asking for, because it's the quickest way to a signature. But work built for one partner usually ends up thrown away.

Building generic features, such as reusable inventory, configurable item types and a checkout that supports multiple gateways and currencies from day one, costs a little more up front and pays back for years. It gives the next ten features something to build on.

One of the rules we put in place is a hard one: everything you build must work for every customer, and no single client owns any part of it.

Turning down bespoke work is difficult, because there's always a deal that seems to depend on it. But every bespoke feature has to be maintained forever, adds complexity and slowly drags down your velocity.

Gift vouchers, account balances, split and deposit payments, wallets, stored currencies and resale can all sit on the same foundation in a well-designed platform.

A bespoke feature helps one customer once. A reusable capability helps every customer and gives the next capability something to build on. For a while you barely notice the difference, and then it becomes a real advantage.

The test is simple. If only one customer could ever use it, it's bespoke. If it would serve a whole group of customers, it's a foundation.

Most "special cases" turn out to be general cases. Before you build the one-off, stop and ask what the reusable version would look like. There almost always is one.

Teams that stick to this find their delivery speeds up over time. New features get cheaper because most of what they need already exists, and onboarding a new partner becomes a matter of configuration instead of new development.

This is a big part of what makes product-led growth work: a platform where every improvement benefits every customer and each new customer costs less to serve than the last.