Enterprise Software Development Company in Vancouver

A privacy impact assessment, conducted during development rather than before launch. The definition sits in Schedule 1 of FIPPA, not in the operative section: a privacy impact assessment is an assessment conducted by a public body to determine whether a current or proposed enactment, system, project, program or activity meets or will meet the requirements of Part 3 of the Act. Section 69(5) requires the head of a ministry to conduct one in accordance with ministerial direction, and section 69(5.3) extends that obligation to the heads of public bodies that are not ministries, which covers health authorities, Crown corporations, universities and municipalities. Section 69(5.1) is the part that changes project sequencing, because it requires the ministry head to submit the assessment to the minister responsible for the Act for review and comment during the development of the system rather than after it. Separately, section 30 requires reasonable security arrangements against unauthorised collection, use, disclosure or disposal, section 36.2 requires every public body to develop a privacy management program under ministerial direction, and section 36.3 requires the head of a public body to notify affected individuals without unreasonable delay where a privacy breach could reasonably be expected to result in significant harm. Our practice is to draft the PIA alongside the architecture, so the data flows in the assessment and the data flows in the system are the same document rather than two documents that diverge.

The legal position changed in 2021 and it is widely misunderstood, so it is worth being precise. FIPPA formerly contained sections 30.1 and 30.2, which required public bodies to store personal information, and allow access to it, only inside Canada. Those sections were repealed by the 2021 amendments. So the blanket statutory prohibition that shaped a decade of BC public-sector architecture is gone. That is not the same as saying anything goes. Disclosure of personal information outside Canada is still governed by section 33 and its regulations, section 30 still requires reasonable security arrangements, and the privacy impact assessment under section 69 has to address cross-border processing explicitly. More practically, procurement has not moved as fast as the statute. Most health authority, Crown corporation and ministry contracts we see still specify Canadian regions, and many organisations have made in-Canada residency a policy commitment independent of what the Act now permits. Our default is therefore to design for Canadian regions, meaning AWS ca-west-1 in Calgary or ca-central-1 in Montreal, Azure Canada Central or Canada East, or Google northamerica-northeast1 or northamerica-northeast2, and to treat any offshore component as a decision requiring a written rationale.

Canadian dollars, tied to scope, and wide because the category is wide. A departmental system, meaning a single workflow with a defined user group, three or four integrations, a proper security model and an accessibility-conformant interface, generally runs CAD 250,000 to 700,000. An enterprise platform serving multiple business units with identity federation, a real integration layer, reporting and a migration off an existing system generally runs CAD 700,000 to 2,500,000. Multi-year legacy modernisation of a core system such as claims, permitting or asset management runs beyond that and should be governed as a programme with independently funded increments rather than as a single contract, because the failure mode of a large fixed-scope public-sector build is well documented. Ongoing support and evolution typically costs fifteen to twenty-five percent of build cost annually and should be budgeted from day one. Vancouver consulting rates are the highest in Canada, driven by the same talent competition that Amazon, Microsoft and SAP create locally. Delivering from Edmonton and Chandigarh is why the same scope prices lower with us. All work is fixed fee against a signed statement of work, with increments scoped so the client can stop after any one of them and still have something running.

As a build requirement in every sprint, not a pre-launch audit. The Accessible British Columbia Act was assented on June 17, 2021. It requires prescribed organisations to establish an accessibility committee that includes people with disabilities and Indigenous representation, to develop and publish an accessibility plan identifying, removing and preventing barriers, to review that plan every three years with public consultation, and to maintain a process for receiving public feedback on barriers. The Act also authorises regulations setting standards in areas including information and communications, service delivery, employment and procurement, which is the mechanism through which digital accessibility obligations tighten over time. Federally regulated organisations have parallel obligations under the Accessible Canada Act. Our engineering standard is WCAG 2.1 level AA, applied through semantic markup, keyboard operability tested without a mouse, visible focus states, colour contrast checked at design time, form errors announced to assistive technology, and accessible names on every interactive element. Automated checks run in the build pipeline and fail it. Automated checks alone are not sufficient, so we also run manual screen reader testing on the primary user journeys before each release.

We use the strangler pattern, which replaces a legacy system capability by capability while the original keeps running. The first step is not code, it is establishing what the system actually does, because on a system of that age the documentation and the behaviour parted ways long ago. We instrument the legacy application to observe real traffic, catalogue integrations and batch jobs, and extract business rules from the code itself where the rules exist nowhere else. Then we put a facade in front, so callers address a stable interface while routing decides whether a request goes to the old system or the new one. Capabilities move across in order of business value against risk, each one behind a feature flag, each one reversible. Data is the hard part, and we usually run a period of dual writes with an automated reconciliation job that compares both stores and alerts on divergence, rather than trusting a one-shot migration. Each increment is independently useful, so if funding, priorities or leadership change, the organisation is left with a working system rather than an abandoned half-build. Decommissioning of the legacy component is an explicit deliverable, otherwise you have paid to run two systems indefinitely.

Two things, and they are real enough to change the budget. The first is privacy. Quebec's Law 25 phased in obligations between September 2022 and September 2024, including designating a person responsible for the protection of personal information, mandatory reporting of confidentiality incidents and a register of them, privacy by default settings, assessments before transferring personal information outside Quebec, transparency when a decision is based exclusively on automated processing, and a data portability right that came into force in September 2024. The second is language. The Charter of the French Language, as amended by Law 96 which received assent on June 1, 2022, imposes French-language obligations on businesses operating in Quebec, and these reach software directly: where a French version of a program exists, the French version must be available, and commercial documentation, public-facing websites and interfaces carry corresponding requirements. In build terms that means designing for internationalisation from the first component rather than retrofitting, planning for professional translation rather than machine output, and testing layouts against French strings, which typically run longer than English and break fixed-width designs. None of this applies to a BC-only deployment, and we will tell you so rather than quoting for it.