Software Product Company: How GBCORP Builds Products, Not Projects

A software product company builds software it runs, sells and improves over years, with customers using it every day. GBCORP is one: its white-label engine, its platforms and its sites are products with roadmaps, release notes and support queues. Client work is delivered on those products, which means a client gets an engine that is maintained because the group depends on it, and a builder whose habits are a product company’s: measure, release every fortnight, keep it running.

Product versus project

What GBCORP runs

An engine for ordering, delivery, booking, loyalty, marketplaces and portals that powers its white-label range. Platforms built for specific sectors and run for years. Its own web presence, ranked and measured. A loyalty platform for multiple businesses. Every one of them is live, in the stores or on the web, and every one of them teaches the company what its client work will face.

How that shapes client work

A client app is a configuration or an extension of a running product, so sign-in, payments, notifications, consoles and store compliance are already solved and already maintained. Fixed prices per release are possible because the unknowns are few. Fortnightly builds are the habit of a company that ships its own products on that rhythm. Support plans exist because the company already runs a support queue.

Roadmaps and release notes

Engine improvements reach every client app under the plan, with a release note that says what changed. A client’s own releases are priced and dated. Feature requests from clients enter the same roadmap as the group’s own, and the ones that many clients need become engine features rather than repeated custom work.

Checklist for choosing a product-minded builder

• Which products does the company run, and for how long?
• Are release notes published for the engine?
• Does the company run its own support queue?
• Is client work delivered on the product or beside it?
• What reaches the client automatically, and what is priced?
• What does the client own on exit?

The numbers to expect

A configured product live within days at a flat plan. A one-time build delivered in weeks at a fixed price, with the code. Custom releases at a fixed price each, every two weeks. Support at a known monthly figure. Customised or more complex functionality is quoted separately before any work starts.

A worked example

A business asks two companies for a customer portal. The project company quotes a build in months and a maintenance contract to be discussed later. The product company, GBCORP, configures its portal product under the client’s brand in days, adds two custom screens as a priced release, and includes the product’s own roadmap and support queue. A year later, the portal has received a dozen engine updates the client did not pay for, has passed every platform change, and the two custom screens still work because they were retested on every release.

How a product company handles requests

Every client request enters a roadmap. A request many clients share becomes an engine feature, shipped to all under the plan. A request one client needs becomes a priced release, built on the core and retested with each engine update. A request that conflicts with the product’s direction is declined, with the reason. This is slower to say yes and faster to deliver, and it is the reason the engine stays coherent after years of client work.

Documentation and hand-over

A product has documentation because its own team needs it: architecture, configuration, release notes, runbooks. A client on a one-time build or custom work receives the same documents for its build, with every release. A new team taking over can read how it works rather than reverse-engineer it. The hand-over period is part of the plan, and no credentials are retained afterwards unless a support contract requires them.

Measuring a product in production

Crash-free sessions, response times, sign-in success, checkout completion, support tickets per thousand users. GBCORP watches these for its own products and for every client app on the engine, because they are the same engine. A client sees them in the console; a project company rarely measures them at all.

What the client pays for, and what it does not

The plan covers the engine and its updates. Releases cover the client’s own features. Support covers monitoring and response times. The client does not pay for the engine’s improvements, for store-rule work, or for the product company’s own roadmap; those are the return on running a product.

Ownership terms

Brand, data and accounts are the client’s. On a one-time build or custom releases, the code is the client’s, documented. Data is exportable at any time. No commission on sales, and no credentials retained after a hand-over unless a support contract requires them.

Questions we hear first

Can we buy the product outright?

Yes. The one-time branded app build delivers the engine as your own build with the code, at a fixed price.

Does product thinking make client work slower?

Faster: the common parts are finished, so the work goes where the client is different.

Do we get engine improvements on a one-time build?

Under a support plan, yes; without one, the build is yours to maintain.

Can our product become part of your range?

Where a client wants to resell what was built, the agency route and partner console exist for that.

Where to start

The GBCORP One-Time Branded App Build is the priced starting point for owning a product outright; the GBCORP software development hub sets out the method. For the process, read software product development explained.

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