# Should you buy a product and bend your workflow, or build around the workflow you have?

Buy the product when your workflow is the same as everyone else's: payroll, accounting, ticketing, email. Build when the workflow is the part of the business you would not change, and bending it to fit a product would cost you the thing you are good at. Most operations are a mix, and the honest answer is usually both.

Kicker: Buy or build
Checked: 2026-09-27

## Where the workflow sits

| Dimension | Buy the product | Build around the workflow |
| --- | --- | --- |
| The work itself | Done the same way by every company your size | Done your way, and the way is part of why customers pick you |
| Changing it | You change your process when the vendor changes the product | You change the system when the process changes |
| The data | Lives in their store, exportable in their shape | Lives in your store, in the shape your operation thinks in |
| What you are paying for | Somebody else's ongoing engineering, spread across every customer | A system nobody else has, and the work of keeping it alive |
| The failure case | You end up running the vendor's process and calling it yours | You end up maintaining code that a product would have done fine |

## The test

One question sorts most of it. If a competitor copied this workflow exactly, would they be closer to you or further away?

If closer, buy. Payroll, accounting, ticketing, calendars, email: doing these your own way is a cost with no return, and a product with a thousand customers has already handled the edge cases you have not met yet.

If further away, the workflow is not overhead. It is the operation. Bending it to fit a product means bending the thing the business is actually good at, and it usually happens quietly: the product cannot represent one step, so the step moves into a spreadsheet, then into somebody's head, then out of the process altogether.

## Both failure modes are real

Buy when you should have built, and after two years your operation is a description of the product's assumptions. The tell is a growing pile of workarounds that everyone has stopped noticing, and a new hire who asks why a step exists and gets told that is how the system does it.

Build when you should have bought, and you own a codebase whose entire job is something a product does better, plus the maintenance, plus the risk that the one person who understands it moves on. This is the more expensive mistake and it is the one a build shop has every incentive not to mention.

For most teams the right answer is a small built piece connecting bought products, sitting exactly where the work is specific and nowhere else.

## The domain question, answered properly

The fair objection to a small build team is domain expertise. A vendor selling into your industry for a decade has seen more of your business than anybody who arrived last month. That is true and worth paying for where the product encodes it.

What that vendor cannot know is how your operation runs, because it is not their industry knowledge, it is yours. A build starts from the operation as it is: what happens now, who does it, what they are working around, and what would change if the work took an hour instead of a day. The Consult produces that map first, and it is yours whether or not anything gets built from it.

The reason OCTYN can say that is that it does the same thing to its own operation before selling it. OCTYN's own inbox and its own publishing system both ran as its daily work before either was offered as a system.

## What OCTYN will tell you not to build

If the answer to the test is buy, that is the answer you get on the call. A Consult that ends in do not build this is not a lost sale, because the alternative is a build that gets resented by month four.

Where it goes the other way, the shape is usually narrow: one workflow, the one that is specific, wired into the products you already pay for instead of replacing them.

## Dated record

- Each company on the craft retailer's outreach system has its own target file of sources, weights, thresholds and market, kept as data rather than as code (recorded 2026-09-27)
- Deciding home market or abroad moved from a model's judgement into a rule based on currency, phone prefix, tax registration and domain, backed by tests. The geography mistake went away with it (recorded 2026-07-29)
- OCTYN's own inbox and its own publishing system both ran as OCTYN's daily work before either was offered as a system (recorded 2026-07-06, [Agency Ops](https://octyn.co/casestudies/agency-ops))

## Terms used here

- [Total cost of ownership](https://octyn.co/glossary/total-cost-of-ownership)
- [Orchestration](https://octyn.co/glossary/orchestration)
- [Human in the loop](https://octyn.co/glossary/human-in-the-loop)
- [System architecture](https://octyn.co/glossary/system-architecture)

## Bears on

- [Company Brain](https://octyn.co/systems/company-brain)
- [Content Engine](https://octyn.co/systems/content-engine)

## Related

- [What it costs to change an AI workflow six months later](https://octyn.co/compare/cost-to-change-ai-workflow-six-months)
- [What production ready means for an AI system](https://octyn.co/compare/production-ready-ai-system)
- [Company Brain](https://octyn.co/systems/company-brain)

Canonical: https://octyn.co/compare/built-around-your-workflow-vs-tool-you-bend-to