Compare · Buy or buildChecked 27 September 2026
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.
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.
Bring the version of this question that is about your company.
The first conversation is with the people who would build it. If there is a fit, the Consult comes next.