Enterprise Web Development: Portals, Consoles and Scale

Enterprise web development produces web applications that many people in and around a group use every day: a customer or partner portal, a staff console, an approvals system, a reporting surface. GBCORP builds them on the same core as its other software, with tenancy, roles, audit history, single sign-on and integrations coming from the foundation, and the group’s own process built on top.

What a group runs in the browser

Identity and roles

Single sign-on to the group’s directory, so staff use the accounts they already have and leavers lose access the day they leave. Roles decide what each person sees and may do. Audit history records who changed what. Multi-company groups see their own data and the group sees everything. This is the foundation, and GBCORP does not build enterprise web applications without it.

Integration with what stays

An enterprise keeps its accounting, ERP and identity systems. The web application joins them rather than replacing them: each integration scoped as its own item, authenticated properly, logged, and with a fallback when a system is down. Where a system has no interface, GBCORP says so and proposes an import.

Security review and procurement

Where data lives, encrypted at rest and in transit. Access by role with audit. Backups, retention and deletion. Response times when something fails. GBCORP keeps this documentation per project and shares it with the security team in the scoping week, so the review runs beside the build rather than blocking the launch.

Checklist before the scoping week

• The applications in order of pain, and the one to build first.
• The identity provider and who administers it.
• Systems that must stay and whether they have interfaces.
• The security questionnaire the group will apply.
• Companies, markets and languages in scope.
• The number the first application should move: cycle time, volume, error rate.

The numbers to expect

Scoping in one week. First application in eight to twelve weeks at a fixed price. Further applications on the same core in four to eight weeks. Releases as often as weekly, with no store review in the way. Support with response times in hours. Customised or more complex functionality is quoted separately before any work starts.

A worked example

A group with six operating companies approves purchases by e-mail and tracks them in spreadsheets. The first enterprise web application is an approvals system: requests with attachments, routing by amount and company, deadlines and escalation, single sign-on to the group directory, and a dashboard showing cycle time by company. It is built on GBCORP’s core in nine weeks, with the ERP integration for purchase orders as a scoped item in the second release. Days from request to approval fall from eleven to two, the figure is on the board pack, and the second application, a supplier portal, is approved from it.

Performance at scale

An enterprise application is judged by how fast the first screen appears for a user in a distant office and how a list of a hundred thousand records scrolls. The shell ships as static files from the edge; data loads as the user needs it; long lists are paged and searched on the server; reports run in the background and notify when ready. Speed is tested on every release at the group’s real data volumes, because a console that is slow is a console people route around.

Reporting that the board reads

Each application ships with the reports for the process it covers: cycle time, volumes, exceptions, cost, by company and by month, exported to the tools finance already uses and shown live in the console. An approvals system that shows the group how long approvals take, and where they stall, is the reason the next application is approved.

Owning the system afterwards

Code, cloud project and every account are in the group’s name from the first commit. After the applications that matter are live, the group chooses a support plan with named response times or a documented hand-over to its own IT team, or a hybrid. An enterprise system with an owner is the one still in use in five years.

Multi-company and multi-market groups

A group with several operating companies runs one application with each company seeing its own data and the group seeing everything, by role. Languages, currency, tax and date formats are configured per company and per market, with right-to-left layouts as a setting. A company acquired later is added in the console and inherits the group’s process. This is the reason enterprise web development is built on a multi-tenant core from the first release rather than duplicated per company, and it is what makes the group-level reports possible without a data project.

Questions we hear first

Can it handle thousands of users?

Yes. The core is multi-tenant and the applications run in the group’s cloud project, scaled as usage grows.

Do we need to host it ourselves?

No. It runs in a cloud project in the group’s name, managed under the support plan; on-premise is a scoped variant.

Can our IT team take it over?

Yes. Documentation ships with every release and a hand-over is part of the plan.

Is it priced by user?

No. A fixed price per release and a support plan; no per-seat licence.

Where to start

The GBCORP web development hub explains the approach; the GBCORP Web Development product is the priced starting point. For the single-application case, read custom web application development explained.

GBCORP operates across 17 countries on 4 continents through six pillars: AI & IT, Innovation, Sustainability, Infrastructure, Business Lounge, and EV's & Solutions.