The framework that actually matters.
Most custom-vs-SaaS arguments are religious wars between consultants who only sell one option. We sell custom — and we'll happily tell you when SaaS is the better answer for your specific situation. The decision is structural, not aesthetic.
Below: a clean decision framework, an honest comparison of the trade-offs, and three scenarios that cover most real-world business situations.
The trade-offs nobody tells you up front.
Both options have real strengths and real weaknesses. The honest comparison:
| Dimension | Off-the-Shelf SaaS | Custom Software |
|---|---|---|
| Time to first useful value | Days to weeks | 12-16 weeks for v1 |
| Year-1 cost | Lower (subscription) | Higher (build cost) |
| Year-3+ total cost (per-seat scale) | Scales linearly with users | Relatively flat |
| Fit to your specific workflow | 70-80% — workarounds for the rest | Built around how you actually run |
| Integration to your existing stack | Available via marketplace, often paid | Designed in from day one |
| Vendor lock-in | Data export rarely complete; migration is painful | Source code yours; data yours; portable |
| Pricing changes & feature loss | Vendor's roadmap, not yours | Your roadmap, your pace |
| Bug fixes & feature requests | "Submitted to product team" | Same team that built it |
| Industry-specific functionality | Generic by design | Industry-shaped from discovery |
| Hardware integration (weighbridges, scanners, IoT) | Rarely supported | Designed for it |
| Compliance documentation (POPIA, audit) | Vendor-provided baseline | Tailored to your specific regulator |
| Total ownership of IP | No — you're a tenant | Yes — code, data, IP are yours |
| Speed of change when business shifts | Wait for vendor roadmap | Two-week sprints; ship when ready |
| Risk if developer disappears | Vendor has thousands of customers | Real risk — needs mitigation in contract terms |
| SA-resident data (POPIA geography) | Often offshore by default | Hosted in our SA data centre |
Three scenarios. Which one is yours?
Stay on SaaS / pick a SaaS product if:
An off-the-shelf product covers 80%+ of what your business needs, the missing 20% isn't a competitive differentiator, your industry has well-established SaaS leaders, your team-size is small enough that subscription pricing is comfortable, and the workarounds for the gap are tolerable. SaaS is the right answer for most generic business functions — accounting, email, basic CRM, helpdesk. Don't custom-build what already exists.
Build custom if:
Your operation has a workflow that off-the-shelf doesn't fit (yard management, weighbridge integration, niche industry processes); your business runs on hardware that needs integration (scanners, sensors, biometrics, IoT, NVRs, specialised industrial equipment); compliance requirements exceed what SaaS provides out of the box; you've outgrown your accounting package but don't want a six-figure ERP rollout; or the "20% off-the-shelf misses" is exactly the operational edge you compete on. Custom pays back through fit, integration, control, and IP ownership.
Neither — keep the spreadsheet — if:
The process is small (under 20 transactions a day), one or two people use it, no audit pressure exists, and the workarounds aren't actively costing time or money. Spreadsheets are real software. They have failure modes (Janine's laptop, no audit trail, version chaos) but for genuinely small workflows, they outperform both SaaS and custom. We'll tell you when this is the right answer and decline the work.
Custom vs SaaS questions.
How long does custom software development take?
Most of our custom builds ship a usable v1 in 12-16 weeks. Discovery is week 1-2, architecture is week 3-4, build runs in two-week sprints from week 5, real-site pilot is week 13-14, cutover is week 15-16. Phased rollout to additional sites or modules continues from there. Faster than most clients expect — slower than "a SaaS subscription you sign up for today."
Is custom software more expensive than SaaS?
Year one — almost always. Year three or four — often not, depending on team size and use case. SaaS pricing typically scales linearly with users; custom software is a fixed build cost plus relatively flat hosting/support. The crossover point depends on your specific economics. We'll model it honestly on a discovery call.
Who owns the IP on custom software you build?
You do. The code is yours, the data is yours, the IP is yours. We host it because we're good at it — not because we hold it hostage. You can leave any day. Most don't, because the relationship works — but the option is real.
What if SaaS does 80% of what we need?
Then SaaS is probably the right call. Custom software earns its place when the gap matters operationally — when the 20% it doesn't do is the 20% your business actually competes on. If the workarounds are tolerable and the missing features aren't strategic, stay on SaaS. We'll tell you that on the call.
Can you build custom software that integrates to existing SaaS we already use?
Yes. Most of our custom builds integrate to something already in place — accounting (Pastel, SAP, Sage, Xero), Microsoft 365, CRM platforms (Salesforce, HubSpot), logistics carriers (DHL, Aramex, Courier Guy), and industry-specific tools. API-first architecture means our custom work plays nicely with the rest of your stack.
What happens if our custom developer disappears?
It's the most common SaaS-vs-custom argument and it's a fair one. Our answer: same team builds and supports — no handover from delivery to ongoing support. Source code is yours from day one. Documentation is maintained. .NET 8 and SQL Server are mainstream platforms with broad SA developer hire-ability. The risk is real — we engineer to mitigate it.
Talk to us.
Book a 30-minute demo and we'll show you Swiss Systems on a real workload.