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

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 tool 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 layer connecting bought tools, 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 it to its own operation before selling it. The outreach engine, the lead engine and the inbox all run OCTYN's own work before any of them is 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 tools you already pay for rather than replacing them.

The receipts under this page

Every claim above comes from a system OCTYN built and operates. Each line carries the date it was recorded and where it came from, so it can be argued with rather than taken on trust.