Guide
Build, buy, integrate or automate: a decision framework
By Mavrin Labs. Published . Last updated . How this guide was researched and checked.
Four paths fix a systems problem: build something, buy something, connect what you already have, or automate the repeat work. Choose by naming the outcome you want, finding the one step that is holding it up, and taking the least complex path that moves it.
When adding tools stops helping
There is a point where another subscription stops helping. The business has a tool for customer records, one for scheduling, one for invoicing and one for messaging, and the work still stalls. Somebody retypes the same details into the second system. A request waits because nobody is sure whose list it is on. A report is assembled by hand from three exports.
Here is an illustration, which describes no real client. An enquiry arrives on a website and lands in an inbox. Somebody reads it, copies the details into the customer system, then messages a colleague to say it needs quoting. The colleague looks up a figure in the accounting tool and replies. Two days later somebody asks whether the customer was ever answered, and nobody can say without searching three places.
Nothing in that story is a missing tool. The tools are all present. What is missing is agreement about which system owns the record and what happens next.
When the complaint is retyping, waiting and uncertainty about whose job it is, the problem is rarely the absence of another tool.
What are the four ways to fix a systems problem?
Four paths are available, and naming them precisely stops the conversation from drifting. Building means commissioning software shaped around your work. Buying means adopting an existing product. Integrating means joining what you already run so information moves. Automating means having software carry out the repeat steps.
- Build
- Commission software shaped around your steps and definitions. You decide what it does next, and you carry the upkeep.
- Buy
- Adopt an existing product and configure it. Fastest to start, and the supplier decides what changes.
- Integrate
- Join the systems you already run so each piece of information is entered once and travels. Fixes most retyping.
- Automate
- Have software carry out the repeat steps a person now does by hand, with people approving what matters.
The rule for choosing is to take the least complex path that plausibly moves the outcome you named. Complexity here means how much has to change, how many people have to learn something, and how much you will have to maintain.
Start with the outcome and its owner
Begin with a result somebody owns. Write it as a sentence a person could be held to: the hours this task takes each week, the share of enquiries answered on the day they arrive, the number of records that need correcting. Then name who owns it.
An unowned outcome produces a project nobody can stop. Everything sounds worth doing, scope grows, and the review at the end has nothing to compare against. An owned outcome with a measure attached does the opposite: it rules options out, and it gives you a date on which you will know. The measurable results method sets out how a target and a review date are agreed before work starts.
Where is the first constraint?
The first constraint is the one step that sets the pace of everything around it. Find it by following several real items from arrival to finish and noting where each one waited longest, or where mistakes entered. That step, and not the one that annoys you most, is where the change belongs.
Work upstream of a constraint only arrives at the queue faster. Work downstream of it has nothing new to do. This is why projects aimed at the wrong step produce a tidier process and no change a customer would notice, which is the most expensive kind of success.
Constraints move. Once the first one is relieved, the pace is set somewhere else, which is the reason to take one path at a time and measure after each.
Evidence gates for each path
Each path has evidence that points towards it and evidence that points away. Read both columns before choosing.
| Path | Points towards it | Points away from it |
|---|---|---|
| Build | how you work is part of your offer; staff keep a parallel record; the rules change often | your process is ordinary; nobody will own the upkeep |
| Buy | the work is common and not where you compete; you need something running soon | the tool's assumptions clash with yours; your records would be stranded |
| Integrate | the same information is entered twice; work waits between systems | the systems offer no interface for other software; nobody owns the join |
| Automate | a task repeats weekly along known steps; a baseline can be measured | every case needs judgment; the task runs a few times a year |
Where two columns both apply, the honest reading is that you are not ready to decide and need a closer look at the constraint.
Write the decision record
Write the decision down in one page, before work starts. It takes under an hour and it is what keeps the project honest later.
- The outcome you want, as a sentence somebody owns, with the measure attached.
- The first constraint, and how you identified it.
- The path you chose, in the words build, buy, integrate or automate.
- The options you ruled out, each with the reason.
- The assumptions you are relying on, so a wrong one is visible later.
- The baseline as it stands today, and the date you will review the result.
Keep it where the next person will find it. The value is not in the writing but in having something specific to argue with when somebody proposes adding scope.
Common mistakes
Four mistakes cause most of the regret in this decision.
- Starting from a shortlist
- A list of tools contains no decision. Start from the outcome and the constraint, and the list shortens itself.
- Fixing the step that annoys you
- The irritating step and the limiting step are usually different. Follow real work through the process to find the limiting one.
- Running all four paths at once
- Simultaneous changes cannot be measured or credited. Sequence them, and review after each.
- Leaving the result unowned
- An outcome without an owner has no one to stop it growing. Name the owner before the work, not at the review.
References
Four public references bear on the four paths, and each is worth opening before you commit. All four were opened and read on Thursday, October 8, 2026.
Building: the secure software development framework published by NIST lists the practices a buyer may require (the framework). Connecting: the project on API security names the failure modes that appear once two systems exchange information (the project).
Automating with an AI step: the risk management framework for artificial intelligence offers a structure for deciding what to watch once a system is live (the framework). Anything a customer touches: the published accessibility criteria are testable statements rather than advice (the criteria).
Related guides and next steps
Each path has a guide that goes deeper. For building, read custom software or an off-the-shelf tool. For connecting, read the systems integration checklist. For automating, read the AI automation readiness guide.
Mavrin Labs works across all four paths, which is why a first conversation sometimes ends with a recommendation to change nothing yet. The services page sets out what each path involves. A decision reached this way puts hours back into the week of the people doing the work, instead of adding another system for them to learn.
Frequently asked questions
Why start from an outcome rather than from the tools?
Starting from an outcome gives you something to decide against. A tool shortlist has no answer in it, because every option on the list can be defended in the abstract. An outcome somebody owns, with a measure attached, rules options out quickly: anything that cannot plausibly move that measure is off the list, however impressive it is. It also tells you when to stop, which is the part a tool-first conversation never reaches.
What counts as the first constraint?
The first constraint is the step that sets the pace of the whole flow, the one where work waits longest or where errors enter. Find it by following several real items through the process and noting where each one sat still. Fixing anything upstream of it only delivers work to the queue faster. Fixing anything downstream of it changes nothing a customer would notice, because the work was never arriving fast enough to matter.
Can I choose more than one path?
Most real answers combine two paths, and that is fine as long as they are sequenced rather than started together. A typical pattern is to buy a tool for the ordinary part, connect it to what you already run, and automate the repeat work the connection makes possible. What goes wrong is doing all three at once, because nothing can then be measured and no single change can be credited or blamed.
What is a decision record and why write one?
A decision record is a short written note of what you chose, what you were trying to achieve, what you considered and why you ruled the others out. Writing it takes under an hour and it earns its place twice: it keeps the project honest when somebody wants to add scope, and six months on it tells you whether the reasoning was sound or merely confident. Without one, every review becomes an argument about memory.
How often should the decision be revisited?
Revisit the decision on the review date you set when you made it, and otherwise only when a stated assumption changes. A date chosen in advance keeps the project from drifting and keeps you from reopening a settled question whenever somebody mentions a new tool. If an assumption in the record turns out to be wrong, that is a real reason to reopen it, and the record is what makes the wrongness visible.
What if the honest answer is to change nothing?
Changing nothing is sometimes the right answer, and a framework that cannot reach it is a sales process. If the constraint is a habit, an unclear responsibility or a step nobody needs, then fixing the manual version is quicker and less work than any software. Write that conclusion down as a decision too, with the reasoning, so the question stays settled until something real changes.
Who writes these guides
Mavrin Labs delivers client work as a team in mixed roles, led by our founder. The people who write these guides are the people who build the systems described in them, and every page is reviewed before it is published.
Which hours would you take back first?
Send Mavrin Labs one workflow that is costing you the most time, and the reply comes back by email from the people who would build the fix.
Start a conversation