Architectural constraints disguised as product requirements.
José Sabogal, woodblock print for Amauta (1927). Cutting relief straight into the grain - what stays standing bears the weight of the ink.
In the corner of our engineering conference room during a massive multi-year platform rebuild, someone took a black dry-erase marker and wrote five short lines on the whiteboard.
No bulleted sub-clauses. No corporate mission statements. No twenty-page PRD appendices. Just five non-negotiables:
- Easy for the user.
- Self-provisioning.
- Cheap for us to run.
- Responsive, no waiting.
- Clean, aesthetically appealing.
Most requirement documents in enterprise technology fail because they are forty pages long. A forty-page document cannot be used as a filter in a design review. When a product manager proposes an unwieldy feature, nobody flips to Section 8.4 to check alignment.
A list this short exists for one purpose: to give the team permission to say no.
THE WHITEBOARD TENSION MATRIX:
[Cheap to Run] <──────────────────── (Tension) ────────────────────> [Responsive / Zero Waiting]
│ │
▼ ▼
Serverless cold starts / Pre-warmed pools /
Low-tier relational instances Distributed edge compute caches
│ │
└─────────────────────────> RESOLUTION <───────────────────────────────┘
(Architecture decided on Day 1,
not discovered as an invoice surprise)The Architectural Disguise
At first glance, these five lines read like standard product requirements. Look closer.
Three of the five—self-provisioning, cheap to run, and responsive speed—are structural architectural decisions disguised as feature requests.
If you don’t decide them on the whiteboard before writing the first schema migration, you cannot fix them later with a sprint polish:
1. Self-Provisioning Is an Architecture, Not a Button
If a customer signs up for your platform and requires an operations engineer to manually run a provisioning script, spin up a tenant, or map an SSO SAML entity ID, your software is not a SaaS platform. It is a professional services firm with a web front-end.
Self-provisioning forces you to solve tenant isolation, automated identity provisioning (SCIM), role mapping, and cryptographic domain validation on day one. It is the single constraint that quietly decides whether a product can scale to ten thousand logos without hiring a hundred support coordinators.
2. Unit Economics as a Design Input
Most engineering teams treat cloud infrastructure costs as an afterthought: build the prototype, ship to production, and let the finance team panic when the AWS bill triples six months later.
Putting “cheap for us to run” on the whiteboard makes unit economics an architectural boundary. It forces the hard trade-offs early:
- Do we really need an always-on vector database cluster, or does a local SQLite index with BM25 keyword search solve 95% of customer use cases?
- Are we caching expensive LLM embeddings at the edge, or re-generating vectors on every single page load?
Cost is not an optimization pass. Cost is a design input.
3. Responsiveness Is Perceived Speed
“Responsive, no waiting” does not mean shaving 10 milliseconds off a database query. It means designing the user experience so the human never stares at an empty spinner.
Consumer applications learned this a decade ago: optimistic UI mutations, instant client-side transitions, background synchronization, and local caching. When an enterprise platform adopts optimistic UI, users describe the software as “lightweight” even if the backend background sync takes two seconds to settle.
The Built-In Tensions
The real beauty of a five-item filter is that the rules deliberately pull against each other.
- “Cheap for us to run” pulls directly against “Responsive, no waiting.” The cheapest architecture is a throttled serverless function with three-second cold starts. The fastest architecture is an over-provisioned fleet of pre-warmed compute nodes.
When you acknowledge that tension on a whiteboard before writing a line of code, the engineering team has an honest conversation about caching, edge routing, and data structures. You design an architecture that balances the trade-offs intentionally—rather than discovering them as a production outage or an emergency budget meeting.
Honest Caveats
- Whiteboards Don’t Write Code: Five clear principles prevent architectural bloat, but they don’t replace disciplined engineering execution. If your team lacks senior technical chops to implement optimistic UI or tenant-isolated SCIM mappings cleanly, simple rules will just highlight the skill gap.
- Simplicity Requires Say-No Discipline: Stakeholders from sales and customer success will constantly ask for custom one-off exceptions (“just this one manual provisioning workflow for a big logo”). The moment you say yes to the exception, the whiteboard principle dies.
Keep the rules short enough to remember. If you can’t fit your platform principles on a small conference room whiteboard, you don’t have principles. You just have a wish list.