Login and roles
Each customer company sees only its own data, with roles inside that company from an admin down to read-only.
SiteFusion is a customer portal development company for founders and operations leads in the US, UK, EU, Canada, Australia, the UAE, Saudi Arabia and Qatar. We build a custom client portal, a logged-in area where your customers or partners can see an order or a project and pull the documents they used to ask for by email. You own the code.
A customer portal is the logged-in place for things that would otherwise need an email or a call. A good first version does a small number of those things well. Your team spends a growing share of the day answering status questions and sending the same files again. Bigger customers expect to serve themselves.
Each customer company sees only its own data, with roles inside that company from an admin down to read-only.
The thing customers ask about most, such as orders, projects, shipments or tickets, on one screen.
Files and invoices in one place, with a record of who downloaded what.
A request or an approval that lands in the workflow your team already uses.
Mail for the few events customers care about, so you are not chasing them to log in.
Your staff manage who can log in, and what each customer company is allowed to see.
Analytics dashboards, in-portal chat, a mobile app and per-client customisation can wait. Our post on designing a B2B customer portal MVP goes through those scope choices. The customer portals guide covers when a portal is worth building at all. Software your own staff use is a separate job, covered under internal tools development.
Your CRM, helpdesk, project tool or accounting software may already include a client portal, and a product built for your industry might fit well enough. Custom development makes sense when the portal has to show data from your own systems, such as an ERP, a production database, a warehouse system or an internal tool, and an off-the-shelf product has no way to show it. It also makes sense when the workflow with customers is specific to why they buy from you. The same is true when permissions or pricing change by customer, and when the per-seat cost gets large once every client user needs a login. The build vs buy guide goes through that decision. A good team asks this too, and sometimes the answer is to keep the tool you already have.
Most of the time goes into reading and writing data in the systems you already run, and into the permission rules. A fixed quote before anyone has seen those systems is a guess. A good team suggests a short paid discovery phase, then a fixed price or a capped budget for a clearly defined first version. Another language, including right-to-left layout for Arabic, changes the design and testing work, so say so before anyone prices it.
Someone sits with the people who answer customer email and writes down the questions, plus the systems those answers come from.
Login, the status customers ask about, documents, and a request that lands in your current workflow. You see a clickable design before any code is written.
You get a working version to try every week or two, against the real systems, while a change is still small.
Open it to a few friendly clients first, fix what confuses them, then widen the rollout with a short guide and a named contact.
A portal puts your data on the open internet behind a login, so the separation between customers has to be designed in from the first week. One customer must never see another's records, and that rule belongs in the API or the database, as well as in the screens. Plan for an audit log, and for encryption in transit and at rest. Ask whether larger clients will need SSO. Enterprise customers often send a security questionnaire before they roll a portal out. For UK and EU customers, GDPR applies to personal data in the portal. Gulf clients may ask where the data is hosted. Our B2B customer portal security checklist lists what to check. You still need your own legal advice.
Each integration needs error handling and retries, plus a plan for when the other system is down or slow. Before you ask for quotes, list every system the portal must read or write, and whether each one has a usable API. That list explains most of the gap between quotes. The systems are often an ERP, accounting software, a CRM, a warehouse system or your own database. Our API integration reliability checklist covers what a team should handle.
Your company should own the source code, the hosting accounts, the domain and the third-party services the portal uses. The agency is a user on those accounts. After launch the portal still needs bug fixes and security updates, plus the small changes that show up once customers are in it. We describe that work on the post-launch support page.
A portal only pays off if customers log in. Treat the rollout like a product launch: a few friendly clients first, then a wider release with a short guide and a named contact. You can see shipped work on the portfolio.
You should get a clear answer on the stack. At SiteFusion we mostly build with Next.js, React, Node.js and PostgreSQL, as described on the full-stack development page. A common, well-documented stack makes it easier to hire someone else later if you need to.
SiteFusion is based in Istanbul and delivers remotely for clients in the US, UK, EU, Canada, Australia and the Gulf. Ask how many hours of your working day overlap with the team, and who your daily contact is. Ask to see a demo every week or two.
More of these are in the guide to hiring a software development partner.
It depends mostly on the number of integrations and permission rules. A focused first version with one or two integrations is usually a matter of weeks to a few months. A team should give you a clearer estimate after a short discovery phase.
Use the built-in portal when it covers what customers need and the per-user cost is acceptable. Build a custom one when the portal has to show data from your own systems, or support a workflow that is specific to your business.
Each record belongs to a customer account, and the API checks that account on every request, so the rule is enforced on the server as well as in the screens. Larger clients can have their own admin roles. Ask any team you hire whether those clients will need SSO.
Usually yes, if the system has an API or a reliable export. The integration is often the largest part of the work, so list your systems early and check what access each one gives.
Rarely for a first version. A responsive web portal works on phones, and most B2B users log in from a laptop. Add an app later if customers ask for something a website cannot do.
Expect hosting, and third-party services such as email or file storage. Also expect ongoing support for security updates and small changes. Ask the team to estimate monthly running costs before you sign. Any precise build price given before someone has seen your systems is a guess.
If you are planning a customer portal and want a second opinion on the scope, book a call. We will say what we would put in version one, and whether a tool you already pay for could do the job.