For a while now I've felt like solutions like customer relationship management (CRM), content management systems (CMS), and task management show up often enough that they seem like patterns themselves. I struggled though to find a source that tries to decompose these patterns in a way that was easy for me to index through.
One book would be great at the literal architecture pattern, another might be good at some philosophy behind typical features like search and messaging, but there wasn't a centralized coherent source that I could reference back to. So I decided to take a stab at it, with the help of the robots of course.
I had a running list in my head for a few years already and had written out some draft outlines of what such a source might look like. The first step I needed to do though was use deep research to make sure I wasn't trying to re-write something that had existed already, I'm still not convinced despite all the research I've done on my own and the results of deep research. It seemed that even the robot was confused why this kind of reference didn't already exist (that made me highly suspicious).
Disclaimer: I am highly critical of anything that robots do. I don't particularly like the robots but they are here with us regardless so I work with them. Doing so has saved me a lot of time but also was like arguing with a heap of sand from time to time.
I'll layout the repo structure and high level explanations for things below.
Structure of the Reference
There are three main folders, "archetypes", "capabilities", and "foundational patterns".
Archetypes
These are common shapes of systems, the primary motivation for making this repo. Examples include: document management and customer relationship management.
Capabilities
These are more like building blocks of systems, common features that you'll often find in software. Examples include: search/filtering, audit logs, and notifications.
Foundational Patterns
This is probably the most abstract part of the resource. It attempts to point out the forces that give form to the archetypes we commonly see. Other sources do a much better job at explaining these concepts and the list in the repo are meant be more supportive in terms of reminders that these patterns are at play in various ways through the archetypes.
Playbooks
Playbooks are meant to be the actual recipes of the cookbook. They apply a domain to the core ingredients and give a sense of how these pieces will mix and interact.
Using the Project
Simple example
Suppose you need to design a municipal permit platform for building, signage, and event permits.
The system has to accept applications, store submitted documents, route reviews across departments, track approval gates, notify applicants, and preserve an audit trail.
Instead of starting with technology choices, Solution Cookbook lets you reason from system shape:
case-ticket-system + workflow-bpm-system + document-management-system + capabilities -> plausible architecture
None of this is especially novel. The value is having these recurring patterns and capabilities collected in one place, with notes on tradeoffs, state boundaries, and scaling considerations, so design discussions can start from shared structure instead of scattered intuition.
Existing Project Example
One of the more practical uses of Solution Cookbook is not greenfield solution architecture but feature expansion in systems that already exist.
For example, say a CRM team wants to add contract approvals, signature tracking, and renewals. Without clear boundaries, the CRM slowly absorbs document storage, approval routing, reminders, search projections, and audit concerns until the feature becomes a tangled subsystem.
The cookbook helps treat that change as a composition exercise instead:
crm + workflow-bpm-system + document-management-system + capabilities
That framing makes it easier to decide what remains authoritative in the CRM, what belongs in contract lifecycle handling, what workflow is allowed to control, what data belongs to which system, and where data is derived rather than treated as the source of truth.
Using Playbooks
A playbook is most useful as a way to frame a system before implementation details take over. The idea is that you'd start with the closest playbook, use it to identify likely boundaries, lifecycle concerns, and capability needs, and then adapt it to the actual domain and constraints you're facing.
The goal is not to copy the playbook literally. The goal is to make the important architectural questions explicit earlier, questions around ownership, workflow, search, integrations, and source-of-truth boundaries.
So I hope you'll take a look at the repo maybe it is useful, maybe it is completely wrong and you'll not want to read any of it. Either way thanks for reading this!
Top comments (0)