Custom Business Software in Ontario: What to Settle Before You Build

Most custom software conversations start with features. The expensive surprises usually come from somewhere else: a client portal that has to meet accessibility standards, a job-tracking app that quietly becomes your accounting record, or a developer who hosts your data in a region your accountant didn’t expect. We build custom web applications for Ontario businesses, and this is the checklist we wish more owners had before they asked for a quote.

I’m Adan Silva, Partner and Software Development Lead at ACT360. If you’re still deciding whether to build at all, start with our guide to custom web applications vs off-the-shelf software. This article assumes you’re leaning toward building and want to know what’s specific to doing it here.

Custom business software is an application built for one organization’s process instead of bought as a product. For most Ontario businesses with 10 to 200 staff, that means a web-based tool your team or your customers use in a browser.

Typical examples we see requested:

• Client portals where customers check status, upload documents or approve work
• Booking and scheduling systems with rules a generic calendar can’t handle
• Integration layers. Small services that pass data between a CRM, an accounting package and an operations tool so nobody re-keys it.
• Internal dashboards that pull numbers from several systems into one screen
• Field and inventory tools, often running on phones or tablets

It rarely means replacing everything. More often it’s one tool sitting beside the software you already pay for. Whether to customize your existing platform or build your own tool is usually the first fork in the road.

Four sets of rules come up most often: Ontario’s accessibility standard for web content, federal privacy law (PIPEDA), CRA’s record-keeping rules, and Ontario’s electronic monitoring policy requirement. Which ones apply depends on who uses the software and what it stores.

The sources, so you can check them yourself: Ontario’s guide on how to make websites accessible (which notes that web content includes web applications), the Office of the Privacy Commissioner’s guidelines for processing personal data across borders, CRA’s page on where to keep records and for how long, and the Ministry of Labour’s guide to the electronic monitoring policy.

If you’re a clinic or another health information custodian, PHIPA adds its own obligations on top; our page on PHIPA compliance for healthcare practices covers that side. None of this is legal advice, and we’d always suggest a lawyer reviews contract terms. But a developer who has never heard of these rules is a warning sign.

Yes, more than most owners expect. If the software holds your business records, CRA treats records stored outside Canada as kept outside Canada even when you open them from here, and keeping them there needs CRA’s written permission.

That line is on CRA’s record-keeping page: “Records kept outside of Canada and accessed electronically from Canada are not considered to be records kept in Canada.” Plenty of low-cost hosting defaults to US data centres, so ask before anything is set up.

Hosting in Canada is straightforward. Microsoft Azure, for example, runs a Canada Central region in Toronto and Canada East in Québec. Keeping the application and its database in a Canadian region also makes privacy conversations with your own clients simpler, because you can answer “where is our data?” in one sentence.

Two more hosting questions worth asking: whose account is the hosting under (it should be yours), and who pays for and applies security updates after launch. Our cloud migration team handles the hosting side for clients who’d rather not run it themselves.

Each option can work. The right one depends on how long the software has to live, how much it touches regulated or sensitive data, and who will maintain it once the original builder moves on.

The wage figure comes from Job Bank’s Ontario wage data for software developers and programmers. Whichever route you choose, get the code, the documentation and the admin accounts in your name. The best team in the world is still a risk if only they can get into the system.

Sometimes, but less often than owners hope. Building a business application with known methods usually isn’t eligible. SR&ED is for work that resolves a genuine technological uncertainty, and the Ontario Innovation Tax Credit only follows eligible SR&ED spending.

CRA’s SR&ED eligibility guidelines are direct about it: if you “circumvent it with a workaround using available knowledge, then the work will not be eligible.” Programming is listed as support work, which doesn’t qualify on its own.

For the cases that do qualify, Ontario’s Ontario Innovation Tax Credit is a refundable 8% credit for qualifying corporations doing the research in Ontario, with eligibility phasing out as taxable income and capital rise. Our advice: talk to your accountant or an SR&ED specialist before the project starts, not after, because the evidence has to be kept as the work happens. Don’t build the business case around a credit you might not get.

The builds that go well start with the process, not the screens. Here’s one we did for an Ontario organization running government-funded health and fall prevention programs across more than 50 locations.

Their scheduling and compliance platform was a custom Drupal 7 system more than a decade old. More than 30 physiotherapist assistants ran over 200 classes a week through it, reports took minutes to load, and attendance could be entered days after a class, which caused payroll disputes and compliance risk.

We rebuilt it on Laravel with Azure-based security: role-based permissions, two-factor authentication and identity checks. Ten years of program records were cleaned and migrated so nothing was lost. Attendance can now only be logged within a defined 10-minute class window. According to the client, reporting is now near instant, payroll disputes have decreased and compliance risk is lower. The full write-up is in our platform modernization case study. We didn’t measure time saved in dollars, so we won’t invent a number.

The lesson that carries over: the attendance window was a business rule, not a technical feature. It only made it into the software because the team spent time on how the work actually happened before anyone designed a screen.

Before you sign, get clear written answers on ownership, hosting, records, accessibility and support after launch. These seven questions cover the points that most often cause trouble in Ontario builds, and any serious developer should be able to answer them quickly.

1. Who owns the source code, the database and the hosting accounts? The answer should be you.
2. Where will the application and its data be hosted, and in which country?
3. If it holds financial records, can it keep six years of data and show an audit trail?
4. Is any part of it customer-facing, and will that part meet WCAG 2.0 AA?
5. Does it log user activity or location? Then your electronic monitoring policy may need an update.
6. Who applies security updates after launch, how fast, and what does that cost per month or year?
7. What documentation and training do we get, so we’re not dependent on one person?

If the business case is still fuzzy, our article on why a custom business system can be worth the investment covers where the payoff usually comes from.

We start with the Assess and Comprehend steps of our ACTION approach: how work moves through the business, where it stalls and why it was set up that way. Sometimes the answer is configuration of a product you already own. When a build does make sense, we scope it to the workflow, host it where it fits your obligations, and include handoff and training so the finished application is yours to run.

Because the same team handles IT for many of our clients, we already know their Microsoft 365 setup, security policies and backups before the app conversation begins. That avoids building something that clashes with the rest of the environment. Businesses near our office can see local work on our custom web application development in Barrie page.

The code is rarely what goes wrong with custom business software in Ontario. What goes wrong is everything around it: hosting nobody chose deliberately, records that can’t be produced for CRA, a portal that has to be rebuilt for accessibility, or an app only its original developer can touch. Settle those questions first and the build itself gets simpler.

If you’d like a second set of eyes on a process you’re thinking of building around, book a free consultation with our development team. You can also call 705-739-2281 or email [email protected].