I default toward buying stable, boring, well-supported software for anything that isn't core to how the business actually creates value. Payroll, ticketing, most reporting — none of that needs a bespoke system, and building one would mostly just add maintenance burden nobody asked for.
The exception is the small set of workflows where a generic tool's built-in assumptions stop matching how the work actually happens — the language it expects, the handoffs it assumes, the approval chain it was designed around. That mismatch is usually small at first and expensive later, once enough people are working around the tool instead of with it.
That's the specific point where building something small and purpose-fit starts to pay for itself. Not everywhere. Not as a default. At the one or two places where the fit actually matters enough to justify owning the maintenance.
What's changed for me isn't the judgment call itself — it's how cheap it's become to test whether a custom fit is even feasible before committing to it. Natural language shortens the distance between "I think a purpose-built tool would help here" and an actual working prototype enough to test the idea in an afternoon instead of a quarter.
This note is mostly an attempt to write the judgment call down instead of re-deciding it from scratch every time a new workflow comes up.
Current Hypothesis
Custom AI solutions earn their cost only at the specific point where a generic tool's assumptions stop matching the real workflow — not before, and rarely everywhere at once.
Not a conclusion — a working idea, revisited as evidence comes in.