Client portal development, built around the work your clients and staff do

Who is client portal development for?

A client portal fits a business whose clients keep asking the same questions: where does my job stand, what do you still need from me, what do I owe. Each answer means someone on your team stopping to look it up, and the answer is often out of date by the time it arrives. The portals we build differ with the kind of business they serve:

• Established local businesses: one office and a client list your team knows by name. The portal takes routine status questions and document requests off the phone, and the staff side can be as simple as one shared queue.
• Multi-location and regional businesses: several offices, and clients who may deal with more than one of them. The portal has to show each client one picture, while staff at each office see their own clients and nobody else’s.
• National businesses: large client bases, client companies with many users each, and security teams on the client’s side who review what you give their people. Sign-in, permissions and audit records carry much of the weight.

Midnite Systems was formed in 2023. We work from our office in Valencia, and the portals we build are for businesses across the US. When a product you can buy would do the job, we’ll say so on the call.

What should clients be able to do in a portal?

Start from the questions clients ask by email and phone, and give each one a screen. The pieces a portal can carry:

• Status: where each job, order, case or project stands, read from the system your team already updates, so nobody types it twice.
• Documents: files you share and files clients send you, in one place with dates, so nothing is lost in an inbox.
• Requests: a form for each thing clients ask for, routed to the right person on your team with the client’s details attached.
• Signatures: agreements and forms clients sign in the portal, filed against their record.
• Invoices and payments: what each client owes and has paid, with a way to pay online through your payment provider.
• Messages: a thread per client or per job, so the history stays with the work.

A portal doesn’t need all six on day one. A first version that answers the question clients ask most often is a sound start, and each screen after it can follow what clients use.

What internal tools sit behind a client portal?

A portal usually has a staff side, and it can be the larger build. When a client uploads a document, someone reviews it. When a client asks for a change, someone approves it. The internal tool is where that work happens:

• Queues: new requests, uploads and signatures waiting for your team, sorted by client and by age.
• Approvals: changes that need a manager’s yes before the client sees them.
• Client records: one screen per client with documents, history and open items.
• Admin: inviting users, removing access and setting what each role can see.

The same pieces make an employee portal on their own, with no client side: a place where staff find documents, submit requests and check schedules. Some businesses start there and add the client side once the records behind it are in order. When the internal tool is the main job, our page on web applications covers it in more depth.

Should you hire a Retool developer or have the portal built in code?

Retool’s own site describes it as a way to build, deploy and manage internal tools. If you’re comparing Retool experts or a Retool agency with a portal built in code, start with what Retool supports for outside users: its documentation describes external apps, white-labeled for customers, vendors or partners, and treats any signed-in user from outside your organization as an external user. External users are billed under Retool’s plans, at a lower rate than the people who build the apps, so check its pricing against the number of clients you expect.

Retool developers, freelance or at an agency, suit a business whose tool is mostly internal, whose team already works in Retool, and whose clients need a few simple screens. A portal built in code suits a business whose clients are the main users, whose screens need to follow its brand and workflow exactly, or whose client numbers would make per-user fees a large part of the running cost.

We are not a Retool partner, and we don’t present ourselves as Retool experts. We build portals in code, each in its own repository, and we work on a low-code platform when that is the better fit for your team. Our guide on building or buying internal tools sets out the trade-offs, and our page on no-code and low-code development covers the platform work.

How is each client kept out of another client’s records?

The first risk to plan for in a portal is one client seeing another’s records. OWASP’s Top 10 for 2025 puts broken access control first: users reaching data or actions their role should not allow. In a portal, that can be as simple as changing a number in the address bar and landing in someone else’s account. The defences are ordinary engineering, applied to every screen:

• A check on every request: the server confirms who is asking and that the record belongs to them on every page and every download, as well as at sign-in.
• Multi-factor sign-in: CISA advises multi-factor authentication because a password on its own no longer protects an account well enough, and it tells businesses to aim for a phishing-resistant method.
• A record of who did what: a log of views, changes, downloads and signatures for each client. OWASP’s 2025 list includes failures of security logging and alerting, since an attack nobody records is hard to spot.
• Tests from the wrong account: before launch, one client’s account tries to reach another client’s records, and every attempt has to fail.
• Narrow staff access: your team’s roles see the clients they serve, and admin rights stay with the few people who need them.

One kind of portal we don’t build: one that creates, receives, keeps or sends patients’ health information.

What does a client portal connect to?

A portal is only as current as the systems behind it. The status a client sees has to come from where your team records it, the invoice from your accounting system, and the signed form has to land back in the client’s record. The usual connections:

• Accounting: invoices and balances read from the system your bookkeeper uses, with payments recorded back.
• CRM: contacts and history, so your team and the portal agree on who each client is.
• Operations: the jobs, orders, cases or projects whose status clients ask about.
• Email: a notice when something needs the client, such as a form to sign or a status change.

Where a system has an API, the portal reads and writes through it. Where it has none, we look at scheduled exports or a direct link to its database. Our page on API integration services covers how those connections are built and kept running.

When is an off-the-shelf client portal the better choice?

When your process is standard, a product can do the job. Some accounting, legal and property management systems include a client portal, and standalone portal products sell document sharing, e-sign and payments for a monthly fee. If your clients need to download documents and pay invoices, and your current system already offers that, switch it on before paying for a build.

A built portal is worth its cost when a product would make you change how you work, when clients need to act on records held in several systems, or when the portal is part of what clients buy from you. Per-user fees count too: a product priced per client costs more each year as the client list grows. Our guide on buying or building a client portal works through the decision, and our guide to building or buying software covers the same question for any system. When a product does the job, we’ll tell you to buy it.

What would a portal we build look like?

What we would build depends on what your clients ask you most. Three examples of the shape it could take:

• A title or escrow company: a closing portal where buyers, sellers and agents see each file’s status, upload what’s missing and sign, while your staff work the same files from an internal queue. Our page on software for title companies goes further.
• An IT services company: a client portal showing each client’s open tickets, the devices you manage for them and their invoices, drawn from your ticketing and billing tools. Our page on software for IT services companies covers that sector.
• A property manager: an owner portal with monthly statements, maintenance requests and lease documents, and a tenant side for requests and payments.

Each would have a staff side as large as the client side, and each would connect to the systems the business already runs.

What does a client portal cost to keep running?

A portal’s running costs sit in three places. Hosting and the services under it, such as email delivery and file storage, cost something each month. Products the portal relies on, such as an e-sign or payment provider, charge their own fees. And the software needs looking after: fixes when a connected system changes, security updates, and the small changes clients ask for. A portal can ask for more of that care than an internal tool, since clients sign up, reset passwords and find the paths your staff learned to avoid.

A portal we build runs on a monthly plan after launch, and the proposal prices that plan. For the market’s build and upkeep ranges at each level, see what custom software costs.

If your team answers the same client questions every day, book a 15-minute call. Tell us who would log in and what they would do there, and we’ll tell you whether a portal is worth building or which product to try first.