Field note / Build vs buy
Custom software vs SaaS: when to build the missing layer.
Most “we need custom software” moments are really missing ownership, integration, or a shared operating surface. The useful decision is which of those gaps is actually expensive—and whether a new product is the cleanest way to close it.
The decision in one line
Build custom software when the workflow is valuable and still lacks a coherent place to live.
Start with the job, the people, and the tools already paid for. Configure or connect first when that closes the gap. Build when the business needs a focused layer those products cannot honestly become.
Begin with the gap
The product category is not the brief.
Owners often arrive with a conclusion—“we need custom software”—before the missing capability is named. The more useful starting point is the recurring workaround: a spreadsheet holding a process together, a report assembled by hand, a client experience split across portals, or a decision that never has one dependable view.
If that gap is really a missing handoff, missing field, or missing status surface inside tools the team already uses, better configuration or automation and integrations may be enough. Custom software should answer a specific missing capability, not a general dissatisfaction with software.
When SaaS is enough
Configure and connect before inventing a product.
Off-the-shelf software is often the right first move when the workflow has a recognizable trigger, a defined source of truth, and a finish the team can describe. Lead routing, scheduling status, document assembly, inbox-to-CRM bridges, and reporting layers frequently improve without a new codebase. Use what to automate first when several candidates compete.
The test is whether the existing tools can host the work without forcing harmful workarounds. If people are fighting the product every day to preserve the business’s real process, that is signal. If they simply have not finished configuring or connecting what they already own, that is a different project.
- Stable triggers and clear ownership
- Sources of truth the team trusts
- Handoffs that can be named and observed
- Exceptions that do not redefine the whole workflow
When custom earns its place
Build the layer only the business can own.
Custom software becomes justified when the workflow is core to how the business creates value, when off-the-shelf products force the team into brittle workarounds, or when several systems need one decision surface with permissions and audit paths a generic product cannot model. See custom software for how ShepBuild scopes that layer.
Growing owner-led teams hit this wall often: proximity used to move context, then growth makes informal handoffs expensive. A focused internal tool can become the calm operating surface over SaaS that remains valuable behind it—without pretending every adjacent idea belongs in version one. Audience pattern: growing owner-led teams.
A sound first build
Choose the smallest complete product with one owner and one receipt.
A first custom layer should support a real workflow end to end: intake through decision, status through handoff, or review through next action. It should establish the design and data patterns the business can maintain, and create evidence for what the next release should—or should not—include.
Hybrid architectures are often wiser than replacement. Keep the SaaS systems that already do their job well. Build the missing operating surface that makes ownership, state, and authority obvious. Lifecycle ownership, source control, hosting, and validation belong in the engagement conversation before the first public client build ships—not after. The delivery process keeps those states separate.
Useful answers before a tool is chosen.
01How do we know SaaS configuration isn’t enough?
When the team’s real process still has no coherent place to live after the tools are properly configured and connected—especially if workarounds preserve core value the product cannot express.
02Can custom software sit on top of tools we already pay for?
Yes. Many strong first builds are operating layers over existing CRM, inbox, calendar, document, or accounting systems rather than full replacements.
03What should we decide before talking about source code?
Name the workflow, the users, the source of truth, the authority boundary, and what “done” looks like. Ownership and hosting terms matter, but they follow a clear product brief.
04Is custom software always more expensive than SaaS?
Not as a slogan. The honest comparison is total operating cost: subscriptions, workarounds, delays, rework, and the cost of a focused build that removes a specific gap. There is no universal winner.
One problem. One useful first build.
Map the gap before choosing a product category.
The AI Build Session separates a configuration problem, an integration problem, and a custom-software problem.
Start a conversation