Why "We'll Add That Later" Costs More Than You Think

Deferring a feature is usually the right call. The mistake is treating all deferrals as equally cheap, when a few of them quietly double the cost of everything built in the meantime.

The test is simple. Does the feature add a view over data you already have, or does it change the shape of the data itself?

The cheap kind

Reports, dashboards, exports, extra filters, a redesigned interface, another notification. These read data that already exists. Building one later costs roughly what it would have cost earlier, and often less, because by then you know which report people actually want.

Defer these freely. This is most of what an interface is, and most of what gets cut from a first release for good reason.

The expensive kind

Five things change the shape of your data, and each one is materially harder to add later than to allow for at the start.

More than one user per account. A system built for one login per business has that assumption in every table with an owner. Adding teams later means introducing an organisation, re-parenting every record, and revisiting every query that assumed one user meant one business.

More than one currency. Amounts stored as plain numbers carry an invisible assumption. Adding a second currency means every stored amount needs a currency, every comparison needs a rate, and historical rows need a decision about what they meant.

More than one language. Translatable content in single columns has to become either separate columns per language or a translations table, and everything reading those columns changes with it.

Audit history. If you need to know who changed a record and when, that has to be captured as changes happen. It cannot be reconstructed. Adding it later gives you history from that date forward and nothing before, which is often exactly the period someone is asking about.

Soft deletion. Rows deleted for real are gone. If a regulator, an accountant, or an angry customer needs to see a deleted record later, the answer is that it does not exist.

How to decide without over-building

You do not have to build these. You have to decide about them, which is cheaper.

For each of the five, ask whether it is plausible within two years. If yes, allow for it in the schema even if nothing uses it: an organisation id on records, a currency column beside every amount, a deleted_at timestamp instead of a hard delete. Each is a small amount of work now and a migration you never have to run.

If it is genuinely implausible, skip it and write down that you did. The note matters, because the expensive version of this problem is not the missing column. It is the developer two years later who has no idea the decision was ever made.

What this means for a first release

Cut features aggressively. Cut foundations carefully. A first release with three screens and a schema that anticipates a second user is in far better shape than one with twenty screens built on assumptions that have to be unpicked.

When we scope a project, these five get asked explicitly in discovery, before pricing. Not because every project needs them, but because the answer changes what the cheapest correct version looks like.