Find a useful pattern.
Practical guides to choosing, building and owning technology, including how to put AI to work well. Explore a project type, work through a decision or plan what happens after launch, with useful examples and selected resources.
Technology
The kinds of tools and systems you can build—and the work each is suited to.
Choose technology around the work
Software gives business decisions a place to live. Find the responsibility that needs to become dependable before choosing its implementation.
Read the guide
Build a system your team can run
A collection of working tools can still produce an unreliable operation. Make shared records and status changes mean the same thing to everyone.
Read the guide
Applications that earn their place
The hard part of an application is often what happens between screens: interruptions, corrections, shared records and returning to unfinished work.
Read the guide
Put AI where judgment can support it
The best AI opportunity may be work that is costly to perform but straightforward to verify. Evaluate the checking effort alongside the generation.
Read the guide
Make the handoffs work
Moving information does not transfer responsibility. Design the agreement at each handoff before automating the movement.
Read the guide
A website connected to your business
A website makes promises your operation must fulfill. Judge it by useful next steps and informed inquiries, not submission volume alone.
Read the guide
APIs make a useful promise
An API is an agreement about what another system may rely on. Define success, uncertainty and repeated requests as carefully as the data fields.
Read the guide
Improve the tools people already use
An extension can put useful context exactly where a decision happens. Weigh that advantage against its dependence on someone else’s interface.
Read the guide
Connect tools without losing control
Synchronization is a business policy about meaning, authority and time. A working connector cannot decide whose version should win.
Read the guide
Build the engine behind repeated work
Shared logic prevents drift only when the business rules really are shared. Preserve meaningful differences before centralizing the implementation.
Read the guide
Decisions & frameworks
Ways to test an idea, compare alternatives and make the next investment count.
Make work easier before making it faster
Faster tasks can create longer queues. Look at the waiting between tasks and the result the whole process produces.
Read the guide
Build something that returns useful capacity
Technology can repeat expertise, but it can repeat its mistakes too. Preserve the conditions under which a method works, including when to stop.
Read the guide
Make the tradeoffs visible
Technology choices move costs between money, attention, flexibility and dependence. Make the destination of each cost visible.
Read the guide
Build, buy or configure?
Buy the assumptions that fit your business. Build selectively where a meaningful difference would otherwise become an expensive workaround.
Read the guide
Choose the team for the work ahead
Separate temporary delivery capacity from lasting business context. Both hiring and contracting depend on someone being available to make decisions.
Read the guide
A temporary tool or a lasting asset?
A successful prototype can become an unplanned dependency. Separate what may be discarded from the data, rules and obligations that must survive.
Read the guide
Check the problem before the solution
Imagine the proposed solution working perfectly, then ask what problem would remain. That question can expose the mistaken premise before the build.
Read the guide
Remove the work you do not need
Every automated step creates future obligations. Remove rituals before building them into software, while preserving the decisions that protect the work.
Read the guide
Fix the constraint that holds up the work
More generated work can deepen a backlog. Protect the scarce decision or capability that determines how much useful work actually finishes.
Read the guide
Make the first release worth using
A useful first release makes a narrow promise and keeps it. Reduce the range of cases before removing the things that make those cases dependable.
Read the guide
Measure what the change returns
Time saved, usable capacity and cash savings are different results. Measure what the freed capacity actually lets the business do.
Read the guide
Keep the expensive decisions reversible
Code changes can be reversible while the records and promises they create are not. Spend care where a choice accumulates costly history.
Read the guide
Get another view before you commit
A useful review tests the assumption that could change your decision. It should leave you with reasoning another team can use, not dependence on the reviewer.
Read the guide
Plan around outcomes and dependencies
A roadmap explains why work happens in a particular order. Include the learning that could change the plan before building on untested assumptions.
Read the guide
From vibe coding to dependable software
AI authorship does not decide software quality. The decisive question is whether someone understands and can verify the behavior others will rely on.
Read the guide
Give the build a clear destination
A useful specification exposes disagreement before implementation. Concrete awkward examples reveal hidden decisions more effectively than pages of general requirements.
Read the guide
Ownership & operations
The people, costs and routines that keep a useful system useful.
Plan who will own the system
Ownership means being able to access, understand and change a system—or choose someone who can. Possessing the code alone is insufficient.
Read the guide
Make maintenance part of the plan
Unchanged code can stop working when the world around it changes. Plan care around dependencies, accounts and business assumptions as well as new features.
Read the guide
Count the cost after launch
The costliest work may never appear on an invoice. Compare full commitments and identify which uncertain assumption could reverse the decision.
Read the guide
Know where your data belongs
Authority belongs to facts, not necessarily entire applications. Preserve the difference between a current value and what was true for an earlier transaction.
Read the guide
Give people the access they need
Permissions determine how far a mistake can travel. Separate the ability to see information from the authority to change it or act on it.
Read the guide
Design for the day something fails
A restored database cannot undo actions already taken elsewhere. Plan how records, people and external systems return to agreement after an interruption.
Read the guide
Put review where it changes the outcome
Human review consumes attention. Design the evidence, workload and authority so someone can genuinely change the outcome before approving it.
Read the guide
Make the work understandable to someone else
Preserve the reasoning that code and screens cannot explain. A useful handover prevents the next person from having to rediscover important constraints.
Read the guide
Build for the people doing the work
A workaround reveals something about the work. Examine who benefits from a new system and who absorbs its extra effort before blaming resistance.
Read the guide
Keep a workable way out
An exit requires usable records and understandable business rules, not just a download. Accept dependencies deliberately and preserve a credible route away.
Read the guide
Know whether the system is working
A system can report success while no useful work arrives. Monitor completed journeys and missing work, then use technical signals to explain the gaps.
Read the guide
Improve a system without breaking its work
Generated code can change a business promise while passing its own tests. Keep changes understandable and compare them with an independent account of intended behavior.
Read the guide