Skip to content

Special Cases

Most software follows the same basic path. Some domains add constraints that change the design.

If you treat every system as the same, you can miss the limits that matter in specific environments.

Some software has extra rules.

Mobile, embedded, data-heavy, and AI systems often need different decisions because of their operating context.

General softwareSpecial cases
Common constraintsExtra constraints
Standard user experienceDomain-specific limits
General deployment modelMore specific runtime needs
Typical data flowUnique performance or safety concerns

A mobile app may need to work with poor connectivity.

A clinic system on a locked-down device may need stronger operational constraints.

An AI-powered feature may need different oversight than a simple rules-based workflow.

  • Assuming one architecture fits every domain.
  • Copying patterns from the wrong context.
  • Ignoring platform constraints.
  • Treating special cases as minor variations.
  • What makes this system different?
  • Which constraints matter most?
  • What should not be copied from the general case?

Pick one special domain and ask:

  • What is unique about it?
  • What changes because of that uniqueness?
  • What stays the same?

Special cases need the same fundamentals, plus domain-specific judgment.

Next, put the whole path together.


  1. Why Software Exists
  2. What People Need
  3. What Success Looks Like
  4. Safety, Privacy, and Trust
  5. What Information It Needs
  6. How Software Should Feel To Use
  7. How Software Is Put Together
  8. How We Know It Works
  9. How Changes Reach Users
  10. How It Stays Healthy
  11. How It Changes Over Time
  12. How Teams Make Decisions
  13. How Cost And Value Shape Choices
  14. Special Cases
  15. Putting It All Together