We have walked into codebases where the frontend was rebuilt twice but the same three-service split from 2018 still governs every feature request. Engineers complain about the stack. Architects complain about the topology. Leadership wonders why each new initiative feels harder than the last. The stack is visible and negotiable. The shape is invisible and sticky. That asymmetry is why architecture decisions deserve more scrutiny than framework choices.
Interactive · Stack vs shape
Teams debate stacks openly. Shape decisions often happen by default. Compare what changes easily and what compounds silently.
Examples
- React
- Node
- Postgres
- AWS Lambda
- Prisma
Change frequency
Every 2 to 4 years on average
Visibility in org
High. Appears in job posts, RFPs, and slide decks.
Primary risk
Obsolescence, hiring friction, vendor pricing shifts.
Stack is negotiable. Shape is sticky.
The stack is the material: languages, frameworks, cloud services, ORMs. It determines developer experience and hiring pools. It is also the easiest layer to change, because tooling markets push upgrades and rewrites feel culturally acceptable. The shape is the geometry: module boundaries, data ownership, sync versus async handoffs, what is a source of truth and what is a cache. Shape decisions answer "how does work move through the system?" They are harder to see in a diagram of logos and harder to undo without touching everything.
Shape persists for boring, rational reasons. First, it works well enough. Second, it is entangled with business process. Third, nobody documented the alternative that was rejected, so revisiting the decision feels like starting from zero. Fourth, every feature since has been bolted onto the existing geometry, increasing the cost of redrawing lines. By year three, the shape is not a decision. It is the terrain. New teams navigate it rather than question it.
Interactive · Decisions that persist
These choices are often made in week two of a project and felt for a decade. Select a decision type to see typical patterns and liberating alternatives.
The question
Where do you draw lines between modules or services?
Typical launch choice
Split by team structure or by technical layer (API, worker, UI).
Typical longevity
10+ years. Boundaries become org charts and budget lines.
Revisit cost
High. Requires data migration, contract rewrites, and political negotiation.
Liberating pattern
Split by business capability. Each boundary owns its data and publishes events.
“You can rewrite the framework. You rarely get a clean rewrite of the shape.”
Liberating vs constraining geometry
Liberating architecture decisions share traits: boundaries follow domain language, data has a single owner per entity, async handoffs are explicit and observable, and the system can be explained on one whiteboard without acronyms. Constraining decisions hide behind integration layers, duplicate entities across services, rely on nightly batch jobs nobody monitors, or require a "platform guru" to change safely. Both patterns can ship. Only one survives contact with a rotating team.
Before the next rebuild, ask which parts of the current system would survive unchanged if you swapped the entire stack tomorrow. That surviving list is your real architecture. Decide there deliberately, document the trade-offs, and treat shape with the same rigor you treat stack selection. Frameworks age. Geometry compounds.