Custom client and tenant portal software
A portal is the cheapest way to stop answering the same five questions by phone. It is also the easiest place in custom software to leak one customer's data to another.
Short answer
Build a portal when the same questions arrive weekly - balance, status, documents. Portals earn their cost through call deflection. The critical risk is access scoping: one query missing a tenant condition leaks data between customers. Builds start at $1,900.
On this page
- Build a portal when the same question arrives every week
- What belongs in one
- The mistake that matters: scoping every query
- Identity is harder than it looks
- Measure the calls before you build anything
- Adoption is the whole project
- Documents are the feature people actually use
- Notifications decide whether anyone returns
- Plan for the accounts that end
- What it costs
Build a portal when the same question arrives every week
Portals earn their cost through deflection. If your team fields the same enquiries repeatedly — what do I owe, when is my appointment, where is my document, what is the status of my request — each one is a phone call that a page could have answered.
The test is volume and repetition. A portal used twice a year will not be adopted; people will phone instead, and you will have both. A portal used weekly becomes the default channel within a couple of months.
What belongs in one
- Account status and balance, and a way to pay it
- Documents — leases, statements, invoices, reports — where the current version is obvious
- Requests and their status, which is the single biggest driver of "any update?" calls
- Messaging that keeps the history attached to the account
- Self-service updates: contact details, payment method, preferences
In property management specifically, maintenance requests with photos are the feature that justifies the build on its own. A tenant photographing the problem removes an entire diagnostic visit.
The mistake that matters: scoping every query
Every portal is a multi-tenant system, and multi-tenant systems fail in one characteristic way — a query that forgets whose data it is fetching. It is not exotic. It is one missing condition on one query, in code that looks correct and tests fine when you are logged in as yourself.
The consequences are severe and asymmetric: a single leaked statement is a privacy incident with reporting obligations under PIPEDA, and it destroys trust permanently. Portals therefore need access scoping enforced at the data layer rather than remembered by whoever writes each new feature, and they need testing as two different customers, not one.
The related trap is the file. Documents stored where the web server will hand them to anyone with the URL are exposed regardless of how good your login page is. Files belong outside the web root, served only after an access check.
Identity is harder than it looks
Real portals have messy identity. One person with two units. A company with several contacts. A tenant who moves out and whose access must end but whose records must not. A co-signer who should see the lease but not the payment method. These are decided before the build, because retrofitting them means reworking every query.
Measure the calls before you build anything
A portal is worth building when it removes repeated work, so the case for it is a count, not an opinion. For two weeks, tally what people actually contact you about: balance, status, a document, a change of details, a maintenance request. The shape of that list is the specification.
Two things usually come out of the exercise. One category is far larger than anyone guessed, which is where to start. And some categories should not be self-serve at all, because the phone call is doing useful work — catching a problem early, or keeping a relationship warm. Automating those is a loss disguised as efficiency.
Adoption is the whole project
A portal nobody logs into costs more than no portal, because you now run both channels. Adoption is not a marketing problem to solve after launch; it is a design constraint from the first day.
What moves it is narrow: the thing people came for must be visible immediately after login, password reset has to work without contacting you, and it has to be usable on a phone because that is what most people have in hand. What kills adoption is equally predictable — a forced enrolment step, a password policy nobody can satisfy, and a landing screen that shows announcements instead of the balance.
Documents are the feature people actually use
Whatever else a portal does, the document library gets the traffic. Leases, statements, invoices, receipts, certificates, reports. It is also the part most likely to leak, because document access is usually bolted on rather than scoped the same way the data is.
Every file needs an owner and every request for it needs to be checked against the person asking, every time. The classic failure is a predictable or guessable file URL that works for anyone who has it, which turns one shared link into a disclosure of everyone's documents. Files belong outside the web root and behind the same authorisation check as the rest of the system.
Notifications decide whether anyone returns
Most people will not visit a portal on a schedule. They come back when something tells them to, which makes notification design the difference between a portal that is used monthly and one that is used once.
Send few, and send them for things people care about: a new statement, an approved request, a payment received or failed. Every notification needs a direct link to the exact item rather than to the login page, and it must never contain the sensitive detail itself — email is not a secure channel, and "your statement is ready" is the correct amount to say. Give people a way to turn categories off, or they will mark the lot as spam and you lose the channel entirely.
Plan for the accounts that end
Tenants move out. Clients leave. Staff change. Every portal needs an answer for what happens to those accounts, and it is much cheaper to decide it during the build than to retrofit it after a former tenant is found still logged in.
The questions are: does access end immediately or after a grace period, can they still retrieve their own documents, how long is their data retained, and who is allowed to delete it. Offboarding is also a privacy obligation rather than a nicety, since retention periods are the part regulators actually ask about.
What it costs
Builds start at $1,900 for platform access, $3,800 to own your modules outright on a perpetual platform licence, and $14,400 for a full custom build with 100% of the IP assigned to you. Hosting from $99/month, optional maintenance from $175/month, changes at $125/hour. Nothing recurring starts until launch.
See GoldenKey Property Management for a portal built alongside the phone and email side of a property management operation.
Common questions
Can it connect to the software we already use?
Usually. If your existing system has an API or a usable export, a portal can sit on top of it rather than replacing it.
How do we get customers to actually use it?
Make the thing they want most available only there, keep the login simple, and do not force a password reset on first use. Adoption is a design problem, not a marketing one.
What happens to a tenant's data when they leave?
Access ends, records are retained for as long as you are legally required to keep them and no longer. That retention rule should be decided during the build.
How do we get people to actually use it?
Put the thing they want on the first screen after login, make password reset self-serve, and make it work on a phone. Then stop offering the old channel for that one task. Adoption follows convenience, not announcements.
Should we build a mobile app as well?
Almost never at the start. A website that works properly on a phone covers the same need with no app stores, no review delays and no second codebase. Build an app when you need something the browser cannot do, such as offline use or push at scale.
What is the most common security mistake in portals?
A database query that filters by record but forgets to filter by customer. It works perfectly in testing with one account and leaks across customers in production. Every query touching customer data needs the ownership condition, and it needs testing with two accounts, not one.
Talk to us
Tell us what the business does and what it has to accomplish. We will tell you honestly if a cheaper option fits you better.