Which early modeling choice will become expensive to change?
Move from the concepts a product elevates, to the attributes that genuinely belong together, to the public interface others depend on. This is a design discussion, not a prescription to split every system into services.
Who this is for: Technical product managers, founders and engineers who can follow a data model and an API example.
Take away: A boundary sketch with one coupling risk and one promise to downstream users.
Estimates use 250 words per minute, rounded up for each piece. Allow extra time for the reflection at the end. Open a piece for its selection note and available summary, then continue to the original.
Matt Brown argues that the concepts a startup builds around shape its interface, pricing and expansion. Use the lens to examine a customer workflow, without treating database centrality as proof of product-market fit.
notes.mtb.xyz · About 6 min
Pause here: Is your central object how customers think, or how your first implementation happened to store things?
Particular’s shopping-cart example uses deliberately implausible business rules to expose attributes that need not share a boundary. It also shows why domain experts must check the exceptions and why composition has a cost.
particular.net · About 10 min
Pause here: Which values change together, and which only happen to share a familiar noun?
A practical API-design essay explores compatibility, retries, pagination and operational limits. Read it for the costs an interface imposes on callers; its implementation preferences are opinions, not a complete security or transaction-safety specification.
seangoedecke.com · About 17 min
Pause here: Which change would look like a cleanup to you but break someone else’s working software?
How the pieces fit together
Brown uses data models as a strategic lens; his company examples are an investor’s interpretation, not a causal proof of why those companies succeeded. Particular narrows the discussion to a concrete shopping-cart model and the business rules behind its boundaries. The API essay adds the cost of exposing those choices to consumers. The useful tension is internal freedom versus external stability: decomposition can reduce coupling, but creates composition work and does not erase promises already made to users.
Digna Legi synthesis of the linked readings, not a claim that the authors endorse this combined approach.
Put five minutes aside
Put the idea to work
Use paper or your own notes app. These prompts are Digna Legi’s exercise, drawn from the readings.
Name the central concept your customers work with, and compare it with what your product makes easiest to see and change.
Choose two attributes currently grouped together. Ask a domain expert whether a business rule actually connects them; do not assume an absurd-sounding rule is impossible.
Sketch a possible boundary and the information that still has to cross it. Include the cost of reconstructing the user’s view.
Name an existing interface promise you must preserve and one failure or retry case its consumers need to handle. This is a review prompt, not a complete implementation design.
Before you leave: Which boundary will you sketch, what coupling might it remove, and which consumer promise must remain stable?
Help improve Digna Legi?
Allow Google Analytics to measure visits and reading-link clicks using cookies. Optional; the site works without it. Privacy details