Web platform development
Business-critical platforms your customers and team log into every day: accounts, permissions, payments and records that must stay correct years after launch.
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.
Problems we find in existing systems
- Permissions added after launch. Access checks live only in the screens, not on the server, so one missed check lets a customer see another customer's data. We enforce access rules on the server and in the database, and test them.
- Status stored as free text ("paid", "Paid ", "PAID?"). Reports disagree and nobody trusts the numbers. We model states as fixed values with constraints and clean up the existing records.
- No test environment. Every change goes straight to real customers, so releases get rarer and riskier. We set up a staging copy and automatic checks before anything reaches production.
- Slow jobs (emails, PDFs, imports) run while the user waits. Under real traffic pages time out and orders are lost. We move that work to background queues with retries.
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 one ends with a working version you can use and check
- 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