Draw the boundary before you name the framework
12 June 2026
When a small business commissions a custom web application, the first lively argument is often about frameworks or hosting brands. Those choices matter, but they are not the first architecture question.
The first question is: what must stay together, and what must stay apart?
A clinic example
A clinic wanted a patient-facing portal. Early debates circled around which JavaScript framework the contractors preferred. Meanwhile nobody had decided whether appointment creation lived in the portal or remained inside the practice-management system.
Once that ownership question was answered, half the framework arguments evaporated. The portal became a thinner surface: reading schedules, submitting requests, showing status. The “big” technical choice became smaller because the responsibility map was clear.
Practical steps
- List the jobs the application must protect in the first release.
- For each job, name the system of record — even if that system is a spreadsheet today.
- Draw module boxes around jobs that change for the same reasons.
- Only then shortlist implementation options that respect those boxes.
LeafHub architecture advisories spend most of their early sessions on this boundary work. Framework taste comes later, when the boxes are stable enough to survive a staff change.