Custom software makes sense when a business's operational workflow cannot be represented cleanly by an existing SaaS product — when integrations, permissions, automation, or data ownership become more expensive to work around than to build the system itself. SaaS remains the better choice for generic, well-understood processes (accounting, email, scheduling) where a business gains nothing from owning the system outright. The decision isn't ideological; it's a cost comparison between adapting a business to a generic tool and building a tool around the business.
What SaaS solves well
SaaS products exist because most business processes aren't actually unique. Accounting, payroll, email, scheduling, and project tracking are solved problems with mature, well-tested products behind them. Adopting one means no build time, no infrastructure to maintain, and a vendor responsible for security patches, uptime, and feature updates. For a workflow that looks like every other business's version of the same workflow, this is close to a strictly better deal than building something in-house.
What custom software solves well
Custom software earns its cost when the workflow is specific to how the business actually operates — not how a generic product assumes it operates. That includes business logic that doesn't map to a SaaS product's data model, multi-party permission structures a generic tool wasn't designed for, and process automation tied to internal rules that would otherwise require a person manually bridging the gap between two disconnected tools.
Where SaaS starts to feel restrictive
The signs are consistent across industries: manual data re-entry between two SaaS tools that don't integrate the way the business needs, permission models that are either too coarse (everyone sees everything) or don't reflect the business's actual roles, and recurring "workarounds" — spreadsheets, shared inboxes, manual approval chains — that exist specifically because the SaaS tool can't do what the business needs. Each workaround is a small cost; together, they're often the real cost of staying on SaaS past the point it fits.
Workflows that should probably stay on SaaS
- Accounting and payroll — regulated, standardized, and not a source of competitive advantage.
- Email and internal communication — infrastructure, not differentiation.
- Generic project or task tracking, when the team's workflow doesn't diverge meaningfully from the tool's defaults.
- Anything where the business would happily change its process to match the tool, because the tool's process is already fine.
Workflows where custom software starts making sense
- A core process that differentiates the business competitively or operationally — the thing the business is actually good at.
- Multi-role systems where permissions need to reflect a real organizational structure a generic tool doesn't model.
- Document or record generation with business-specific rules, branding, or distribution logic.
- Anything currently held together by spreadsheets, manual copy-paste between tools, or a person acting as the "integration layer" by hand.
Integrations
A single SaaS tool rarely covers an entire workflow end to end. Once a process depends on data flowing correctly between three or four different tools — and someone is manually checking that it did — the integration overhead itself becomes a maintenance burden. Custom software can own that data flow directly instead of stitching together webhooks and Zapier-style automations across tools that were never designed to work together.
Role and permission complexity
Most SaaS products ship with a handful of permission levels: admin, member, viewer. Businesses with real operational hierarchies — different visibility for internal staff, external partners, and clients, or document-level rather than account-level access — often can't express their actual structure in a generic tool's permission model without giving people either too much access or too little.
Document and process automation
Generating, populating, and distributing business documents according to specific rules is a common trigger for custom software. A generic e-signature or document tool can handle the mechanics of signing, but the business logic — who gets which document, under what conditions, with what generated content — usually has to live somewhere the SaaS product wasn't built to hold it.
Business-specific logic
Pricing rules, approval chains, eligibility criteria, and internal policies that are specific to one business rarely fit cleanly into a generic product's configuration options. Custom software can encode that logic directly instead of approximating it through settings, tags, and naming conventions inside a tool built for a different purpose.
Data ownership
With SaaS, business data lives in a vendor's database under the vendor's terms. That's a reasonable trade for generic tools, but it becomes a real constraint for data that's sensitive, regulated, or core to the business's competitive position. Custom software keeps that data inside infrastructure the business controls.
Vendor lock-in
Migrating away from a SaaS product that has become deeply embedded in daily operations is its own project — exporting data, retraining staff, and rebuilding integrations elsewhere. That switching cost is easy to underestimate at adoption time and expensive to discover later. Custom software doesn't eliminate lock-in (it creates a dependency on whoever maintains it), but it keeps the business in control of the roadmap.
Scaling considerations
SaaS pricing is typically per-seat or per-usage, which scales linearly (or worse) with the business. Custom software has a fixed build cost and a smaller, more predictable maintenance cost that doesn't necessarily grow with headcount or usage in the same way — the trade-off is that the business, not a vendor, is responsible for that infrastructure scaling correctly.
Cost over time
The real comparison isn't the first invoice — it's the total cost across several years. SaaS costs are visible and predictable per seat, but rarely include the cost of workarounds, manual data reconciliation, or the eventual migration when the tool is outgrown. Custom software has a higher upfront cost and an ongoing maintenance cost, but no per-seat scaling and no forced migration on someone else's timeline. Neither model has a universally "correct" number — the right way to compare them is workflow by workflow, not as a blanket policy.
A build-vs-buy decision framework
A practical way to work through it, workflow by workflow:
- Is this workflow genuinely specific to how the business operates, or is it a solved, generic problem? Generic → SaaS.
- Does a SaaS product exist that fits it without heavy workarounds? If yes → SaaS. If the fit requires a growing list of manual workarounds → reconsider.
- Is this workflow core to the business's competitive position, or purely operational overhead? Core → custom software earns its cost faster.
- Would the business rather adapt its process to the tool, or does the tool need to adapt to the business? If the business can't adapt without losing something real, that's a build signal.
| Factor | SaaS fits better | Custom software fits better |
|---|---|---|
| Workflow type | Generic, industry-standard | Specific to this business |
| Permissions | Simple roles (admin/member/viewer) | Multi-party, document- or feature-level |
| Integrations | One or two, well-supported | Several, or the tool must own the data flow |
| Data sensitivity | Low to moderate | Regulated, competitive, or core IP |
| Cost shape | Predictable per seat, scales with headcount | Higher upfront, flatter ongoing cost |
| Time to adopt | Days | Weeks to months |
Example: a legal document automation platform
A useful illustration from LFT's engineering work is a secure platform built to automate legal and business document generation and controlled distribution to client accounts. This is a workflow that doesn't fit a generic e-signature or document-storage SaaS product cleanly: it needed business-specific document generation rules, role-based access controlling exactly who could see which documents, and controlled distribution logic tied to client accounts — not just file storage with sharing links. A generic tool could have handled parts of this (storage, maybe signing) but not the rules connecting them, which is where the custom build earned its cost.
Start with the workflow, not the category
"Should we build custom software or use SaaS" isn't a company-wide decision — it's a per-workflow one. Most businesses end up with both: SaaS for the generic operational layer, and one or two custom systems for the processes that are actually specific to how they compete. The workflows worth examining first are the ones already surrounded by manual workarounds — that's usually where the real cost of staying on SaaS is hiding.