Budget and Legal Constraints
The two constraints engineers most often leave to someone else and most often get surprised by. Budget decides how many pieces the system may run and how; law decides what may be stored, where, for how long and who may see it. Both are design inputs, and both are cheapest when found before the schema exists.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
What do the money and the law require of this system, who owns those answers, and how do you get them into the design before the design makes them expensive?
The store's design is nearly done. Someone asks what the hosting will cost per month and you do not know; someone else asks whether storing customer addresses is fine "under the data rules" and you do not know that either. Both questions feel like somebody else's job, and both are about to be decided by the schema you drew yesterday.
Defer both. Budget will be whatever the cloud bill says, and it is small at first; legal is a review before launch, and the compliance person will tell you what to change. Both feel like non-engineering concerns that will resolve themselves when the relevant people look.
The cloud bill is small at first and then it is not, and by then the architecture has six managed services because each one was the easy choice in the moment; the bill exceeds the store's margin and there is no single thing to remove.
- The cloud bill is small at first and then it is not, and by then the architecture has six managed services because each one was the easy choice in the moment; the bill exceeds the store's margin and there is no single thing to remove.
- The pre-launch review finds that card data passes through our server, that addresses are replicated to a region they may not be in, and that there is no way to delete a customer — each of which is a schema change, a deployment change and a code change, in the week before launch.
- Because nobody owned either question, each was answered by default: the default region, the default retention (forever), the default logging (everything, including the address), the default tier (whatever the console suggested).
- The engineer who deferred both cannot answer either when asked, and the asking happens in front of the founder.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat budget as a constraint with a number, an owner and a shape. The number is what the business can spend to build and to run per month before revenue; the owner is whoever pays; the shape is fixed versus variable — a managed database is a fixed monthly cost, object storage and outbound traffic grow with use. Cost each piece of the design at its smallest viable tier, sum it, and put the sum in front of the owner before building. A design that cannot be costed is not finished.
- Treat law as a set of obligations attached to specific data, not as a review phase. For each kind of data the store holds — card details, addresses, emails, order history, logs that mention any of these — ask: may we store it, where, for how long, who may see it, must we be able to delete or export it, and who is liable if we get it wrong. The answers come from the actual rules that apply to this jurisdiction and this kind of business, read by you and confirmed by whoever owns legal; they are not guessed and not inferred from what other stores do.
- Convert each obligation into a design decision now, while it is a column or a configuration rather than a migration: card data never on our servers (hosted fields); addresses stored in the permitted region only; a deletion path that actually removes or anonymises a customer across every table and every log; retention periods on logs and on carts; personal data kept out of log lines. Each of these is cheap at design time and expensive at launch minus a week.
- Where budget and law pull against each other — the compliant region costs more; the audit log is another store to pay for — make the trade-off visible to the owner rather than resolving it silently. The engineer's job is to cost the options and name the obligation, not to decide that compliance is too expensive.
Where each constraint bites
The table is the failure shape for both constraints: something decided by default, visible only when the bill or the review arrives. The cause column is the same in every row — nobody owned the question, so the default answered it — and the response is always a design decision that was cheap earlier.
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| Traffic grows modestly | The hosting bill exceeds the store's margin | Six managed services, each the easy choice in the moment, none costed against a ceiling | Cost the design at design time; remove the pieces a database index or a scheduled query replaces |
| A customer asks to be deleted | Nobody can do it; addresses survive in orders, carts, backups and log lines | Deletion was never a requirement because the rules were never read | A tested deletion path across every table and log; anonymise where retention rules forbid deleting the order |
| The pre-launch review reads the deployment | Personal data is replicated to a region it may not be in | The default region was accepted; the obligation attached to addresses was unknown | Region decided by the obligation, costed, chosen by the owner |
| A support engineer searches the logs | Shipping addresses and emails appear in plain text in every request log | The default logging captured everything; nobody asked what a log line may contain | Personal data out of log lines; retention on the logs themselves |
| The card-data question is asked | Card numbers passed through our server on the way to the provider | The integration copied an example that posted the card to our API first | Hosted fields; card data never on our servers — a design property, not a review finding |
Obligations as testable leaves
Legal obligations decompose like any other requirement, and the leaves have to be testable or they are a policy document rather than a design. The tree is the store's obligations as they went into the schema, the deployment and the code — every leaf is something a test or an inspection could check.
- ├Card data— the largest liability
- └Never on our serverstestable No request log, database column or backup contains a card number; the checkout page posts card fields to the provider, not to our API.
- ├Personal data (addresses, emails)— the data-protection rules attach here
- └Stored in the permitted region onlytestable The database, its backups and object storage are all in the permitted region; the deployment configuration is inspected, not assumed.
- └Deletable on requesttestable Deleting a test customer removes or anonymises them across customers, orders, carts, emails sent and log lines; a search afterwards finds nothing.
- └Absent from logstestable A request that includes an address produces a log line without it; a log search for a test address returns nothing.
- ├Order history— the tax rules require keeping it
- └Kept for the required period, anonymised not deletedtestable After a customer deletion the order rows remain with the customer reference anonymised and the amounts intact.
- ├Logs and carts— retention is an obligation too
- └Retention enforcedtestable Log lines and abandoned carts older than the set period are gone; the job that removes them is observed running.
The tree is short because the store holds little. The point is that every leaf is a check, and every check was cheap when it was a column and expensive when it was a migration.
Money against law: whose decision
The decision is what to do when a costed option and an obligation disagree. The engineer's options are about how the disagreement reaches the owner, not about which side wins — that is the owner's call, and the design record has to show it was theirs.
How does this reach the person who owns the decision?
when The obligation is clear and the cost difference is real — a compliant region, a separate audit store — and the owner needs to see the trade to make it.
cost A conversation, and an owner who now knows the number; the gain is a recorded decision that is theirs.
when The obligation is hard and unambiguous — card data never on our servers — and the "cheaper" option is not an option at all.
cost The cost is simply incurred; the design record says why, so the next budget review does not reopen it.
when The obligation can be met a cheaper way — anonymise rather than delete, a retention job rather than a separate store — and engineering can find it before the trade is presented.
cost Design time; the gain is that the owner is offered a compliant option they can afford, which is the engineer's real job here.
How to do it
Most important first.
- Cost the design: list every piece, its smallest viable tier, fixed or variable, and the monthly total. Put the total beside the budget number and the name of who confirmed the budget (Integration and Operating Cost).
- List the kinds of data the store holds — including what ends up in logs and backups — and for each write: store? where? how long? who sees? delete/export? liability? Get the actual rules, not a summary of them (What Must Persist).
- Turn each legal answer into a concrete decision in the schema, the deployment or the code, and write the obligation next to it so a future engineer knows why the column has a retention date.
- Test the deletion path the way you would test checkout: create a customer, order, refund and log line, delete the customer, and check every table and every log (Invariants as Tests).
- Where money and law conflict, write the options with costs and take them to the owner — a decision, not a default.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, costed. One application server at a small tier, fixed; one managed database at the smallest tier with backups, fixed; object storage for images, variable and tiny at launch; outbound email, variable per message; the payment provider's fees, variable per order and outside the hosting budget. The total sat under the founder's ceiling with room; the number and the ceiling went on the canvas with the founder's name beside them. The one thing removed by the costing: a managed search service that had crept into the design for "filter by name" over a few hundred products — its fixed cost was a quarter of the budget for a problem a database index solves.
- The store's data, under the law. Card details: never stored — the contracted provider's hosted fields, which also settled the biggest liability. Addresses and emails: personal data; stored in the permitted region only, which fixed the deployment region and ruled out a cheaper one; deletable on request, which required a deletion path across customers, orders, carts and — the surprise — the log lines that had been printing the shipping address. Order history: kept for the period the tax rules require, which is longer than the customer may want, so deletion anonymises the customer and keeps the order. Logs: retention set, addresses removed from log lines.
- The conflict. The permitted region's managed database cost more than the default region's. The options went to the founder as two numbers and one obligation; the founder chose the compliant region, as they would — but it was their decision and it was recorded, not an engineer's silent choice either way.
- The file-upload service version: budget is dominated by storage and outbound traffic, both variable, so the costing produces a per-upload cost and a ceiling on file size; the law adds a retention obligation, a question about what the uploads may contain, and a scanning step. Both arrived before the first bucket was created — which is the only time they are cheap.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The design has a monthly cost, itemised, next to a budget number with an owner's name, and at least one piece was removed or downsized because of it.
- Every kind of personal or financial data the store holds has a written obligation — where, how long, who sees, delete — and each obligation points at a specific column, region or configuration.
- The deletion path exists and has been tested across every table and log, before launch.
- At least one budget-versus-law conflict was written as options and decided by the owner.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What does this design cost per month at its smallest viable tiers, fixed and variable, and who confirmed the number it must fit under?
- ?For each kind of data we hold — including logs and backups — may we store it, where, for how long, who may see it, and can we delete it?
- ?Which of those obligations is a column, a region or a configuration today, and would be a migration next month?
- ?Where do money and law conflict here, and have I put the options in front of the person who owns the decision?
What can go wrong
- Costing becomes penny-optimisation. A week spent choosing between two small tiers of the same service, when the number that mattered was the order of magnitude against the ceiling.
- Legal becomes paralysis. Every data field is treated as a liability, the store stores nothing useful, and the founder cannot see who bought what. The obligations attach to specific data and have specific answers; most data has none.
- The engineer reads the rules and decides they are the lawyer. Reading the rules is the move; confirming the interpretation with whoever owns legal for the business is the other half, and skipping it moves the liability to the engineer.
- Both constraints are handled once and never revisited. The budget grows with revenue and the design stays starved; a second jurisdiction appears and the region decision is silently wrong.
- Costing and reading the rules before designing is a day or two of non-engineering work by an engineer, and it produces conversations with finance and legal that many teams would rather have later.
- Designing for obligations you have read about yourself risks over- or under-reading them; the confirmation step costs time and sometimes overturns a decision.
- The compliant choice is often the more expensive one, and putting that in front of the owner as a number makes the trade visible — which some owners would rather not see.
- "Budget is an operations concern." The number of managed services in the design is an architectural decision, and it is the one that sets the bill. Operations can tune a tier; only design can remove a piece.
- "Legal is a checkbox before launch." A deletion path across every table and every log is not a checkbox; it is a design property, and it is the difference between a column with a retention date and a migration in launch week.
- "Security and legal are the same list." They overlap — card data — and differ: an audit log is a security control that the law may also require, and an address retention limit is a legal obligation that security does not care about. Ask both questions (Non-Functional Requirements).
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- DOMAIN-SPECIFICA store holds addresses, emails and order history and touches card data through a provider; a chat app holds messages, which carry their own retention and disclosure rules; an AI assistant over company documents holds whatever the documents hold, which may include everything. The five questions per data kind are the same; the answers and the applicable rules are entirely different, and must be read for the actual domain and jurisdiction.
- SCALE-SPECIFICAt launch the budget is dominated by fixed costs and the move is about removing pieces; once traffic exists the variable costs — storage, egress, per-message fees — grow with use, and the same move becomes per-unit costing against margin.
- ILLUSTRATIVEThe hosting ceiling, the region cost difference, the tax-retention period and the address in the log line are invented to show the shape of both constraints; no jurisdiction's actual rules are being stated, and the real ones must be read.
Where the depth lives
This domain asks the question and hands the answer off by name.