The SaaS you bought can't answer the security questionnaire a federal contract in Ottawa demands
When generic SaaS can't survive a federal procurement and security review, custom software in Ottawa typically runs $60k to $300k over 3 to 10 months depending on scope. Off-the-shelf SaaS isn't inferior software; it's built for a market that never has to answer an ITSG-33 questionnaire, prove Protected B handling, or ship WCAG-compliant interfaces, which is exactly what selling into the federal government requires.
You adopted a popular SaaS product because it covered 80 percent of what you needed. Then a federal opportunity arrived with a security questionnaire, an accessibility requirement, and questions about data residency the vendor's support team couldn't answer. The 80 percent fit doesn't matter when the missing 20 percent is the part procurement actually scores.
This is the Ottawa pattern that catches firms by surprise: commercial SaaS optimizes for fast onboarding and broad appeal, not for the controls a federal department demands. You can't bolt Protected B handling, an immutable audit trail, or bilingual accessible UI onto someone else's closed product. At some point the only way forward is software you control.
Budgeting a custom software build in Ottawa
| Project scope | Typical cost | Timeline |
|---|---|---|
| Focused single-purpose application | $60k to $120k | 3 to 5 months |
| Multi-module platform with security controls | $120k to $210k | 5 to 8 months |
| Enterprise build with Protected B handling and bilingual UI | $200k to $300k | 7 to 10 months |
The case for owning your custom software
Custom software lets the controls that win federal contracts be part of the architecture. You design the data boundary, audit trail, accessibility, and bilingual UI to pass the exact reviews your contracts require, instead of hoping a SaaS vendor's roadmap eventually reaches them. For an Ottawa firm whose growth depends on procurement, that control is the difference between bidding and watching.
- A federal procurement requires controls no SaaS product can demonstrate
- Accessibility or data-residency gaps in your SaaS are blocking contracts
- Your process is unusual enough that no off-the-shelf product fits
- You need an audit trail a closed product can't provide
- An off-the-shelf product covers your needs and the security bar is low
- Your buyers are commercial and never run a procurement review
- Time-to-market beats control for your current stage
- You lack the team to maintain custom software long-term
What your build should include
What we build under custom software in Ottawa
Everything a custom software build here can cover: MVP development, legacy modernization, systems integration, microservices, database design and bespoke software development.
Delivery, week by week
Exactly what you get
Software designed around the reviews it has to pass. You get a data boundary and encryption to Protected B expectations, an immutable audit trail, WCAG 2.1 AA accessible interfaces, bilingual English-French UI, and access control aligned to clearance levels. It integrates with your ERP, CRM, and internal tools through a clean API instead of a SaaS connector you rent by the seat.
How to choose a developer in Ottawa
Hire the firm that starts with your procurement requirements, not its preferred stack. The right Ottawa partner asks which security and accessibility reviews the software must clear, runs a real discovery phase to control scope, and has shipped through a federal gate before. Ask for a reference where their build passed a departmental review, and pin down who owns maintenance and patching afterward.
- Built to pass the specific security and accessibility reviews your contracts require
- Data boundary, audit trail, and encryption designed in, not retrofitted
- WCAG 2.1 AA and bilingual UI as architecture, so they don't block procurement
- You own the roadmap, so the next contract's requirement is a sprint, not a vendor request
- Clean integration with your ERP, CRM, and internal tools without a SaaS connector tax
- Higher upfront cost than a SaaS subscription you can expense monthly
- You own all maintenance, security patching, and uptime
- Build time means living with the gap while it's developed
- Scope creep is a real risk on open-ended custom projects without tight discovery
- !They start with technology before understanding your procurement requirements; ask which reviews the software must pass
- !No discovery phase; ask how they prevent scope creep on an open-ended build
- !Accessibility and bilingual UI are line items at the end; ask how they're built in from the start
- !They've never shipped through a federal security review; ask for a relevant reference
- !No plan for who maintains and patches it; ask about post-launch ownership
If custom software is on the roadmap, website, inventory management, warehouse management usually follow within the year. Budget them as one conversation.
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
When is custom software actually worth it over SaaS?
When the gap between off-the-shelf and your needs is the part procurement scores: security controls, accessibility, data residency, audit trails. If SaaS covers those and you just want polish, stay on SaaS. If it can't answer the federal questionnaire, custom is often the only path that wins the contract.
How do I keep a custom build from sprawling?
Insist on a real discovery phase that defines the controls and scope before any code. The biggest cost overruns in Ottawa custom builds come from open-ended scope, not technical difficulty. A partner who can't articulate a tight phase plan is a risk worth avoiding.
Can't I add the missing controls to my existing SaaS?
Rarely, because the controls that matter (immutable audit trails, data residency, Protected B handling) are architectural, and you don't control a SaaS vendor's architecture. You can sometimes wrap a SaaS in additional layers, but a security assessor evaluates the whole stack, including the parts you can't change.
How much does the security and accessibility work add?
Together they're often the majority of the budget for federal-facing software in Ottawa. Protected B data handling, WCAG 2.1 AA accessibility, and bilingual UI are the costliest pieces, and also the ones that decide whether you pass procurement. They're rarely the place to economize.
Who maintains custom software after launch?
You do, or a partner you retain. That includes security patching, OS and dependency updates, and responding to new review requirements. Budget for ongoing maintenance from the start; abandoned custom software fails its next security review just as surely as outdated SaaS.