Development
Backend and APIs
The server side of the product: API, business logic, database and integrations with other systems.
- Reply to your brief
- within 24 hours
- First call
- 30 minutes, no commitment
- First working version
- in 2–3 weeks
Process
What happens, and when
The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.
Days 1–4
Data and operations
We go through data and operations rather than screens: which entities the system holds, who calls the server — a browser, an app, someone else’s service — and what has to complete immediately versus what can wait in a queue. It ends with the list of endpoints for the first version: a timeline is costed from that list, not from a description of the system.
You get — The endpoint list for the first version
Days 5–10
The contract before code
The contract is written before the code: tables and relations, endpoints, one shape for errors, versioning. It is handed over before the server runs, so the web and mobile clients can be written against the description instead of waiting for a live endpoint. Where the data sits is settled here, along with what must survive any failure.
You get — An API description clients can be written against
From week 2
Endpoints in groups
Endpoints arrive in groups, and you can call each group yourself on a running instance with its documentation, rather than hear it described. Heavy work goes onto a queue from the start; caching goes where a request is measurably slow, because caching added early is the thing that later hides the real cause.
You get — A running instance with its documentation
Before deployment
Deployment and failures
Docker, NGINX, SSL, migrations with a way back, logs and metrics. We check separately how the API behaves when its neighbours fail: what it returns while the database is slow, and when the payment provider answers nothing at all. Without that a server works right up to somebody else’s outage.
You get — Migrations with a way back, logs and metrics
After launch
Version compatibility
An API outlives the clients calling it. New fields and methods are added so an older app keeps working, and anything that breaks compatibility ships as a separate version with a date on which the old one is switched off.
You get — New fields that leave older clients working
What the work covers
The data model and migrations
tables, relations, integrity constraints, indexes where measurement finds a slow query, schema changed on a live database.
The API contract before code
endpoints, request and response shapes, a single error format, version numbers and the rules for backwards compatibility.
Product rules on the server
calculations and statuses, validation of what comes in, rules a request cannot get around by skipping the interface.
Access and roles
sign-in by token, one organisation’s data kept apart from another’s, service keys for the systems that call the API directly.
A queue for long operations
retries when something fails, jobs on a schedule, reports and exports that do not hold up a request.
When a neighbour fails
timeouts on outside calls, a readable error instead of a hung request, a partial answer when part of the data is missing.
What we need from you
- The operations the server has to perform, and who calls it — a browser, a mobile app or someone else’s service.
- Access to the existing database and its schema, if the server slots into a product that already runs.
- Your expected volumes as figures — how many requests and records a day, and where the peaks are.
Projects in this area
Logistics
Vezira
A haulage company with a mixed fleet: the assistant reads a dispatcher’s request, gathers data from the CRM, the TMS and the telematics, and does only what is permitted.
3 systems
answer one dispatcher’s question
NestJS · PostgreSQL · OpenAI API
E-commerce
Onvela
A cosmetics retailer whose first line of support is an AI bot. It does not recite the FAQ: it finds the order, checks delivery and payment, and answers from data.
18 seconds
to a first useful answer, where the peak-hour wait was 27 minutes
NestJS · PostgreSQL · Qdrant
Fintech
Tallim
Matching payments to invoices inside a payments company’s finance team: strict rules, similarity and a model each take their turn, and a person confirms what stays unclear.
31,000 payments
a month go through reconciliation; 1.9% of them reach a person
Python · PostgreSQL · OpenAI API
What people usually ask
Contact
Send a description of the task
A reply with the scope, the timeline and a budget estimate comes within 24 hours.
The first call is 30 minutes, with no commitment on your side.
01
You describe the task
Five questions in the form, or a plain email — whichever suits you.
02
We answer within a day
With the scope, the timeline and a budget estimate, based on what you told us.
03
We talk for 30 minutes
To clear up whatever is unclear. It commits you to nothing.