Custom Web Platform Development | Built for Your Business

2,000+

builds shipped

55+

countries served

8-16 wk

first release

48 h

scoped quote

A web platform is software with external users, a tenancy boundary, and a billing relationship. People outside your company sign in to it. Their data has to stay separated from every other customer's data. Money, or an entitlement that stands in for money, decides what each of them can do. Those three properties are what make a platform a different engineering problem from a website or an internal tool.

Portals, marketplaces, member dashboards, partner networks and licensed industry systems all sit inside that definition. So does a client portal a services firm gives its customers, even when nobody calls it a product.

The visible surface is usually a dashboard. The work is almost never the dashboard. It is the permission model underneath it, the tenancy boundary around it, and the admin console your own team needs on day one to answer a support ticket.

We build these on Next.js, Rails or Django with Postgres underneath, picked by who maintains the thing after we leave rather than by what is fashionable this year. Payments run through Stripe Billing or an equivalent, and the identity layer is bought rather than invented.

in short

A platform has external users, tenancy and a billing relationship. Internal software usually has none of the three.
Seven layers ship in every build: identity, permissions, tenancy, billing, admin, integrations, and the operational handover.
The tenancy decision is made once, in discovery, because changing it later is a migration rather than a refactor.
The first release carries one complete revenue path end to end, not five half paths.
Everything lands in your repositories and your cloud account, with our engineers as removable collaborators.

§ 02 · the boundary

Platform, internal software, or a SaaS product.

Three different briefs arrive wearing the same words. The honest test is who signs in and who pays. If only your staff sign in, you want custom software. If strangers sign up and pay you directly for the software itself, you want a SaaS product. If named external customers sign in under an account you provision, you want a platform.

Question	Internal software	Web platform	SaaS product
Who signs in	Your employees only.	Your customers, partners, suppliers or members, plus your staff.	Anyone who finds the pricing page.
Tenancy	One organisation. Usually none needed.	Required. Each account is a hard data boundary.	Required, and sized for thousands of accounts.
Billing	A cost centre. No billing code.	A relationship. Contracts, invoices, seats or usage.	The product. Self-serve checkout and plan changes.
Onboarding	HR adds an account.	Your team provisions the account, then the customer invites their own people.	Nobody touches it. Sign up to first value unattended.
Failure blast radius	Your team works around it for a morning.	Customers see it, and a leak between accounts is a contract problem.	Public. It reaches a status page and a support queue.
go here	Custom software development	This page.	SaaS development

Three signals settle it in practice. Someone outside the company asks for a login. A data leak between two accounts would be a breach rather than an annoyance. A lapsed invoice or a downgraded plan is supposed to change what a user sees. Any one of those puts you on this page.

§ 03 · identity and access

Auth is bought. Permissions are built.

Nobody should be writing password hashing in 2026. Identity is a commodity, so we wire in a provider and spend the design time where the real domain lives: the permission matrix. Sessions, recovery and multi-factor follow the OWASP authentication guidance rather than a blog post.

01

The account model comes before the login screen

A user belongs to an organisation, and a person can belong to more than one. Getting that wrong early is the single most expensive mistake in platform work, because every query written afterwards assumes it.
02

A written permission matrix, not a vibe

Every role gets a row. Every protected action gets a column. Your team signs the grid before anyone writes the guard clauses, and the grid becomes the test plan later.
03

Object level checks on the server

Hiding a button is styling, not security. Broken object level authorisation sits at the top of the OWASP API risk list for a reason, so every request re-checks ownership server side.
04

Tests that prove the negative

It is easy to test that an admin can see the report. The tests that matter assert that a viewer in another account gets a 404, and they run on every commit so a later refactor cannot quietly undo them.
05

Invitations, offboarding and revocation

Customers add and remove their own people constantly. Pending invites, seat limits, role changes mid-session and immediate session revocation are product features, and they get designed rather than discovered in support tickets.
06

Single sign on when the buyer asks

Enterprise customers will eventually require SAML or OIDC and domain capture. We leave the seam for it in the identity layer from the start, and build it when a signed contract asks, not before.

§ 04 · tenancy, decided once

Whose data is whose.

Tenancy is the boundary that keeps one customer's records away from another's. There are three serious options, and the choice is made in discovery because changing it after launch is a data migration with downtime, not a refactor you slip into a sprint.

Model	Fits when	The cost you accept
shared schema tenant id on every row	Most platforms. Many accounts, similar data shapes, no contractual demand for physical separation.	Every query has to be scoped. We enforce it in the database with row level security so a forgotten where clause returns nothing instead of everything.
schema per tenant one namespace each	Tens to low hundreds of accounts, some wanting their own retention or export rules.	Migrations now run per schema, and reporting across all accounts needs deliberate work rather than one query.
database per tenant hard separation	Regulated work, data residency clauses, or a handful of very large accounts paying for isolation.	Real operational weight. Provisioning, backups, restores and upgrades all multiply by the number of customers.

§ 01

Tenant switching

Consultants, agencies and holding companies belong to several accounts. The switcher, and the audit line it writes, are designed in rather than added under pressure.

§ 02

Export and deletion

A customer who leaves is entitled to their data and to its removal. Both paths are built and tested once, early, because retrofitting them across a mature schema is miserable.

§ 03

Leak testing

A seeded second account runs through the suite on every build, asking for the first account's records by id and expecting to be refused every time.

§ 05 · billing as product

Money changes what a user can do.

The payment provider handles cards, invoices, tax and dunning. What it cannot do is decide whether this user may open this screen right now. That is an entitlement, it belongs in your database, and keeping the two in step through webhooks is most of the real billing work.

01

Plans and entitlements

A plan is a marketing idea. An entitlement is a row the code checks. Every feature gate reads the second, so a pricing change is configuration rather than a release.

02

Seats and usage

Per seat pricing needs a seat counter that survives invites and removals. Usage pricing needs a meter you can reconcile and a customer facing view of it before the invoice lands.

03

Trials and proration

Trial start, trial end, upgrade mid-cycle, downgrade mid-cycle, pause and resume. Each one is a state transition with a defined effect on access, written down before it is coded.

04

Failed payments

A card declines far more often than founders expect. Retry schedule, email sequence, grace period and the exact day access narrows are product decisions your team makes, not defaults we inherit.

05

Webhooks that can be replayed

Billing events arrive late, twice, or out of order. Handlers are idempotent, signed, stored raw, and replayable, so a provider outage becomes a catch up rather than a reconciliation weekend.

06

Invoices, tax and contracts

Business customers want purchase orders, net terms, a VAT or GST number on the invoice, and an annual contract that ignores the self-serve flow entirely. The model has room for both paths.

worked example

1 plan → 9 states

hypothetical, and typical

Imagine a single paid tier on a hypothetical supplier portal. Trialling, active, past due, grace, suspended, cancelled at period end, cancelled now, paused, and reactivated. Nine states, each with its own answer to what the user sees. Write them as a table in discovery and the build is calm. Discover them one support ticket at a time and it is not.

Map your billing states with us

§ 06 · the admin layer

The screen your own team lives in.

Every platform needs a second product nobody demos: the admin console. Support uses it hourly, finance uses it monthly, and it is the difference between answering a customer in two minutes and answering them after an engineer runs a query. We ship it in the first release, not the third.

The test is simple. If answering a normal customer question needs an engineer with production access, the admin layer is unfinished. In discovery we take the ten most common support questions and make each one a screen rather than a query.

§ 01 · provision

Accounts

Create an account, set its plan, invite the first administrator, and move a user between accounts without touching the database.
§ 02 · support

Audited impersonation

See what the customer sees, with a visible banner while it happens and a permanent log entry naming who looked, at what, and when.
§ 03 · control

Flags and overrides

Turn a feature on for one account, extend a trial, waive a limit, issue a credit. Everyday commercial decisions that should never need a deploy.
§ 04 · evidence

The event log

Every meaningful action writes an immutable event from day one. It settles disputes, it feeds reporting later, and it cannot be reconstructed after the fact.

§ 07 · the integrations underneath

A platform is mostly other systems.

Very little of a platform's value sits inside its own database. It sits in the payment provider, the mail system, the CRM, the ERP, the warehouse, the accounting ledger. Integration work is where estimates go wrong, so we inventory every connection during discovery and size it before it is promised.

01

Identity providers

Email and passkey sign in, social providers where they suit the audience, SAML or OIDC for enterprise buyers.

02

Payments

Cards, bank debit, invoicing, regional methods, and the tax engine that keeps the invoice compliant where you sell.

03

Mail, files and notifications

Transactional mail with real deliverability setup, in app notifications, a preference centre, and object storage behind signed URLs.

04

CRM and ERP

Two way sync with the systems your revenue team already trusts, with conflict rules agreed in writing before the first record moves.

05

Webhooks, both directions

Inbound events signed, stored raw and replayable from the admin console. Outbound events retried with backoff, logged for the customer, secret rotatable.

06

A public API

Versioned, rate limited, documented, and scoped by token. Built when customers ask for it, and designed so it is not a second permission system.

Where the integration itself is the whole brief, and there is no portal around it, our API development and integration service is the cheaper door. Where the platform's centre of gravity is a customer record or an operations ledger, look at custom CRM development or ERP development first.

§ 08 · the first release

One complete path, all the way through.

The first release carries a single user type through a single valuable journey from sign up to the thing they came for, with the admin layer behind it and the billing state that governs it. Five half finished journeys teach you nothing. One finished journey tells you whether the model works.

ships in release one

Sign up, sign in, recovery, invitations and the account model behind them.
The role and permission matrix for the roles this journey actually needs.
The tenancy decision, implemented and leak tested.
One complete journey end to end for the primary user type.
The billing states that change what that user sees.
The admin console for the ten most common support questions.
The integrations that journey cannot run without.
CI/CD, staging, error tracking, structured logs, backups with a tested restore.

deliberately waits

The second and third user type, until the first one is proven in production.
Self-serve public sign up, when your early accounts are provisioned by hand anyway.
A public API, until a customer names what they want to build with it.
Single sign on, until an enterprise contract requires it.
Configurable everything. Configuration is a feature with a maintenance bill.
A reporting suite, before there is enough real data to report on.
Native mobile apps, which belong in their own engagement.
Anything whose only justification is a competitor screenshot.

§ 01 · wk 1-3

Discovery

Domain model, permission matrix, tenancy decision, billing states, integration inventory, written estimate.
§ 02 · wk 3-5

Foundations

Identity, tenancy, permissions, CI/CD, staging URL live at the end of the first fortnight of build.
§ 03 · wk 5-12

The journey

The primary user journey, the screens it needs, the integrations under it, demoed weekly on staging.
§ 04 · wk 12-15

Admin and billing

Support console, entitlements, webhook handling, the failure paths, and a pilot with real accounts.
§ 05 · wk 15-16

Launch

Load check, restore drill, runbook, training, cutover, and a named engineer watching the first week.

§ 09 · the handover

You should be able to fire us.

A platform you cannot operate without the agency that built it is a liability wearing a nice interface. Everything is built inside your GitHub organisation and your cloud account, under your billing, with our engineers as collaborators you can remove in an afternoon. Ask the same of every firm in our US custom software development ranking.

01

Your accounts, from day one

Repositories, cloud project, database, payment provider, mail provider and domain all registered to you before the first commit, never migrated to you afterwards.

02

Architecture decision records

Every choice that would be expensive to reverse is written down with the alternatives and the reason, so your next engineer inherits the argument as well as the code.

03

A runbook, not a wiki graveyard

Deploy, roll back, restore a backup, rotate a secret, add a tenant, read the logs. Short, current, and verified by someone new following it without help.

04

Seeded local setup

One command brings up a working environment with two seeded tenants and every role, so a new developer is productive on their first day rather than their second week.

05

Training, then a defined exit

Recorded walkthroughs for your engineering, support and finance teams, a fixed post launch window for defects at no cost, then either a retainer or a clean exit. Both are priced before launch so neither becomes leverage.

If you would rather keep the capability in house, we also staff the other side of this. An embedded squad through a dedicated development team works alongside your engineers on the same repository, under the same review rules.

§ 10 · how we engage

Three engagement shapes.

Discovery first, always, because a platform quoted without a permission matrix and a tenancy decision is a guess. Discovery produces a written scope you own outright, and you are free to build it elsewhere. Most clients then run the first release with us and move to a release cadence afterwards.

discovery

Platform discovery

2-3 weeks

Domain model, permission matrix, tenancy decision, billing states, integration inventory, architecture record, and a scoped first release with a written estimate. Yours to keep.

Book discovery

most picked

first release

First release build

8-16 weeks

Identity, permissions, tenancy, one complete journey, the admin layer, billing states, and the integrations under them. Named tech lead, weekly demos, staging from week one.

Scope the first release

after launch

Release cadence

monthly

Second user type, self-serve onboarding, public API, reporting, regional expansion, and the operational work real usage creates. Cancellable, with the exit documented up front.

Plan the next releases

§ 11 · questions we get

Custom web platform FAQ.

Direct answers on what a platform is, how tenancy is chosen, what the first release costs you in time, who owns the code, and when a different service is the better buy.

What is custom web platform development?

It is the design and engineering of a multi-user web system with external users, a tenancy boundary and a billing relationship. Portals, marketplaces, member dashboards and partner networks all qualify. The build covers identity, roles and permissions, tenancy, subscription or usage billing, an admin console for your own team, and the integrations that sit underneath all of it.

How is a web platform different from custom software?

A platform has external users, tenancy and a billing relationship. Internal software usually has none of the three, which removes a large amount of work. If only your staff will ever sign in, and nobody is invoiced for access, custom software development is the cheaper and faster route. We will say so on the call.

When should I build a SaaS product instead?

When the software itself is the thing you sell to a market, with a pricing page, self-serve trials and strangers signing up unattended. That is a different commercial machine, and it is planned against revenue stages rather than one customer set, so it belongs in SaaS development. Platforms serve accounts you provision and know by name.

How long does a first release take?

Eight to sixteen weeks of build, after two to three weeks of discovery. The range is set by how many roles the first journey touches, which tenancy model the risk profile demands, and how many external systems have to be integrated. You get a staging URL in the first fortnight of build and a demo every week after that.

What does a custom web platform cost?

Cost tracks the number of roles, the tenancy model, the billing complexity and the integration count, so we do not publish a list price. Discovery produces a fixed-price, week-by-week quote for the first release, and we send it within 48 hours of the scoping call. The price moves only if the scope moves, and scope changes are flagged before invoices are.

Which multi-tenancy model will you choose?

Most platforms use a shared schema with a tenant identifier on every row, enforced in the database through row level security so a missing filter returns nothing rather than everything. Schema per tenant suits tens of accounts with individual retention rules. Database per tenant is for regulated work or data residency clauses, and it carries real operational weight.

Do you build the billing, or just connect Stripe?

Both, and the second half is the part people underestimate. The provider handles cards, invoices, tax and retries. Your platform still needs an entitlement layer that decides what a user may do right now, webhook handlers that are idempotent and replayable, and a written answer for every subscription state including grace periods and cancellations.

Who owns the code and the infrastructure?

You do, from the first commit. Repositories sit in your GitHub organisation, infrastructure runs in your cloud account under your billing, and our engineers are collaborators you can remove whenever you choose. Handover includes architecture decision records, a runbook, a seeded local setup and recorded walkthroughs for your engineering, support and finance teams.

Can you take over a platform someone else built?

Yes. We start with a fixed-length audit covering the permission model, tenant isolation, billing reconciliation, dependency health and deployment safety, then hand you a prioritised remediation plan with costs. Sometimes the honest recommendation is to stabilise and keep going. Sometimes one layer needs replacing. You get the finding either way, before any build work is proposed.

§ 12 · related services

Where this work connects.

ready to scope

Describe the platform. Plan back in 48 hours.

A 30-minute call to find the roles, the tenancy risk and the money path. A written scope and a fixed-price first release come back within two business days. If a simpler service would serve you better, we will name it.

Scope a platform build See case studies

Why work with Digital Heroes

115 people across five studios in New York, Delhi, London, Sydney and Lucknow, shipping ecommerce, web, software and mobile work for founder-led brands. Senior engineers only, no account-manager relay, and the same team from kickoff to launch.

Shopify Select Partner, as listed in the Shopify Partner Directory
Tier 1 registered supplier on the United Nations Global Marketplace, which requires audited company documentation
Top Rated Plus on Upwork, the bracket for the top 3% of talent by client outcomes
397 public five-star-weighted reviews across four Fiverr gigs, from clients in 36 countries
DUNS verified business, No. 650878346, so procurement can check us before signing
Listed by Clutch in Top 1000 Global B2B Companies and Top Web Designers 2024
Verified profiles on GoodFirms, DesignRush, Digital.com, AppFutura and TopDevelopers
2,000+ brands built across 40+ countries, with $50M+ in client revenue scaled