Someone reading that a customer portal takes three to six months may already have built a convincing version with Claude in an afternoon.
They have a fair point.
AI coding tools have changed how quickly a business can turn an idea into screens, a database and a working journey. That work can be genuinely useful. It can show customers the idea, expose missing decisions and give an engineering team a head start.
The honest answer to "how long will our portal take?" now begins with what the business means by a portal and what customers will be allowed to trust it with.
First things first, define what you mean by portal
A customer portal is a private, authenticated service where a customer can see information specific to their account and complete useful tasks with the business.
That could mean viewing live order status, downloading invoices, managing users, booking against controlled availability or placing an order using agreed prices and terms. A marketing website with a contact form is not a portal. A set of attractive screens using sample data is a portal prototype, but it is not yet a customer service.
The definition matters because two products can look similar and carry very different obligations.
A customer who signs in to see contract prices, current availability, an accepted order, delivery progress and the final invoice is using a portal connected to the operation. Each fact may come from a different system. Each action may trigger rules that the interface never shows.
Write down the first thing a named customer should be able to do and what they will believe when the portal says it has happened. That gives the discussion a useful boundary.
AI has moved the starting line
A prototype can now do more than illustrate a design. It may include working authentication, a database, generated components and an integration. It can help the business test language, navigation and the main customer journey before committing to a larger build.
That progress should carry forward. Rebuilding everything because AI helped create it would ignore the evidence the prototype has produced.
The useful question is which parts are ready to support a customer promise.
Generated authentication can look complete while account recovery or staff access remains unclear. A database can hold several customers while queries fail to enforce the customer boundary. A dashboard can show order status without establishing which connected system owns that status or what happens when two systems disagree.
AI makes code faster to produce. It also makes it easier to create more behaviour than anyone has properly reviewed. The production effort should concentrate on the parts where an attractive demonstration can hide a serious consequence.
The time sits behind the screens
Four decisions usually have more influence on the production date than the number of pages in the portal.
Authentication is the first. Who can invite, remove and recover users? Can a customer's administrator manage colleagues without gaining access to staff functions?
Customer separation is the second. Every record, file, search result, export and background task must stay inside the correct customer boundary. Testing the interface alone will not prove that.
Data protection is the third. The ICO's guidance requires privacy to be considered from design through operation. The business needs to know what personal information the portal holds, why it is needed, who can see it, how long it remains and what happens when a contact leaves.
Connected operations are the fourth. Prices, stock, credit, bookings, documents and service status often live in separate systems. The portal needs a clear source for each fact and a safe response when the source is late, unavailable or contradictory.
These are production questions, not arguments for a six-month programme. A narrow portal with one customer group and one dependable data source may move quickly. A similar-looking interface that writes into several legacy systems and handles customer-specific rules carries more work because the promise is larger.
Use discovery to earn the date
We would call the work of defining that promise discovery. The GOV.UK Service Manual describes discovery as understanding users, constraints, existing processes and the value of solving the problem before committing to a solution. Its published timetable applies to government services and should not be copied into a commercial plan. The principle is the useful part: understand what the service must achieve before turning a date into a promise.
Good discovery does not need to become a long prelude. Start with the prototype if one exists. Put it in front of the people who will use and operate it. Follow one customer journey into the systems behind the screen. Prove the riskiest read or write with representative data.
At that point the business can see which work is already useful, which decisions are still open and which dependency is likely to move the date. It can choose a credible first group of customers and keep later journeys outside the initial release.
The GOV.UK beta guidance supports the same controlled approach: release to a limited group, learn from real use and prepare the service for live operation. Security, privacy, accessibility, monitoring and support belong in that first boundary because a real customer will experience them as part of the product.
A portal may begin in an afternoon. The production date comes from the customer promise behind it.
If you have already built something useful, book a customer-portal conversation. Bring the prototype and the journey customers need next. We can identify what should carry forward, test the hardest dependency and turn the remaining work into a credible first release.