In this article (14 sections)
Short answer: as a 2026 market reference, a read-only customer portal costs USD 3,000 to 7,000, a self-service portal where customers can place orders or upload documents costs USD 7,000 to 15,000, and a transactional portal with online payments and customer-specific pricing starts at USD 15,000. The big jump is between showing data and receiving it: everything a customer can do has to be validated, authorized and fed into your process.
A customer portal is the feature with the best ratio between what it costs and what it returns, and also the one most often dropped because it looks like a luxury. The reason is that people think of it as "giving the customer a screen", when it's really something else: taking repetitive work off your team.
What it is and what it solves
A private area where your customer logs in and sees what's theirs: orders, delivery status, account balance, invoices, documents.
The math that justifies it isn't about image. It's this: how many times a week does someone on your team answer the same question?
"When does my order arrive?" "Can you resend March's invoice?" "How much do I owe?" "Can you send me the signed delivery receipt?"
If those four questions take several hours a week of someone's time, the portal pays for itself, and fairly fast.
The ranges
Type of portal | 2026 market reference | What the customer can do |
|---|---|---|
Read-only | USD 3,000 to 7,000 | See orders, account balance and download invoices |
Self-service | USD 7,000 to 15,000 | All of the above, plus place an order, request a return, upload documents, update their details |
Transactional | USD 15,000 and up | Online payments, quoting, customer-specific price lists and your own commercial rules |
The jump from the first to the second is the one that matters. Showing is easy; receiving is where the work is.
At Atomix, a portal is built as a custom software project of USD 5,000 to 10,000; only exceptional, much larger projects go above USD 10,000. Before any quote there's a free working demo in 24 to 48 hours, built on your case.
What moves the price
Where the data comes from. If it already lives in a system with an API, the portal is a layer on top. If it's split between an old system and three spreadsheets, that has to be solved first, and that's the real project.
How many roles there are. One kind of customer is not the same as four, each seeing different things. Permissions are one of the parts that grow the most without anyone noticing.
Whether there are multiple users per customer. A client company with three people and different permissions —the buyer, the receiver, the payer— sounds minor and isn't.
Whether it has to send notifications. "Your order shipped" or "a new invoice is available" by email or text is what brings customers back to the portal instead of back to your inbox. Each message type is a small piece of work, and someone has to decide which ones are worth sending.
Whether it has to work on a phone. It almost always does, and it's worth deciding at the start: reworking it later costs more than building it right the first time.
How payments are handled. If customers pay through the portal, you'll typically lean on a payment provider for cards, invoices and saved payment methods; providers such as Stripe offer a hosted customer portal for billing that covers part of it out of the box. Their fees are a third-party cost, separate from the build.
The most common starting mistake
Showing everything the system has.
A portal isn't a window into your database. It's an answer to the questions your customers ask. Start by listing the five questions your team gets most often, and make the first version answer those five and nothing else.
A portal with five useful things gets used. One with thirty screens gets abandoned on the second visit, and it cost four times as much.
What has to be in place first
The data has to be right. A portal exposes your information to the people with the least tolerance for errors. If your balances aren't reliable internally, don't publish them: you'll turn an internal problem into an argument with a customer.
The process has to exist. If the portal lets customers request a return, someone has to receive that request and answer it. A request that lands in an inbox nobody checks is worse than not offering the feature.
Someone has to invite the users. It looks like a detail and it's the number one reason portals go unused: it launched and nobody invited the customers.
Login has to be secure. A portal holds invoices, balances and sometimes contracts. Password rules, account lockout and multi-factor authentication aren't extras; the OWASP Authentication Cheat Sheet is a good checklist to ask your vendor about.
How to tell whether it worked
Three numbers, and none of them is page views:
- How many repetitive questions stopped coming in. Count for two weeks before and two weeks after.
- What share of your active customers use it. If it's low after three months, the problem is almost never the portal: nobody invited them or showed them what it's for.
- How much response time dropped for the things the customer now handles alone.
When it isn't worth it
When you have few customers and a very personal relationship. With twenty customers who call or text you and value that closeness, a portal can make the relationship worse instead of better.
When your data isn't reliable yet. Fix that first.
When what you need is for the customer to buy, not to check. That's an online store, with different logic, cost and goals; see Shopify or custom e-commerce.
The detail everyone forgets
Telling people. A portal that exists and that customers don't know about doesn't save a single question.
Budget the rollout as part of the project: the invitation email, a one-page guide, the link in your email signature, and above all your team mentioning it every time someone asks something the portal answers. That last one moves the needle the most and costs nothing.
How we build portals and the systems behind them is on the custom software development page.
Frequently asked questions
How much does a customer portal cost in 2026?
As a market reference, USD 3,000 to 7,000 for a read-only portal, USD 7,000 to 15,000 for self-service and USD 15,000 and up for a transactional portal with payments and customer-specific pricing. Where your data lives today moves the number more than the screens do.
Should a customer portal be built on top of my current system?
Yes, if your current system has an API: the portal becomes a layer on top and reads the same data. If the data is spread across spreadsheets and an old system, that consolidation comes first and is usually the larger part of the work.
What should the first version include?
The answers to the five questions your team receives most often, typically order status, invoices, account balance and documents. Everything else can come later, once you see how customers use it.
Why do customer portals go unused?
Almost always because nobody invited the customers or showed them what it's for, or because the data shown wasn't reliable. The software is rarely the reason.
Do I need multi-factor authentication on a customer portal?
It's strongly recommended once the portal shows invoices, balances or contracts. At a minimum, the portal should have strong password rules and lock accounts after repeated failed attempts.
If you want to see what a portal for your customers would look like, book a call.