Solutions
The layer nobody sees and everything else depends on.
APIs, data model, permissions and integrations. This is where it gets decided whether a system can still be changed in three years or has to be rewritten.
When it makes sense
Symptoms of a service layer that no longer holds.
Almost nobody asks for "a backend". They describe this instead:
- Every small change breaks something somewhere else, and nobody can predict where.
- The same business rule is written in three places, and they no longer agree.
- There is an integration that works because someone restarts it every morning.
- The mobile app and the web report different numbers for the same figure.
- Nobody can say who changed a record, or when.
- Validation happens in the browser, trusting that nobody will call the API directly.
What we build
Pieces of the service layer.
Product APIs
Versioned contracts with authentication, role-based authorization and server-side validation. Documented so another team can consume them without asking us.
Integrations
ERP, CRM, invoicing, payments or internal systems, over an API or file exchange, with explicit boundaries of responsibility.
Data model
Structure, constraints and controlled migrations. Business rules live in one place and can be read.
Identity and permissions
Own, corporate or federated sign-in, with roles at real granularity instead of two levels of administrator.
Background processing
Scheduled jobs, queues and retries for work that cannot happen inside a user request.
Auditability and reporting
A record of who did what and when, plus the exports the operations team asks for every month.
How it is built
Decisions made once and paid for over years.
Decisions made once and paid for over years.
A backend is not judged on delivery day. It is judged the day it has to change while it is in production, with data that cannot be lost. These decisions are what make that day an ordinary Tuesday instead of an incident.
- Validation and authorization on the server. The browser is a convenience, not a defense.
- Idempotent operations: a retry does not duplicate a charge or a record.
- Versioned contracts, so a change does not break whoever already consumes the API.
- Reversible migrations, tested before they touch production.
- Audit trails on sensitive operations from day one, not when someone asks.
- Separate environments, with test data that is not a copy of the real thing.
- PHP
- MySQL
- Firebase
- REST
- GraphQL
How it is delivered
From contract to operation.
Contract
What the system exposes, to whom, and with what guarantees. Before any code.
Model
Data, states and rules. Documented and reviewed with whoever knows the business.
Build
Usable increments, with automated tests over the critical rules.
Verification
Load, permissions, edge cases and a security review before publishing.
Operation
Observability, alerting, and handover to whoever will maintain it.
This work exists inside the systems shown in /case-studies: they are platforms with their own service layer, not standalone interfaces. What does not exist yet is a published case where the backend is the project itself. It is documented practice, not a line with a case of its own.
Let us look at the layer you already have.
With access to the code and the database, a week is enough to say something useful.