Digital Platform Development: One Engine, Many Surfaces

Digital platform development produces software with several kinds of user on one foundation: customers, providers, staff, partners, administrators, each with their own app or console, all on one data model and one set of rules. GBCORP’s engine is built this way, which is how a city platform, a marketplace or a group’s multi-brand system can be delivered as configuration and releases rather than as separate projects that later have to be joined.

App or platform

The shared core

Accounts and roles, payments and payouts, notifications, multilingual text, wallet cards, documents, audit history and reports are built once. Every surface uses them. A rule changed in the core applies everywhere, and a new surface, say a partner console, is a set of screens on data that already exists.

Surfaces

A customer app on iOS, Android and web. A provider or merchant app. A staff app. A web console per role. A public API for partners. A reporting surface for the owner. Each is added as a release when the platform needs it, and each is thin because the core is thick.

Governance from the first release

Who may list, sell, post or book, and what happens when they break the rules. Fees, payouts and statements. Content review before publication where the platform’s reputation depends on it. Audit history of who changed what. A platform without governance becomes a moderation problem within a month of success, so GBCORP builds it into the first release rather than the fifth.

Checklist before the scoping week

• The kinds of user, and what each does on the platform.
• What flows between them: money, messages, bookings, content.
• Who governs: rules, fees, review, disputes.
• Which surface launches first and which follow.
• Partners who will need an API, if any.
• The number that proves the platform works: transactions, active providers, repeat use.

The numbers to expect

Scoping in one week. A first surface in eight to twelve weeks at a fixed price on the shared core. Further surfaces in two to six weeks each. Releases every two weeks. Support with response times in hours for critical issues. Customised or more complex functionality is quoted separately before any work starts.

A worked example

A city organisation wants a platform for residents, local businesses and its own departments. The first surface is the resident app: places, events, offers and a loyalty card. The second, six weeks later, is the business console where venues manage their listings and offers under review before publication. The third is a department console for events and announcements. All three run on one data model with roles, review, audit and reports built into the first release, so a business listing approved in the second surface appears in the first at once. The fourth surface, an API for a transport partner, is a release rather than a project.

Money on a platform

Where a platform moves money between parties, payments, fees, payouts and statements are core, not features: a customer pays, the platform keeps its fee, the provider receives a payout with a statement, and every party can see its own ledger. GBCORP builds this into the core with the platform’s own payment provider, so a marketplace, a booking platform or a city offers programme handles money the same tested way, and the owner sees revenue by party in the console.

Ownership of a platform

Code in a repository the owner controls. Cloud project, domains, store accounts and payment accounts in the owner’s name. Documentation for every surface and the API. No credentials retained after a hand-over unless a support contract requires them. A platform is a long-lived asset with partners who depend on it, so ownership is written down in the first agreement rather than negotiated later.

Trust and safety on a platform

A platform where strangers transact needs review before publication for listings and content, word filters and tiered wording rules, tripwires for suspicious patterns, a safety queue for staff, and clear house rules accepted at sign-up. GBCORP builds these into the core because they are the same on every platform and because a platform that adds them after the first incident has already lost the trust it needs.

Sequencing the surfaces

The first surface is the one that proves demand, usually the customer app. The second is the one that removes the owner’s manual work, usually the provider or merchant console. The third serves the internal team. Partners and their API come when a partner is ready to build. Each surface is a release with a fixed price and a date, and each ships on the core built in the first, so the platform grows in weeks per surface rather than months per project.

Questions we hear first

Is a platform much more expensive than an app?

The first surface costs about what an app costs; the saving is in every surface after it.

Can we start with one surface?

Yes, and you should. The core is built for several from day one; the surfaces follow the numbers.

Can partners integrate?

A public API is a release on the same core, with keys, limits and documentation.

Who owns it?

You do: code, cloud project, accounts and data.

Where to start

The GBCORP software development hub sets out the engine and the method; the GBCORP Custom App Development product is the priced starting point. For the product side, read digital product development explained.

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