Simple does not mean small at any cost. It means understandable enough to change, and capable enough to do the job. A static site is a strong choice for publishing; it is not a substitute for a transactional system merely because it is inexpensive.
Begin with what can be known in advance
Ask when each piece of information changes:
| Information | Reasonable starting point |
|---|---|
| An article or product explanation | Build-time content |
| A public index of articles | Generated JSON |
| A visitor’s search query | Browser-side computation |
| A private account balance | Authenticated runtime service |
Move computation to build time only when the information and freshness requirements permit it. Static-first is a bias, not a prohibition on servers.
Make each layer answer a question
Before adding a service, record:
- Which requirement cannot be met without it?
- What state will it own?
- What happens when it is unavailable?
- Who updates it, and how will we remove it?
A dependency can save effort. It can also move effort into upgrades, monitoring, security, and operational knowledge. Include those costs in the decision.
Compare whole systems
A zero-cost hosting plan is not automatically the cheapest architecture. Include build time, authoring friction, incident recovery, and human maintenance. Likewise, a familiar database may be simpler for your team than an elaborate file workaround.
Choose the smallest design that satisfies the actual constraints. Record what would make you change your mind: update frequency, graph size, response time, or an access-control requirement.
Leave a decision record
Decision:
Requirement it serves:
Alternatives considered:
Accepted costs:
Evidence that would trigger a revision:
Try it: pick one layer in your proposed stack. Remove it on paper. Describe exactly what stops working. If nothing important stops working, defer the layer.