Web platform development
Systems people log into and depend on. Accounts, permissions, records that must stay correct, and a data model that still makes sense after two years of changes.
What this covers
- Authentication, roles and permissions, including who can see which records
- Relational data models designed for the questions the business actually asks
- Customer-facing areas and the internal side used to operate them
- Payments, subscriptions and invoicing where relevant
- Reporting and exports that do not require a developer to run
- Deployment, environments, backups and monitoring
When a company needs this
Usually when a process has outgrown its tools. Orders tracked in a shared spreadsheet, client files in email, a booking system that two people understand and nobody documents.
Also when an existing platform cannot answer a new question — who churned and why, which accounts are over their limit — because the data was never modelled for it.
What usually goes wrong
- Permissions bolted on after launch, so every new feature risks a data leak
- A schema that stores state as free text, making reporting guesswork
- No environment to test in, so every change is released to real customers
- Background work running inside the web request, so the platform stalls under load
What we do
We start from the records: what entities exist, who owns them, who may read and change them, and what must never be lost. The interface follows from that.
Permissions are enforced at the database level as well as in the application, so a mistake in the interface does not become a disclosure.
How the engagement runs
- Audit or scoping phase: data model, access rules and the first release defined in writing
- Build in phases, each with a working deployment you can use
- Migration of existing data where there is any, with a rehearsal before the real run
- Handover: documentation, local setup, and a period where we are still on hand