Interaction and delivery needs
Content depth, device context, offline needs, accessibility, real-time interaction and search visibility change the frontend approach.
Architecture / Requirements before technology
Choose a stack the product can live with.
Evaluate frontend, backend, data, integrations and operations as one system. Hich Web frames technology choices around the product's workflow, risk, ownership and expected change—not a universal list of fashionable tools.
/ Decision guide
Product systemBuild / Run / Change
ExperienceFront end
LogicBack end
StateData
OperatePlatform
01 / FitRequirements lead selection
02 / SimplicityComplexity needs a reason
03 / OwnershipOperations shape architecture
04 / ChangeDecisions stay reviewable
Direct answer
How should a technology stack be chosen?
Choose a technology stack by first defining the users, workflows, data, integration boundaries, expected load, availability needs, change rate, security responsibilities, team skills, budget and operating model. Compare a small set of viable architectures against those requirements, test high-risk assumptions and record the tradeoff. A good stack is one the team can build, run, monitor and change responsibly—not simply the option with the most tools.
01 / Selection inputs
Start with the forces the system must handle.
These inputs narrow the options. Estimates should include their source and uncertainty instead of being treated as fixed facts.
Workflows and rules
Roles, approvals, calculations, exceptions and audit needs reveal where logic belongs and how modules should be separated.
Shape, sensitivity and lifecycle
Relationships, volume, consistency, retention, residency, recovery and reporting needs affect storage and processing choices.
Who will own the system?
Team capability, release frequency, service hours, vendor constraints, support model and budget determine sustainable complexity.
02 / Architecture layers
Treat the stack as connected responsibilities.
Technology names come after the responsibility of each layer is understood. Options listed here are categories, not a claim that every project uses every pattern.
Frontend delivery
Choose how pages and interactions reach browsers or devices and what should work before client-side code.
- Semantic HTML and CSS foundations
- Static, server-rendered or client-rendered views
- Component and state needs
Backend and domain logic
Place workflows, permissions, validation and business rules in boundaries the team can understand and test.
- Runtime and framework fit
- Module or service boundaries
- Background jobs and scheduling
Data architecture
Select storage by access patterns, relationships, consistency, search, reporting and lifecycle requirements.
- Relational, document or specialised stores
- Schema and migration approach
- Backup and recovery requirements
Integration boundaries
Define how systems exchange data, authenticate, retry failures and reconcile inconsistent states.
- APIs, webhooks, files or events
- Contracts and versioning
- Idempotency and failure handling
Deployment platform
Match managed hosting, serverless functions, containers or virtual infrastructure to control and operating needs.
- Environment strategy
- Build and release pipeline
- Scaling and regional needs
Identity and access
Model people, services, roles, sessions and privileged actions before choosing authentication components.
- Authentication and session model
- Authorisation boundaries
- Administrative access
Security controls
Translate threats and data obligations into implementation, configuration and operational requirements.
- Secrets and encryption needs
- Input and dependency controls
- Logging without sensitive leakage
Observability and support
Decide what must be visible when the product slows, fails or behaves unexpectedly.
- Logs, metrics and traces as needed
- Health checks and alerts
- Incident and change records
Quality strategy
Balance automated and manual checks around the most important behaviours and failure modes.
- Unit, integration and journey checks
- Accessibility and browser coverage
- Performance and resilience tests
03 / Pattern comparison
Choose architecture by justified boundaries.
These are broad patterns. A real solution may combine them, and suitability depends on the product, team and operating environment.
| Pattern | Can fit when | Useful strengths | Tradeoffs to examine |
|---|---|---|---|
| Static or pre-rendered site | Content changes through a controlled publishing workflow and dynamic behaviour is limited or external. | Small runtime surface, cacheable delivery and straightforward hosting. | Editorial workflow, preview, builds, forms and dynamic personalisation need deliberate solutions. |
| Server-rendered application | Pages combine dynamic data with strong initial delivery, navigation or search needs. | Centralised data access, useful first response and progressive enhancement options. | Server capacity, caching, session handling and deployment ownership must be managed. |
| Client-rich application | Complex, repeated interaction or local state is central to the experience. | Responsive in-app transitions and reusable stateful interface patterns. | JavaScript cost, loading and error states, accessibility, indexing and API dependence require care. |
| Modular monolith | One product team needs clear domain modules without independent distributed services. | Simpler deployment and transactions while preserving boundaries inside the codebase. | Poor internal discipline can create coupling; scaling and release remain shared. |
| Independent services | Domains, teams, scaling or release cycles have genuinely separate ownership. | Independent operation and change where boundaries are stable and justified. | Network failure, data consistency, deployment, testing and observability complexity increase. |
| Managed platform or SaaS integration | A non-differentiating capability can be responsibly delegated to a suitable provider. | Less custom surface to build and potentially faster access to mature functionality. | Recurring cost, data location, limits, extensibility, vendor change and exit strategy matter. |
04 / Common tradeoffs
Ask what changes when one option wins.
A comparison should include delivery, operations and exit cost—not only the developer experience on day one.
| Choice area | Option A may favour | Option B may favour | Questions that decide |
|---|---|---|---|
| Minimal JavaScript vs interface framework | Content-led pages, simple interaction and lower client complexity. | Complex state, repeated interactive components and app-like workflows. | What must update without navigation? What works if scripts fail? How much state exists? |
| Integrated CMS vs headless CMS | Connected editing, preview and page delivery in one system. | Structured content shared across channels and independently delivered interfaces. | How many channels, editors and deployments exist? Who owns the integration? |
| Relational vs document data | Strong relationships, constraints, transactions and flexible querying. | Document-shaped records and access patterns suited to that model. | Which consistency and query needs are real? How will schemas evolve and report? |
| Synchronous API vs asynchronous event | Immediate response and a simpler request path. | Decoupled processing, buffering and workflows that tolerate delay. | Must the result be immediate? How are retries, ordering and reconciliation handled? |
| Managed runtime vs self-managed infrastructure | Delegated platform operations and a smaller operational surface. | More control over runtime, networking or specialised requirements. | Which controls are required? Who patches, monitors and responds outside office hours? |
05 / Decision process
Reduce uncertainty in the right order.
The sequence can scale from a focused review to a larger architecture engagement. Each stage creates evidence or a decision another team can inspect.
Define requirements
Record product behaviours, service expectations, constraints, quality attributes and which estimates remain uncertain.
Find boundaries
Model users, systems, data flows, trust boundaries, dependencies and operational ownership.
Shortlist options
Evaluate a small number of credible approaches using the same weighted requirements and consequences.
Probe the risky assumption
Use a spike, prototype, load model, vendor review or security analysis according to the uncertainty.
Choose and set a review trigger
Document why the option fits now, what it makes harder and which future condition should reopen the choice.
06 / Security, reliability and operations
A stack is not finished when it deploys.
Security, compliance and reliability are outcomes of continuing engineering and operations. The controls below must be tailored to the product, applicable obligations and risk assessment; they are not guarantees.
Threat and trust model
Identify actors, assets, entry points and trust boundaries, then prioritise plausible misuse and failure cases.
- Data classification inputs
- Abuse and threat scenarios
- Control ownership
Access lifecycle
Plan invitation, verification, role changes, recovery, privileged actions and removal.
- Least-privilege roles
- Session and credential handling
- Administrative review
Software supply chain
Track dependencies, sources, build permissions and update responsibility.
- Dependency inventory
- Automated checks where suitable
- Patch and exception process
Recovery design
Define service restoration and data recovery expectations before selecting backup and replication patterns.
- Recovery objectives
- Backup scope and verification
- Failure and restore exercises
Operational visibility
Collect enough signal to diagnose important failures without gathering unnecessary sensitive data.
- Structured events and correlation
- Service indicators and alerts
- Retention and access rules
Incident readiness
Define who responds, how issues are communicated and what produces follow-up action.
- Escalation and contacts
- Runbooks for likely scenarios
- Review and improvement loop
07 / Architecture decision record
Preserve the reason, not just the result.
A concise record helps future contributors understand why a decision was suitable at the time and when it should be reconsidered.
08 / Interactive planner
Shape a starting architecture scope.
Select the areas the technical review should examine. Your choices can be copied, cleared or carried into contact. This planner is not a design approval, security assurance, compliance statement or final specification.
09 / FAQ
Technology stack and architecture questions.
Architecture is a set of contextual tradeoffs. Specific recommendations require product and operating inputs.
What is a technology stack?
A technology stack is the connected set of languages, frameworks, data stores, integration methods, hosting services and operational tools used to deliver and run a digital product. The architecture describes how those parts are separated, connected, secured, deployed and owned.
How should a technology stack be chosen?
Start with the product's users, workflows, data, integration needs, expected change, service criticality, team skills, budget and operating constraints. Compare a small number of viable options against those requirements and document the tradeoffs rather than choosing by popularity alone.
Is one modern framework best for every website or application?
No. A content-led website, internal workflow tool, e-commerce operation and real-time application have different needs. The simplest dependable option that meets the requirement is often easier to operate than a fashionable stack with unnecessary moving parts.
When is a headless architecture useful?
A headless approach can be useful when structured content must serve several channels, the interface needs independent release cycles or an organisation has the team and tooling to operate the separation. It also introduces preview, integration, deployment and editorial complexity that should be justified.
Should a new product use microservices?
Not by default. Independent services can help when domains, teams, scaling needs or release boundaries are genuinely separate. They also increase network, data consistency, deployment, testing and observability demands. A modular monolith is often a clearer starting point when those boundaries are still developing.
Does a technology choice make a product secure or compliant?
No technology name guarantees security or compliance. Outcomes depend on requirements, configuration, implementation, identity and access design, data handling, dependency management, monitoring, operational practice and independent review where appropriate.
What should an architecture decision record contain?
It should state the decision, context, options considered, important requirements, chosen tradeoff, known consequences, owner and review trigger. A concise record helps future teams understand why a choice made sense at the time.
10 / Related services
Connect the architecture to the product work.
Technical decisions become useful when they are informed by workflows and carried through implementation and operation.
Choosing a stack or untangling an existing one?