Build · Pillar 01
Web platforms that carry the business, not just describe it.
A marketing site tells people you exist. A web platform is where they order, quote, book, track, approve and pay. The second one has to survive Monday morning.
What is a web platform, as distinct from a website?
A web platform is a browser-based application where users sign in and perform transactions — placing orders, raising quotes, booking capacity, approving documents, tracking jobs. A website publishes information; a platform holds state, enforces permissions and integrates with the systems behind it, which makes it an operational system rather than a marketing asset.
- Authentication, roles and permissions rather than open pages.
- Holds and changes business state, so uptime and data integrity matter.
- Integrated with the back office, not a separate island of data.
Why it matters
Most platform projects fail on the unglamorous half.
The demo always works. What breaks a platform in month four is everything the demo skipped: what happens when two people edit the same record, what the customer sees when the payment provider times out, how a price change propagates to quotes already issued, who can see which site’s data.
These are not edge cases, they are Tuesday. We design for them first, because retrofitting concurrency, permissions and audit into a platform that was built without them is close to a rewrite.
Designed in from the start
The unglamorous half
These are specified in phase one rather than discovered in production. Each one is cheap to design in and expensive to add later:
- Customers phone to ask things the platform should already tell them.
- Your team has a separate spreadsheet to track what the platform cannot.
- Permissions are enforced by hiding buttons rather than by the server.
- There is no audit trail of who changed a price, or when.
- Performance degrades noticeably at the busiest hour of the week.
- The mobile experience is the desktop one, shrunk.
Scope
What a platform build includes.
Scope varies, but a platform that will carry real transactions needs all six of these. We will not quote a build that omits the last two.
-
Accounts, roles & permissions
Server-enforced access control, organisation and site scoping, SSO where you already have an identity provider, and an invite flow that does not need IT.
-
Transactional workflows
Quote to order, booking to despatch, submission to approval — modelled as state machines with the exceptions handled explicitly rather than by a status field.
-
Interface & accessibility
Designed for the device it is used on, tested against WCAG 2.2 AA, and usable by someone on a warehouse tablet with gloves on.
-
Back-office integration
Stock, pricing, credit limits and invoices read from and written to the systems that own them, so the platform is never a second source of truth.
-
Security & audit
Threat-modelled, penetration-test ready, with an immutable audit trail of who did what. Built to pass a corporate client’s security questionnaire.
-
Performance & observability
Load tested at a realistic peak, with logging, error tracking and alerting in place before launch rather than after the first incident.
Deliverables
What launch day looks like.
A platform is not finished when it is feature-complete; it is finished when you can run it without us.
-
A platform your customers prefer to the phone
The test is whether call volume falls. If customers still ring to ask where their order is, the platform has not done its job, however complete the feature list is.
-
Permissions that survive a security review
Access control enforced server-side and documented, with a role matrix you can hand to a client’s IT department. This is routinely what unblocks enterprise accounts.
-
Observability from day one
Dashboards for errors, response times and queue depth, with alerts that reach a human. You find out about a problem from a notification, not from a customer.
-
An operations manual, not a mystery
Deployment runbook, environment variables, rollback procedure and on-call notes. Everything needed for your own team or another supplier to take it over.
Is this the right answer?
When web platforms is worth doing — and when it is not.
We would rather lose a project at this stage than six weeks in. If the right-hand column describes you, say so and we will tell you what we would do instead.
Worth doing when
- Customers need to transact with you, not just read about you.
- Your trade pricing and credit rules break consumer e-commerce platforms.
- A larger customer has asked for punch-out, EDI or a security questionnaire.
- Your team maintains a spreadsheet to track what the current system cannot.
Probably not when
- Nobody signs in and nothing changes state — that is a website.
- An existing platform fits and the problem is that it is not integrated.
- You cannot name the single workflow it has to carry.
- There is no appetite for the unglamorous half: permissions, audit, monitoring.
How we deliver
From prototype to production.
The riskiest assumptions get tested first, deliberately. It is much cheaper to be wrong in week two than in month six.
-
Phase one
Prototype the risky part
We build the single hardest workflow as a clickable prototype and put it in front of real users. If the model is wrong, we find out before the architecture is committed.
-
Phase two
Platform foundations
Accounts, permissions, audit, deployment pipeline and observability. Unglamorous, and the reason the rest of the build goes quickly.
-
Phase three
Workflows & integration
The transactional features, built one complete journey at a time and connected to the back office as each one lands, so nothing is integrated twice.
-
Phase four
Harden & launch
Load test at peak, accessibility audit, security review, then a staged rollout — usually one site or one customer segment first.
What you receive
The things that actually land.
Artefacts, not adjectives. Everything below is listed in the scope document before a phase starts, so “done” is a defined state rather than an opinion.
-
A tested prototype
The hardest workflow, clickable and put in front of real users before the architecture is committed. It is cheaper to be wrong here than in month six.
-
The platform, in your infrastructure
Repository, cloud tenancy and deployment pipeline in accounts you own, with environments for development, staging and production.
-
A documented role matrix
Who can see and do what, enforced server-side. Routinely the document that unblocks an enterprise customer’s security review.
-
Load test results
Measured against a realistic peak established in discovery, at two to three times that figure, with the findings written down.
-
Monitoring and alerting, live
Dashboards for errors, response times and queue depth, with alerts that reach a human. In place at launch, not after the first incident.
-
An operations runbook
Deployment, rollback, environment variables, on-call notes and the common failure modes with their fixes.
Golden Triangle
Platform work in this corridor.
What Midlands businesses ask a platform to do is shaped by distribution and manufacturing, and that is a harder brief than retail.
- Trade, not retail B2B pricing Customer-specific price lists, credit limits, contract rates and minimum order quantities. Consumer e-commerce platforms handle none of this, which is why so many trade businesses outgrow them.
- Depot and fleet Multi-site stock Availability that reflects which depot holds the stock, and despatch that respects cut-off times and vehicle routes out of the M1 and M6 corridor.
- Enterprise buyers Procurement-ready Large Midlands manufacturers expect punch-out, EDI or a security questionnaire before they will transact. We build so those are answerable.
Platforms we have scoped in the Triangle generally serve customers nationally while the operation itself sits across Birmingham, Leicester, Northampton and the Nottingham–Derby belt.
Technology
Platform technology.
Chosen for operational boringness and for the size of the hiring pool, so you are never one developer away from a stalled platform.
- TypeScript / Node
- Laravel
- .NET
- PostgreSQL
- Redis
- Azure
- AWS
- OAuth 2.0 / SAML
- Stripe
- Load & uptime monitoring
Where we deliver this
Web Platforms across the Golden Triangle.
35 locations, each with a page written for it — the sectors it is actually built on, and what that means for this work. See all areas we serve.
Northamptonshire 10
Warwickshire 5
West Midlands 5
Buckinghamshire 4
Leicestershire 4
Staffordshire 4
Derbyshire 1
Greater London 1
Nottinghamshire 1
Questions
Web platforms, answered plainly.
What gets asked once the conversation moves past the design.
What is the difference between a website and a web platform?
A website publishes content for anyone to read. A web platform requires a sign-in and changes business state — it takes orders, holds quotes, tracks jobs, routes approvals. The practical difference is that a platform needs permissions, an audit trail, integration with your back office and real uptime, none of which a brochure site needs.
How much does a web platform cost to build?
Mid-market platforms typically land in the five to low six figures depending on how many workflows and integrations are in scope. GTX Digital quotes each phase against a written specification, and the prototype phase deliberately comes first so that you have a tested model before committing to the build price.
Can a web platform integrate with our ERP or accounts system?
Yes, and it generally must. We read pricing, stock and credit from the system that owns them rather than copying it, so the platform never becomes a second version of the truth. We work with Sage, Xero, Business Central, NetSuite, SAP and bespoke ERPs through APIs, middleware or a scheduled file exchange where that is all the vendor offers.
Will the platform be accessible and legally compliant?
We build and test to WCAG 2.2 AA, which is the standard UK public sector bodies are held to and the one most corporate procurement teams now ask about. Accessibility is part of the build rather than a remediation project afterwards, because retrofitting it is several times more expensive.
How do you handle peak load?
We establish what a realistic peak looks like during discovery — usually a specific hour on a specific day for distribution businesses — and load test against two to three times that figure before launch. Monitoring and alerting go live with the platform, not after the first outage.
Can our own team maintain it afterwards?
Yes. The deployment runbook, architecture notes and test suite are written for a developer who has never spoken to us, and the admin layer is designed so that routine configuration — users, prices, content, rules — needs no developer at all.
How do you handle customers who need their own pricing?
Contract pricing is read live from the system that owns it rather than copied into the platform, so there is never a second version to drift. Price lists, customer-specific rates, volume breaks, credit limits and minimum order quantities are first-class parts of the data model rather than fields bolted on, because in B2B they are the commercial relationship.
What about customers who want to integrate with us directly?
That is usually a sign the platform is working. We build an API alongside the interface rather than afterwards, versioned and documented with OpenAPI, so a customer’s own systems can place orders and check status without a person. For larger customers that capability is often what wins the account.
Can the platform handle multiple brands or regions?
Yes, and it is much cheaper to design in than to retrofit. Multi-brand means separate catalogues, pricing, branding and sometimes separate legal entities against shared stock and fulfilment. We would rather know in discovery than discover it when the second brand launches.
How long before customers can actually use it?
The prototype is in front of real users within weeks. A first production release carrying one complete journey is typically three to five months, launched to a small group or a single customer segment rather than everyone at once, which is how problems get found while they are still cheap.
Related services
Commonly built together.
-
Connect
Customer Portals
Self-service for customers, so routine questions stop arriving by phone.
Explore -
Build
SaaS Products
Multi-tenant products with billing, onboarding and the admin tooling to run them.
Explore -
Connect
API Development
APIs and integrations so data is entered once and moves on its own.
Explore
Next step
Bring us the hardest workflow first.
Not the brief — the one process everyone agrees is painful. We will prototype it, put it in front of your users, and price the platform from what we learn.