Home / Product development / Back-office software development
Your support team asks a developer to merge accounts, operations fix orders with a database script, and nobody can say later who changed what. We build the admin layer behind your product or service: customers, orders, content and documents on screens built for each job, with roles, sign-offs and a history of every change. Coding agents help write the screens, filters and bulk tools; senior engineers decide who may change which record.
Support asks a developer to merge two accounts, finance corrects a payment by hand in the database, and a customer’s address is changed in three tools that then disagree. Later nobody can say who changed what. When each job has its own screen, permission and log entry, operators settle the case themselves and the history answers the question.
Support, operations and finance each work different records and fear different mistakes. These six conversations settle which jobs the back office takes on, and what each operator may see and change.
Who works in the back office, which jobs they do every day, and which of those still go to an engineer, a database script or a spreadsheet.
Which customers, orders, content and documents operators work on, which system owns each record, and which fields the back office may change rather than only show.
Who may see, edit or delete each kind of record, and which changes, such as refunds, deletions and bulk edits, need a second person before they apply.
The cases the product cannot settle on its own, how each one reaches a person, who owns it, and how long it may wait before someone is told.
What the history keeps for each change, including values before and after, how long it is kept, who may read it, and how a wrong change is reversed.
Requests closed without an engineer, minutes per case or corrections made by hand, measured before the build starts and again once operators use it every day.
A back office is many similar lists, forms, filters and bulk tools over one data model, so coding agents take most of it. Senior engineers write the permissions, the sign-off rules and the change history, because a mistake there lets an operator delete what they should only see, or leaves a refund nobody can trace.
AI-native product developmentA back office cut down to the common screens sends every other job back to an engineer. Faster implementation lets the less frequent jobs follow soon after the first release.
Working screens on anonymised records reach the support team early, so the order of fields and steps comes from the people who use them all day, not from a specification.
Who may see, change and delete each record, down to single fields such as bank details, is designed and reviewed by a senior engineer, never left to generated code.
The change log is written by the server, not the screen, and kept where the operators it records cannot alter it, so it still answers an auditor’s question a year later.
Agents help write the preview and validation for each bulk tool, and a senior engineer reviews how it is reversed, because one wrong import can change thousands of records at once.
Six situations, from a shared spreadsheet to a back office someone else built.
We start with the jobs your team most often hands to a developer or works from a spreadsheet, build screens for those first with roles and a change history, and add the rest once operators use it.
A first back office with only the jobs launch needs, such as users, content and orders, but with roles and a change history from day one, because adding them later means reopening every screen.
A generated admin panel shows tables, not jobs. We keep the screens that work and replace the ones operators work around. If a ready-made admin tool still fits your case, we say so.
We replace the old technology one part at a time while operators keep working, move the records and their history across, and keep every screen they depend on until its replacement is in use.
We take over through a knowledge transfer, read how permissions and the change log actually work before trusting them, and fix what blocks operators first while we learn the rest of the code.
Support, billing and content sit in separate tools that each hold part of the customer. We build one back office over their APIs, starting with the job that costs most, and keep the tools that already work.
Five stages. One operator team settles real cases in the third, so launch follows their cases rather than a demo.
Each operator job drawn as screens and steps and checked with the people who do it today, including the rare cases they currently send to an engineer.
FigmaRecords, roles, validation and the connections to your product and tools, delivered sprint by sprint, each sprint ending in a build operators can try on anonymised data.
React or Next.js, Node.js or .NET, PostgreSQLOne team settles real cases in the new back office with the old way still available, so missing screens and permissions show up before everyone switches.
Case and usage logsPermission and change-history tests, load tests on full record counts and a security review, then rollout team by team, each with its roles confirmed on the day it starts.
Permission tests, security reviewJobs still done in spreadsheets and scripts move into the back office one at a time, in order of how often they come up and how long they take.
Change history, case metricsSix parts, built around the change history, because every edit, sign-off and case an operator touches is written to it.
A support ticket, a failed payment or a flagged record
What this operator may see and change
Customer, orders and history on one screen
Against the same rules the product enforces
Refunds, deletions and bulk edits need a second person
Who changed what, and the customer told where needed
Fixes repeated by hand become rules in the product
Permissions per role for each type of record and each field an operator may edit, sign-in through the identity provider you already use, and access revoked from one screen.
An append-only log of who changed what and when, with values before and after, written by the server and kept where the operators it records cannot edit it.
Accounts, orders and documents read and written through your product’s APIs where possible, under the same validation rules, so the back office and the product never disagree.
Exceptions, failed payments and flagged records routed to a queue by rule, each with an owner, a status and the time it has waited.
Imports and bulk changes previewed before they run, validated against the product’s rules, and logged as one change so they can be reversed together.
In your product’s codebase or beside it on its APIs: React or Next.js front ends, Node.js or .NET services, and PostgreSQL or the database you already run.
An administrator app built beside apps for doctors and patients, the central reservation system behind a hotel booking platform, and a retail content platform where we extended the client’s own team.
Healthcare web platformMedical Research Association
Built for a French public health screening project, beside separate apps for doctors and patients, with speech-to-text and translation through Amazon’s API for multilingual communication. Third-party libraries were kept to a minimum to avoid vendor lock-in.
Read the Medical Research Association case studyIt depends on how many operator jobs the first release covers, how many systems it reads and writes, and how fine the permissions are. Set it against what the current setup costs: developer hours spent on support requests and corrections made by hand. After discovery you get a written figure for the jobs that cost your team most, sized to them rather than to a feature list.
Use a ready-made tool for a few tables and one team: a generated admin panel or an internal-tool builder is often enough, and we will tell you so. A custom back office pays off when one job spans several records and systems, when permissions differ by record or field, or when changes need a second sign-off and a history.
It depends more on access than on screens. Your product’s data and APIs, agreement on who may change what, and your security review usually set the date. After discovery, the written plan names one date for the pilot team’s first real cases and another for the rollout to every team.
The daily jobs that currently need a developer’s help, with roles and the change history built in from the start. Dashboards, rare jobs and a second team’s views come after, because none of them decides whether operators stop asking engineers for help, while roles added later would mean reopening every screen.
Yes. It changes your product’s data through its APIs, or its database where there is no API, under the same validation rules the product enforces. Helpdesk, payment and email tools connect through theirs. Where a tool cannot be written to, discovery says so and the plan works around it, for example with a link out and a note in the history.
Lists and search load one page of records at a time, indexes follow the filters operators actually use, and imports and exports run in the background so no screen waits on them. A new team gets its own role, queues and views, set up by an administrator rather than built by an engineer.
Each role sees only what its work needs, and fields such as bank details can be masked for everyone else. Every change is written to a history with who made it, when, and the values before and after, which operators cannot edit. Reading the history is a permission of its own, so it does not become a second way to see masked data.
You do. IP assignment is part of the contract. The repository, the database, the change history and the cloud accounts sit under your company from the first day, so the record of every change stays with you if we part ways.
Your operations lead decides, and the named engineer who signed the first release stays on to build it. The change history and the case queues show which jobs still take operators longest, so those come next. Small changes ship in small releases; larger jobs are scoped and quoted before work starts.
Purchasing and stock built as modules, cases that cross several systems, and a developer to keep extending the admin.
Send a screenshot of the spreadsheet your operators work from, or list the requests support sends to developers in a typical week.
In the first call we name the jobs we would build first and the data they need from your product. If a ready-made admin tool would do the job, that is what we recommend.
We sign an NDA before discussing your data in detail. We reply within 24 hours.
