Monolithic vs composable

Two different philosophies for building systems with large capabilities.

Monolithic approach

• Build one giant system that does everything
• All functionality integrated inside the system
• Your data lives inside it
• Proprietary formats internal to the system
• No interchange format (or very limited - maybe an API, maybe export)
• User works entirely within the monolith
• Examples: Notion (tries to be notes + database + wiki + project management), Salesforce (giant integrated CRM), Adobe Creative Cloud (integrated suite with proprietary formats), 60s mainframe systems

Composable approach

• Build many small tools that each do one thing well
• Tools work together via standard interchange formats
• Your data lives in files that any tool can access
• Open formats (text, markdown, etc)
• Files/text streams are the universal interchange format
• User controls how tools compose
• Examples: Unix tools (grep, sed, awk, git), markdown files (write in any editor), Git, Obsidian (works with files on your filesystem)

The tradeoffs

Monolithic systems can be easier initially — everything is integrated, works together out of the box, consistent interface.

Composable systems require more initial setup but give you more control — you choose your tools and customize them, create your own workflows, own your data in open formats. Over time, arguably, the ceiling is higher.

2025-11-05

Home