Backend work is invisible until it fails, which makes it the hardest part of a build for a non technical buyer to assess and the most consequential to get wrong. The useful evaluation questions are all about behaviour under conditions that do not appear in a demonstration.
Data modelling is the decision that outlives everything
Interfaces are replaced every few years; the data model is not, because by the time it is wrong there is production data shaped by it. Ask a candidate firm to model a small part of your domain and then change a requirement, and watch whether the model bends or breaks. That exercise tells you more than any portfolio, and it takes an hour.
Ask what happens when things fail
What happens when a third party is unavailable for an hour, when a request is retried after a timeout, when two users update the same record, when a background job fails halfway through. Good answers involve queues, retries with backoff, idempotency and explicit compensation. These are the difference between a system that degrades and one that corrupts data quietly, and they are never visible in a demonstration.
Security is structural here, not a later review
The backend decides how authentication works, how authorisation is enforced, what is logged and how data is separated. The elements at 16 CFR 314.4 make a practical specification: access limited to authorised users by job need, encryption in transit and at rest, multi factor authentication, secure development practices, monitoring and logging, periodic testing and a written incident response plan. Ask which exist in the proposed design rather than in principle.
Operability is part of the deliverable
A backend you cannot observe is a backend you cannot run. Require structured logging, metrics that answer whether the system is healthy, alerting a human will act on, a deployment process someone other than the author can run, and a restore that has been tested rather than assumed. Ask when the firm last restored a production database from backup, and treat hesitation as the answer.
Questions people ask about backend development company
How can a non technical buyer evaluate backend work?
Ask behavioural questions: what happens when a third party is down for an hour, when a request is retried after a timeout, when two users edit the same record. Good answers involve queues, retries, idempotency and compensation.
What is the most consequential backend decision?
The data model, because interfaces are replaced every few years and the model is not. Ask a firm to model part of your domain and then change a requirement, and watch whether the model bends or breaks.
What should be in the deliverable besides code?
Structured logging, health metrics, alerting someone will act on, a deployment process another person can run, and a restore that has actually been tested. A backend you cannot observe is one you cannot run.