- Why "It Depends" Is Not a Non-Answer
- Typical Phase Breakdown for a Mid-Size Custom Project
- Total Realistic Timeline by Project Type
- What Actually Causes Delays
- The Bilingual and Compliance Factor for Canadian Projects
- How to Pressure-Test a Vendor's Timeline Estimate
- FAQs
- Set the Timeline Before You Set the Budget
You have a defined project, an approved budget, and a deadline that's already generating pressure from above. The question your executive team keeps circling back to is simple: how long will this actually take?
It's a fair question. The honest answer is that it depends on factors most vendors gloss over in their initial pitch. This article breaks down what drives a software development timeline, what realistic phases look like for the kinds of projects mid-size Canadian organizations typically commission, and where timelines go wrong before a single line of code is written.
Why "It Depends" Is Not a Non-Answer
Custom software isn't something you pull off a shelf. The timeline for a customer portal at a telecom carrier looks structurally different from a back-office claims system at an insurance company, which looks different again from a public-sector workflow tool that requires bilingual delivery and data-residency compliance.
Three variables shape your timeline more than anything else:
- Scope clarity at kickoff. Projects with a defined problem statement and documented requirements move faster. Projects that start with a vague mandate spend the first six to eight weeks in discovery regardless of what the contract says.
- Integration complexity. Connecting to an existing CRM, ERP, or payment platform adds time. Every third-party API introduces its own negotiation: their documentation, their sandbox environment, their release schedule.
- Compliance and approval layers. Regulated industries and public-sector procurement add review cycles that aren't optional. A provincial government agency may require security assessments, accessibility audits, and bilingual content reviews before any feature ships to production.
Knowing how these variables interact is what separates a realistic timeline from a number that sounds good in a proposal.
Typical Phase Breakdown for a Mid-Size Custom Project
For a project in the CAD 150,000 to 600,000 range, here is how the phases tend to distribute across time. These are realistic ranges, not best-case scenarios.
Discovery and Product Strategy: 3 to 6 Weeks
This phase defines what you're actually building. It includes stakeholder interviews, current-state mapping, requirements documentation, and architecture decisions. Compressing or skipping it is the single most common cause of scope creep later in the project.
For regulated industries, discovery also surfaces compliance requirements early. If your project needs to meet Quebec's Law 25 or federal bilingual obligations, those constraints need to shape the architecture from the start — not get retrofitted at the end.
Design and Architecture: 3 to 5 Weeks
UI/UX design, data modelling, API contract definitions, and infrastructure planning all happen here. For projects with complex integrations, architecture often runs in parallel with discovery rather than sequentially.
This is also where tech stack decisions get finalized. Choosing .NET 8 and Angular, for example, has downstream implications for your DevOps pipeline, your cloud configuration, and your long-term maintenance model.
Development: 10 to 20 Weeks
Development is where the timeline spread is widest, because scope varies most here. A focused customer portal with three to five core workflows lands closer to ten weeks. A back-office system with ERP integration, role-based access control, and reporting dashboards lands closer to eighteen to twenty.
Agile delivery means working software ships in two-week sprints. You should be seeing functional features in a staging environment by week four of development — not waiting until the final stretch to see anything at all.
QA and Testing: 3 to 5 Weeks
Testing runs alongside development in well-run projects, but dedicated QA cycles for regression testing, performance testing, and accessibility audits add time at the end. For public-sector projects, this phase often includes third-party security assessments.
Deployment and Hypercare: 2 to 4 Weeks
Cloud deployment, CI/CD pipeline configuration, go-live support, and the immediate post-launch stabilization period. For projects using Azure DevOps and Docker Compose, a well-configured pipeline shortens this phase considerably. Hypercare is the window where the team stays close to production to catch issues before they become incidents.
Total Realistic Timeline by Project Type
| Project Type | Realistic Timeline |
|---|---|
| Customer portal (moderate complexity) | 5 to 7 months |
| Back-office system with ERP integration | 7 to 10 months |
| Workflow automation tool | 4 to 6 months |
| Full platform with API integrations and bilingual delivery | 9 to 14 months |
These ranges assume a vendor with real domain experience in your industry. A team that has never built for telecom or insurance will spend weeks learning domain rules that an experienced team already knows. That learning time doesn't disappear from your timeline — it just shows up as delays.
What Actually Causes Delays
Most timeline slippage doesn't come from technical problems. It comes from process problems.
Unclear ownership on the client side. If your team doesn't have a designated decision-maker who can approve designs and sign off on requirements within a defined window, every review cycle adds days. Across a six-month project, that adds up fast.
Scope additions mid-project. A feature that seems small often touches more of the system than it appears to. Adding a new report, a new user role, or a new integration after development has started carries a real time cost.
Third-party dependencies. Waiting on a vendor to provision a sandbox environment or update their API documentation is outside your control and outside your vendor's control. The best mitigation is identifying all third-party dependencies during discovery and starting those conversations early.
Compliance reviews scheduled too late. Security assessments and accessibility audits take time. Planning them at the end of development rather than building them into the schedule from the start will push your go-live date.
The Bilingual and Compliance Factor for Canadian Projects
This point deserves its own section because it's consistently underestimated.
If your project serves Quebec users or falls under federal bilingual requirements, bilingual delivery is not a translation task you add at the end. It affects your content model, your UI component library, your testing scenarios, and your QA process. A vendor who treats it as an afterthought will hand you a product that fails compliance review.
The same applies to Canadian data-residency requirements. If your data must stay within Canadian borders, that shapes your cloud architecture from day one — it's not a checkbox you tick before launch.
At Hamdi Services, bilingual delivery and Canadian data residency are built into the project structure from discovery. These are defaults, not add-ons. For Quebec public-sector mandates and federal bilingual obligations, that distinction matters to both your timeline and your compliance posture.
How to Pressure-Test a Vendor's Timeline Estimate
When a vendor gives you a timeline, ask these questions:
- What assumptions is this estimate based on? A credible answer references scope, integration count, and compliance requirements. A vague answer is a warning sign.
- When will I see working software? If the answer is "at the end," walk away. Agile delivery means functional increments throughout the project, not a big reveal at the finish line.
- How do you handle scope changes? Every project has them. A vendor without a clear change-management process will either absorb scope quietly and slip the timeline, or fight every change request.
- What third-party dependencies have you identified? This question reveals whether the vendor has done real discovery or is estimating from a template.
- What does your QA and deployment phase look like? Vague answers here usually mean those phases are underestimated in the timeline.
FAQs
How long does a custom software project take from first meeting to go-live?
For a mid-size project in the CAD 150,000 to 600,000 range, a realistic timeline from first discovery call to production deployment is five to ten months, depending on scope, integration complexity, and compliance requirements. Projects with heavy ERP integrations or bilingual delivery obligations tend toward the longer end.
What is the most common reason custom software projects run late?
Unclear requirements at the start and scope additions mid-project are the two most common causes. Compliance reviews and third-party API dependencies scheduled too late in the process are close behind.
Can you build custom software faster by skipping the discovery phase?
Compressing discovery saves weeks at the start and typically costs months at the end. Requirements that were never properly defined get discovered during development, which is the most expensive time to find them.
How does bilingual delivery affect the project timeline for Canadian organizations?
Bilingual delivery affects your content model, UI components, and QA process. When treated as a translation task added at the end, it typically adds two to four weeks and risks compliance failures. When built into the architecture from discovery, the impact on timeline is minimal.
What should I expect during the hypercare period after launch?
Hypercare is the two to four weeks immediately after go-live where the development team monitors production closely, resolves issues that surface under real load, and supports your internal team in operating the new system. It's distinct from long-term support.
How do I know if a vendor's timeline estimate is realistic?
Ask what assumptions underlie the estimate, when you'll see working software, and how they handle scope changes. A credible vendor ties the timeline to specific scope and integration decisions — not to a generic template.
Does working with a vendor who knows my industry actually shorten the timeline?
Yes, meaningfully. A team that has already built for telecom, insurance, or the public sector doesn't spend the first weeks learning your domain rules, compliance requirements, or integration patterns. That prior knowledge compresses discovery and reduces rework during development.
Set the Timeline Before You Set the Budget
A timeline isn't a number a vendor produces after a thirty-minute call. It's the output of a real discovery process that accounts for your scope, your integrations, your compliance obligations, and your internal capacity to make decisions.
If you're planning a customer portal, back-office system, or workflow automation tool and want a timeline grounded in the specifics of your project, start a discovery call with Hamdi Services. The first conversation is about your problem, not our pitch.