HLDs and LLDs stall for two reasons. First: they contain everything, which means nobody can approve anything. Second: they contain nothing decisive, which means every decision gets pushed to a meeting.
Both are self-inflicted. Here's what works.
What the HLD is actually for
The HLD answers: what are we building, at a level a business stakeholder can approve, and why is this the right shape given the constraints?
It has these sections, no more:
- Business context. Two paragraphs. What triggered this project. What outcome does the business want.
- Scope and non-scope. A short list of what's in. A shorter, clearer list of what's out. The out-list matters more.
- Architecture diagram. One diagram. If you need two, you're describing two systems.
- Key decisions. Three to seven decisions with the trade-offs called out. Each with the alternative you rejected.
- Assumptions and dependencies. The things you're not solving in this project but need to be true.
- Risks. Real risks, not "the migration might take longer than planned." Specific things that could break.
- Rough cost and timeline. Order of magnitude, not a plan.
Everything else — sequence diagrams, IAM policies, VPC subnets, security group rules — is LLD.
What the LLD is actually for
The LLD answers: what does an engineer need to actually build this, without further architecture consultation.
It has:
- Detailed architecture diagram. With component names matching what will exist in AWS.
- Data flows. Every service-to-service interaction, protocol, port.
- IAM roles and policies. By name, with the actual permissions.
- Network layout. VPCs, subnets, route tables, security groups.
- Deployment topology. Which resources in which account, in which region.
- Operational runbook. How to deploy, roll back, monitor, alert.
- Test plan. Concrete test cases with pass criteria.
If an engineer can pick up the LLD and build without asking you a question, it's done. If they need to ask, it isn't.
What kills HLDs at review
Overspecification. If the HLD talks about VPC CIDR ranges, the reviewer will argue about VPC CIDR ranges instead of the actual architecture. Push CIDRs to the LLD.
Understatement of trade-offs. If the HLD says "we chose RDS" without saying "we considered EC2-hosted PostgreSQL and rejected it because…", the review committee will bring that alternative up themselves and you'll spend the meeting justifying instead of clarifying.
Cost estimates without ranges. "$450k" invites debate about the $50k. "$400k–$500k depending on X" gets accepted.
Timelines shown as Gantt charts. Nobody at CAB reads a Gantt chart. They read "3 months" or "6 months." Give them the summary, put the Gantt in the appendix.
The specific patterns that get sign-off
Decision tables. For each of the three-to-seven key decisions, a four-row table: The Decision / What We Considered / What We Chose / Why. It's easier to approve a table than a paragraph.
Compliance mapping. If the project has regulatory scope (PCI, HIPAA, GDPR, banking regulations), a one-page table mapping each regulatory control to the architecture element that provides it. Compliance people read this table and skip everything else. That's a feature.
Named owners. Every risk has a name attached. Every dependency has a name. "Team X" is not a name. If you can't name a person, the risk is real.
The "what won't work" list. A short section explicitly listing approaches that were considered and rejected. This is the section reviewers most often skip — but including it means the alternatives don't get re-litigated in the meeting.
The LLD review is different
LLD reviews are technical. The reviewers are usually infrastructure and security engineers, not business people. What kills LLDs there:
- IAM policies that grant
*. Every one is a fight. - Security groups too open. Same.
- Missing monitoring. If the LLD doesn't have a "how will we know when this breaks" section, InfoSec adds a review cycle.
- No rollback plan. Every deployment step needs a corresponding rollback step. If your rollback is "restore from backup and hope," it's not a rollback.
Fix these before submitting, not during review. Every review cycle costs a week.
The right length
An HLD for a mid-sized project (~$500k, 3–6 months) is 15–25 pages including diagrams. An LLD is 40–80 pages. Documents dramatically shorter than these under-specify. Dramatically longer, and nobody reads them.
Bottom line
HLD and LLD are not deliverables. They're contracts. The HLD is a contract with the business about what and why. The LLD is a contract with the engineers about how. Every reviewer signing off is a party to the contract. Write them like contracts — precise, complete, and boring — and they get approved.
I've delivered HLD/LLD packages for banks, telcos, energy companies, and government. The ones that got sign-off inside a month all had these properties. The ones that took a quarter all violated at least three of them.