SaaS is great for commodity processes. It's terrible for the things that make your business unique.
Every SaaS product is built for the average use case across thousands of customers. When your process is average, SaaS is perfect. When your process is what differentiates you from competitors, or when it's shaped by industry-specific regulations, or when it's evolved organically over years to fit your actual operations, SaaS becomes a straitjacket.
The symptoms show up gradually. Custom fields that don't quite capture what you need. Workflows that require three extra steps because the tool doesn't support your actual process. Reports that are "close enough" but never exactly right. An export-to-Excel step that shouldn't exist. At some point, the cost of forcing the tool to fit exceeds the cost of building something that fits naturally.
The answer isn't always "build custom." It's knowing the difference between processes that are commodity (use SaaS) and processes that are competitive advantage (build custom). The companies that get this distinction right build faster, operate more efficiently, and don't spend their engineering budget on Salesforce workarounds.
The four ways off-the-shelf tools fail mid-market companies.
Not every SaaS failure means you need to build custom. But these patterns are clear signals that the tool is holding you back more than helping you.
Process contortion
You've changed how your team works to fit the tool instead of the tool fitting how your team works. The operations team adds extra steps. The sales team uses fields for purposes they weren't designed for. Everyone has adapted, but nobody's happy, and the inefficiency compounds.
Integration dead ends
The SaaS tool's API doesn't support the data you need to push or pull. The Zapier integration breaks when anything changes. You need real-time data flow but the tool only supports batch exports. The integration gap forces manual workarounds that defeat the purpose of using the tool.
Escalating costs without escalating value
Per-seat pricing made sense at 20 users. At 200, you're spending more on SaaS licenses than you'd spend building and maintaining a custom tool that does exactly what you need. And the enterprise tier they're trying to upsell you to still doesn't have the feature you actually need.
Vendor dependency and data lock-in
Your data is trapped in the vendor's format, in the vendor's cloud, and behind the vendor's API limits. If they raise prices, change their product direction, or get acquired, your options are limited. The switching cost grows every month you stay.
Build what's unique. Buy what's commodity. Integrate everything.
The smartest companies don't build everything or buy everything. They build the software that supports their competitive advantage and buy SaaS for everything else.
Separate commodity from competitive
Which of your processes are truly unique to your business? Which are standard operations every company in your industry runs? SaaS for the standard stuff. Custom for the stuff that makes you, you. Getting this distinction right saves hundreds of thousands in misallocated investment.
Design the custom application
Build for the actual process, not the tool's idea of your process. Proper data models, role-based access, the workflows your team actually follows, and the reports they actually need. Designed from the start to integrate with the SaaS tools you're keeping.
Build with integrations from day one
The custom application pulls from Salesforce, pushes to NetSuite, and syncs with the warehouse. It doesn't replace everything. It fills the gap where SaaS failed, connected to the tools that still work. This hybrid approach gives you the best of both worlds.
Migrate and decommission
Move the data out of the old tool, transition users to the new system, and cancel the license. The best part of replacing a SaaS tool that doesn't fit: the monthly license payment becomes development ROI, and you never have to email their support team again.
Questions from operations leaders considering custom software.
When should I build custom instead of using SaaS?
Build when: the SaaS requires more workarounds than it eliminates, the process is a competitive differentiator, you need integrations the vendor doesn't support, licensing costs exceed build costs at your scale, or you need control over data and IP. Keep SaaS for commodity processes where your business isn't meaningfully different.
How much does custom business software cost?
It depends on scope. We scope the real number in a Product Design Sprint ($40K-$75K, 2-4 weeks) before any build commitment. On timeline, a focused internal tool replacing one SaaS tool runs 6-12 weeks. A complex operational platform runs 3-6 months.
What are the risks of building custom vs buying?
Custom risks: maintenance responsibility, longer initial setup, and scope creep. SaaS risks: process contortion, vendor lock-in, escalating costs, limited integrations, and data portability issues. The right answer depends on whether the process is commodity or competitive advantage.
Can a custom app integrate with our existing SaaS tools?
Yes, and this is the most common pattern. Build custom for what's unique, keep SaaS for what's commodity, and integrate everything. A custom operations platform pulling from Salesforce, pushing to NetSuite, and syncing with your warehouse is a typical MiT engagement.
Great fit
- SaaS tool requires more workarounds than it eliminates
- Business process is a competitive differentiator, not commodity
- Need integrations the SaaS vendor doesn't support
- Licensing costs at your scale exceed the cost of building
- Need control over data and IP that SaaS doesn't provide
Not the right fit
- Process is truly commodity (email, basic CRM, and accounting)
- SaaS tool works well but users need more training
- Problem is data integration, not the application itself
- Budget or timeline doesn't support a custom build
Ready to build software that actually fits?
Start with a sprint to validate the approach, or go straight to the build.