Skip to main content
The Hard Parts.dev
THP · Issues · 01 All issues →

Issue 01

The inaugural edition

27 April 2026 151 entries

First public release of the reference. Four catalogs ship together — failure modes, tech decisions, red flags, engineering playbooks — covering the recurring shape of software work.

FM

Failure Modes

31 new

TD

Tech Decisions

38 new

New 38

  1. TD 01 Monolith vs Microservices
  2. TD 02 Modular Monolith vs Distributed Services
  3. TD 03 REST vs GraphQL
  4. TD 04 SQL vs NoSQL
  5. TD 05 Sync Communication vs Event-Driven
  6. TD 06 Shared Database vs Service-Owned Data
  7. TD 07 Strong Consistency vs Eventual Consistency
  8. TD 08 Batch vs Real-Time Processing
  9. TD 09 Edge Logic vs Centralized Backend Logic
  10. TD 10 Build vs Buy
  11. TD 11 Speed vs Robustness
  12. TD 12 Scope Flexibility vs Date Certainty
  13. TD 13 Platform First vs Product First
  14. TD 14 Rewrite vs Refactor
  15. TD 15 Generic Solution vs Case-Specific Solution
  16. TD 16 One-Way Door vs Two-Way Door Rollout
  17. TD 17 Customization vs Standardization
  18. TD 18 Experimentation vs Operational Stability
  19. TD 19 Central Platform Team vs Embedded Enablement
  20. TD 20 Specialist Teams vs Cross-Functional Teams
  21. TD 21 Strong Ownership vs Shared Ownership
  22. TD 22 Local Team Autonomy vs Central Governance
  23. TD 23 Documentation First vs Tacit Coordination
  24. TD 24 Synchronous Collaboration vs Async-First Collaboration
  25. TD 25 Test Pyramid vs Heavy End-to-End
  26. TD 26 CI Gate Strictness vs Developer Throughput
  27. TD 27 Feature Flags vs Branch-Based Release Isolation
  28. TD 28 Backward Compatibility vs Faster Evolution
  29. TD 29 Convention over Configuration vs Flexibility
  30. TD 30 Manual Review Depth vs Automation Dependence
  31. TD 31 AI-Assisted Development vs Manual-Only Development
  32. TD 32 Model API vs Self-Hosted Model
  33. TD 33 RAG vs Fine-Tuning
  34. TD 34 Prompt Layer vs Workflow/Tooling Layer
  35. TD 35 Human-in-the-Loop vs Full Automation
  36. TD 36 Fast AI Adoption vs Governance-First AI Adoption
  37. TD 37 Broad AI Enablement vs Restricted High-Trust AI Use
  38. TD 38 Synthetic Evaluation vs Real-World Evaluation

RF

Red Flags

42 new

New 42

  1. RF 01 Nobody can explain this module simply
  2. RF 02 One file does too much
  3. RF 03 Changes always touch too many places
  4. RF 04 Naming is generic where understanding is weak
  5. RF 05 Business logic leaks across layers
  6. RF 06 Tests are hard to write for normal changes
  7. RF 07 End-to-end tests carry all the confidence
  8. RF 08 Shared utility layer grows faster than products
  9. RF 09 Integration contracts are implicit
  10. RF 10 Generated code is merged without deep review
  11. RF 11 Everyone asks the same person
  12. RF 12 Critical knowledge lives in chat and memory
  13. RF 13 People avoid touching certain areas
  14. RF 14 PRs are approved faster than they are understood
  15. RF 15 Ownership is claimed but not visible
  16. RF 16 No one disagrees in meetings, everyone complains later
  17. RF 17 The loudest person wins architecture discussions
  18. RF 18 AI use is widespread but norms are unclear
  19. RF 19 Work enters faster than it leaves
  20. RF 20 Everything is urgent
  21. RF 21 Scope changes without decision records
  22. RF 22 Dates are fixed but trade-offs are implicit
  23. RF 23 Tickets substitute for thinking
  24. RF 24 Metrics are visible but not trusted
  25. RF 25 Retrospectives repeat the same outputs
  26. RF 26 Release confidence depends on luck and timing
  27. RF 27 Dependencies are discovered late every cycle
  28. RF 28 Teams cannot explain what done means
  29. RF 29 Reporting looks healthier than delivery feels
  30. RF 30 Teams are measured on output, not outcome
  31. RF 31 Ownership and authority do not match
  32. RF 32 Platform work has no users, only sponsors
  33. RF 33 Risks are acknowledged but never priced into plans
  34. RF 34 Governance exists mainly as ceremony
  35. RF 35 Nobody can say what the company will stop doing
  36. RF 36 More output, less certainty
  37. RF 37 AI-generated artifacts are trusted more than source material
  38. RF 38 Prompt changes replace system thinking
  39. RF 39 Benchmarks are discussed more than real user outcomes
  40. RF 40 Humans in the loop are rubber stamps
  41. RF 41 RAG uses sources nobody actually trusts
  42. RF 42 Model drift is noticed informally, not measured

EP

Engineering Playbook

40 new

New 40

  1. EP 01 Upgrade code review for AI-assisted work
  2. EP 02 Define safe AI development zones
  3. EP 03 Introduce AI tools without synthetic velocity
  4. EP 04 Build a grounded RAG system
  5. EP 05 Evaluate an AI feature against real tasks
  6. EP 06 Design human review that is not rubber-stamping
  7. EP 07 Detect AI drift before users do
  8. EP 08 Create AI usage norms for a team
  9. EP 09 Review service boundaries
  10. EP 10 Reduce change fan-out
  11. EP 11 Make an integration contract explicit
  12. EP 12 Improve testability without stopping delivery
  13. EP 13 Choose where business rules should live
  14. EP 14 Audit a shared layer for accidental complexity
  15. EP 15 Design a safe rollout path
  16. EP 16 Refactor a dangerous hotspot
  17. EP 17 Run a phased migration
  18. EP 18 Start a rewrite safely
  19. EP 19 De-risk a risky release
  20. EP 20 Recover a slipping project
  21. EP 21 Re-scope without lying
  22. EP 22 Handle a high-dependency delivery
  23. EP 23 Turn recurring urgent work into managed work
  24. EP 24 Stabilize a fragile service
  25. EP 25 Run an incident review that actually helps
  26. EP 26 Write a useful runbook
  27. EP 27 Build a practical rollback strategy
  28. EP 28 Reduce operational dependence on heroes
  29. EP 29 Create meaningful alerts
  30. EP 30 Triage operational debt
  31. EP 31 Prepare a handover properly
  32. EP 32 Improve release confidence
  33. EP 33 Onboard a new engineer well
  34. EP 34 Spread knowledge out of one expert
  35. EP 35 Re-establish ownership in a blurry area
  36. EP 36 Run a healthy engineering retrospective
  37. EP 37 Repair trust after a painful incident
  38. EP 38 Facilitate a difficult technical disagreement
  39. EP 39 Reduce review bottlenecks without lowering quality
  40. EP 40 Recover a team stuck in reactive mode