If you run a business in Canada and you're hiring a developer somewhere else to build your customer portal, the question underneath all the others is usually this: where will my customers' data actually sit? The honest answer is that it sits wherever you point the hosting, not wherever the developer sits. Database region, file storage region and backup region are configuration choices made in the first hour of a build. A team in Toronto can quietly host your portal in Virginia. A team on another continent can host it in Montréal. What changes with distance is not the location of the data. It's the rhythm of the work, the paper trail you ask for, and how carefully the handover gets planned. Your obligations to your customers under Canadian privacy rules stay yours either way, so treat the decisions below as business decisions, and have your own lawyer read the agreement before you sign it.
Why a portal raises questions a website doesn't
Your marketing site holds a contact form and some photos. A customer portal holds the filing cabinet. Depending on what you do, that can mean:
- Invoices, payment history, and sometimes a stored payment token
- Signed estimates, contracts and permits
- Job and service history tied to a home address
- Photos taken inside a customer's house or shop
- Notes your staff wrote assuming the customer would never read them
That last one surprises people. The day you give customers a login, internal notes become semi-public unless you decide, field by field, what renders in a browser. An auto shop with a job note that reads "difficult customer, don't bother upselling" now has a design decision on its hands. So the first real conversation about a portal isn't about hosting at all. It's about which fields a logged-in customer sees, which ones only staff see, and which ones never leave your internal system.
Pinning the data to a Canadian region
Every major cloud platform offers Canadian regions. Montréal and Toronto are the common ones, with others available. Picking one is a dropdown at setup time and genuinely annoying to change later, which is the practical reason to decide in week one rather than month six.
Whether Canadian residency is required for you, or merely preferred, depends on your sector and your province. Firms working with public bodies, schools or health information tend to face stricter expectations than a landscaping company does. That's a question for your counsel, not your developer. But either way, write the region into the written scope rather than settling it on a kickoff call, and then verify it yourself once a staging environment exists. You should be able to sign into the hosting account and read the region off the dashboard. If you can't sign in, that's a bigger problem than geography, and the handover section below is about exactly that.
The parts that quietly leave the country
Teams pin the database to a Canadian region and assume they're done. The database is rarely the whole picture. Ask specifically about:
- Backups and snapshots. Often a separate region setting from the database itself.
- Error tracking and logs. An error report can include a customer's name, email, or the contents of the form they just submitted.
- Transactional email. Password resets and invoice notices pass through an email provider that stores the message body.
- File and document storage. PDFs and uploads frequently live in a different bucket than everything else.
- Analytics and session replay. Session replay behind a login records whatever is on screen, invoices included. The simplest answer is not to run it inside the portal.
- Payments. Your processor decides where card data lives. Ask about Canadian processing and settlement in CAD while you're at it.
- Helpdesk tools and chat widgets, which usually see the logged-in user's details.
- The developer's own laptop. The most common leak anywhere is a copy of production data pulled down for debugging. Ask for anonymised seed data instead, and for a plain rule that live customer records never land on a local machine.
Access matters as much as location. Named accounts rather than one shared login, two-factor on everything, the smallest permission set that lets someone do the job, and access removed the week a project ends. For a portal, also ask for a record of which staff member opened which customer file. If a customer ever asks who looked at their account, you want an answer that isn't a shrug.
Working across a four-to-eight hour gap
Canada runs from Newfoundland to British Columbia, so "remote" already means something to you. A provider in Europe overlaps with your morning. One in the Asia-Pacific region overlaps with almost nothing unless somebody shifts hours. Two hours of genuine overlap per day is plenty, as long as the habits are right:
- A staging URL that is always current, so you review the working thing instead of screenshots.
- Decisions recorded in writing, in a thread you can search in eight months.
- Batched feedback. One list of fourteen items moves faster than fourteen messages.
- A standing weekly call booked in your time zone with the zone spelled out, as in "Thursdays 10:00 ET". Vague times are how the daylight-saving changeover weeks get lost.
- An agreed answer to who can unblock a small decision while you're asleep, and what counts as small.
This is the normal case rather than the exception at WebShift Studios: two developers, everything delivered remotely, and the written trail that makes a time difference boring.
Money, ownership and the handover
Paying across the border
Ask for the build quoted in one currency and stated plainly. If the quote is in USD and you budget in CAD, the exchange rate moves between the deposit and the final invoice, so agree up front who absorbs that. Cross-border wires and card payments carry their own fees. Recurring costs are the part people forget: hosting, email delivery and error tracking are usually billed in USD even when the servers sit in Montréal, so your monthly running cost floats with the rate regardless of where the data lives. Ask for those recurring items listed separately, in their native currency, so you can see which numbers are fixed and which aren't. How sales tax applies to services bought abroad is a question for your accountant.
What you should hold at the end
- Code in a Git repository owned by your company's account, from the first commit
- Hosting, database and email accounts in your business name, with you as owner and the developer invited as a collaborator
- Domain and DNS at a registrar you control
- A backup restore someone has actually performed, not just a backup that exists
- A short written runbook: how to deploy, how to rotate keys, how to restore, what tends to break first
- Clear contract language that the custom code is yours, with any third-party licences named
The test for all of it is simple. Could a different developer clone the repository and run your portal locally without emailing anyone for a secret? Ask for that walkthrough before the final payment, not after.
Where to start
Before you talk to any provider, write down the five things a customer should be able to see without phoning you. Invoice history. Current job status. The estimate they signed. Their next appointment. Somewhere to upload a document. That list is your portal, and it's also what keeps the budget honest, because everything past it is phase two.
Bring that list, your hosting region preference and your handover expectations to whoever you hire. If you'd like a second opinion on any of the three, get in touch through our business systems page and tell us what your customers call you about most. Canadian clients are routine for WebShift Studios, and nothing about this work needs us in the room.