Software Product Development: When the Software Is the Business

Software product development differs from building software for one company in a way that is easy to state and hard to practise: the product must work for customers the company will never meet, on the day they arrive, without a person configuring anything. Every architectural and design decision follows from that sentence.

What multi-tenant means in practice

The release rhythm of a product

The first release is the smallest thing someone will pay for, shipped in weeks, with billing and onboarding inside it. Then a release every two weeks, driven by activation and retention numbers rather than the founder's list. Features that do not move those numbers wait. This rhythm is how GBCORP runs its own products and how it delivers client products: scoped, priced per release, usable at every step.

What a software product company knows

That billing edge cases cost more than features. That the second customer breaks assumptions the first one confirmed. That store review will reject something every year. That support tooling built in month two saves a year of engineers debugging by e-mail. GBCORP builds client products with these in from the start because it has paid for learning them on its own.

SaaS on the web, the app, or both

From one codebase, GBCORP delivers the web application, the iOS and Android apps and the marketing site, all sharing one account, one billing system and one catalogue of features. Most products start on the web and add the apps when notifications or wallet passes earn their place.

Checklist before building a product

• The one-page brief with the paying user and the success number.
• The plan structure and prices you intend to charge.
• Ten named people who have said they will pay.
• The first release defined by the one result a customer must reach.
• The markets at launch: languages, currencies, tax rules.
• The person who will read the analytics every week.

The numbers to expect

Scoping in a week; a first release with billing and onboarding in eight to twelve weeks at a fixed price; releases every two weeks after that, priced before they start. Ownership of code, cloud, store and billing accounts in the company's name from day one. Track activation, week-four retention and revenue per customer; those three decide the roadmap.

The architecture decisions that pay later

Tenant isolation from the first table, because retrofitting it is a rewrite. Plan limits enforced by the system rather than by policy, because policy is not enforced at three in the morning. A single account and billing model shared by the web app and the mobile apps, because two of anything doubles the support load. Event logging from day one, because analytics cannot be added to the past. Feature flags, so a release can reach ten customers before it reaches all of them. None of these adds much to release one when they are designed in; each costs a quarter when they are bolted on under load.

Enterprise customers and what they ask for

The first enterprise customer asks for a dedicated tenant, data in a named region, single sign-on, an audit history and a data-processing agreement. A product built on the multi-tenant foundation above can say yes to all of them as plan features; one built as a single shared database has to say later. GBCORP designs for this from release one without building it until it is sold, which keeps the first release small and the enterprise conversation short.

Pricing experiments without rebuilding

A product's price changes several times in its first two years, and the software should make each change a setting rather than a release. Plans, limits, trials and add-ons are configured in the billing model, so a new tier can be offered to a segment of sign-ups and compared against the old one on activation and revenue per customer. Grandfathering existing customers, regional prices and annual discounts are the same mechanism. GBCORP builds this flexibility into release one because the founder's first price is a guess, and the product should survive being wrong about it.

The billing model also records why a customer left: the cancellation flow asks one question and stores the answer beside the account's usage history, so churn is a list of reasons rather than a percentage. Read monthly next to activation and retention, it is the cheapest product research a company will ever run, and it is built into release one for that reason.

Questions we hear first

Can we start on GBCORP's white-label platform and then build our own product?

Yes. Many products begin as a configured instance to test demand, then become custom development once paying customers show what they want.

Who handles billing and tax?

The product does, per market; GBCORP builds it into release one.

Can GBCORP run the product after launch?

Yes, under a support plan, or hand over to your team with documentation.

Do you build the apps and the web version?

Yes, from one codebase, with one account and billing system.

Where to start

The GBCORP software development hub covers product development end to end; the GBCORP Custom App Development product is the priced starting point for release one. For the earlier stages, read digital product development from idea to paying users.

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