A platform must ship a major capability quickly. Which architectural shortcuts are acceptable, and which create debt that compounds?
Show the full answer Hide the answer
The discriminator
Reversibility. A shortcut in something easy to change later is a legitimate trade. A shortcut in something hard to change compounds, because every subsequent decision is built on it.
Acceptable shortcuts
- Unoptimised implementation. Slow code in a service with a clean interface is a contained problem, fixed later without anyone else knowing.
- Manual operational processes. A human step is acceptable at low volume and automatable later, provided it is documented and its scaling limit is known.
- Missing non-critical features — bulk operations, advanced configuration, edge cases — deliberately deferred and written down.
- Simple infrastructure. A single instance, a shared database, no autoscaling. Easy to change and correct at low volume.
- Deferred internal tooling, where the cost is engineering inconvenience rather than customer impact.
Shortcuts that compound
- Data model and schema. Once data exists in a shape, changing it means migration, and once other systems depend on it, migration means coordination. This is the least reversible decision in most systems.
- Public interfaces. An API shipped to customers or partners is a contract you cannot unilaterally change. Getting the shape wrong is permanent in a way internal code is not.
- Identity and tenancy model. How users, accounts, organisations and permissions relate. Retrofitting multi-tenancy or an organisation layer is a rebuild.
- Missing auditability. A property of every write path, and retrofitting means touching all of them plus backfilling attribution that no longer exists.
- Skipping idempotency on operations with irreversible effects, which produces duplicate charges and duplicate sends that are discovered by customers.
- Security shortcuts on data handling, where the consequence is not debt but exposure.
How to take a shortcut well
Name it, date it, own it. A decision record stating what was skipped, why, what it costs, and the trigger for revisiting. Undocumented shortcuts become the architecture by default, because nobody remembers they were temporary.
Contain it behind an interface, so the shortcut is replaceable without touching callers.
Instrument the trigger. "We will revisit when volume exceeds N" is only meaningful if N is on a dashboard with an alert.
The framing for the conversation
Speed is a legitimate architectural driver, and treating every shortcut as debt to be resisted is unrealistic. The question is not whether to take shortcuts but which ones — and the answer follows the reversibility of each, which is a technical judgement the architect is uniquely placed to make.