Your team manages orders in a spreadsheet, approves requests by email and opens a ticket every time a record needs fixing. Sooner or later someone says you need a custom back office. They are often right. But the phrase can mean three settings in a tool you already own, or a whole piece of software that you will have to maintain for years.
I design and build websites and tools on my own, from scoping to go-live. I configured the back office of this site myself, and I show you below what it contains. Before that, here is the question I ask before talking about tools, the three possible routes, and the checklist I fill in before starting the work.
01What a back office has to let people do, before we talk tools
Most requests arrive as tables: we need a screen for customers, one for orders, one for products. I start somewhere else. I ask which decisions the team makes every day, and what they need in front of them to make those decisions. "Approve any order above a certain amount", "chase an incomplete file", "move an article from to review to reviewed". Each decision becomes a screen or an action. The tables follow.
Nielsen Norman Group makes a point that changes how you judge an internal tool. In its CASTLE framework for workplace software, it notes that users did not choose the tool, so measuring adoption or retention tells you very little. The framework looks instead at mental effort, task efficiency, learnability and errors. Its example of cognitive load rings true for me: having to remember which record you were checking while going back and forth between a long list and the detail page.
It is the same reflex I use at Moonworkers, my company: the product was designed from its users, with personas and wireframes, before any code was written. An internal tool has users too. They just sit next to you, which makes them easier to forget.
02Configure, assemble or build: three routes to a custom back office
I sort the options into three families, from the cheapest to maintain to the most expensive.
Configure the tool you already have
Almost every CMS, ERP or CRM has an admin interface you can adjust: filtered lists, hidden fields, roles, views by status. It is often enough, and it is the route I suggest first. Sanity, for example, shows a long list per document type by default. Its documentation on the Structure Builder shows how to build lists suited to editorial work, filtered by a query.
Assemble an internal tool
When the data lives in several places, you can assemble an interface on top of it, with a base such as Airtable or an internal tool builder. I have described how I would set up an Airtable base to track content production: linked tables, views by status, simple automations.
A talk published by Retool, a vendor of internal tool software (so read it as such), shows this case well. In this recorded talk, a team of engineers at a payments provider explain that they used to receive tickets asking for account balances, sometimes handled the next day. A small tool where you paste an identifier removed that bottleneck. What I mostly took from it is why they did not code everything themselves: they would have had to build authentication, access restriction and audit logs on their own.
Build
Building makes sense when the business has rules nobody sells: a calculation, an unusual approval flow, a screen that has to fit an operator's exact gesture. It is also the route that costs the most to maintain. Whatever code you write today, someone will have to update it in two years.
03The back office of this site fits in a few lines
This site runs on Next.js and Sanity, with the Studio built in at /studio. I have explained elsewhere why I chose Sanity as a headless CMS. The back office itself is almost entirely configuration.
My content machine checks every article and then publishes it straight through the API, with a "to review" status. So I almost never create content in the Studio. I use it for a single decision: have I reviewed this article on the live site, yes or no? I automated publishing before producing more because the bottleneck was getting things online. What remained was making the review easy.
In practice, the Studio holds three settings:
- an "Articles to review" list at the top of the menu, filtered by a one-line query on the editorial status;
- a status field with two values, "To review" and "Reviewed", shown as radio buttons;
- the gate verdict, its justification and the date sent, all read-only.
The last point matters more than it seems. Sanity's documentation on conditional fields explains that the `readOnly` property locks a field, either permanently or under a condition. I do not want to be able to change, by mistake, the record of what the machine checked. I can read it, I cannot rewrite it.
There is also a limit I learnt on client work: a site can look fine to the logged-in team and be broken for visitors, because of caching. The back office shows what is saved, not what the public sees. So I review every article on the public page, never in the form.
04Access rights and logs, the part that gets put off
In many specifications, the screens are described in detail and the access rights take up one line: "one administrator and some users". That is where problems turn up, six months after go-live.
France's data protection authority, the CNIL, gives a simple baseline in its guidance on managing access rights (in French). Profiles that separate duties, every access request approved by a manager, rights removed when someone changes role or leaves, and a review at least once a year with the business teams. It advises against untracked shared accounts and administrator rights handed out "just in case".
Its guidance on logging operations (in French) sets out what a log should keep: who created, viewed, changed or deleted which data, with the date, time and type of operation. It recommends keeping logs over a rolling period of six months to a year, and points out that these records must not be used to count working hours.
If you build your own, the Next.js authentication guide recommends a proven library rather than a home-made solution, and authorisation checks placed close to the data rather than in the layout. That is exactly the work the team in the talk did not want to redo.
05The checklist I fill in before starting the work
It gets filled in with the team, before choosing the route, not after.
Decisions and people
- List the decisions made every day or every week, with the person who makes each one.
- For each, note what you need to see to decide, and what happens next (an email, an update, an invoice).
- Spot the decisions that currently go through a ticket, a spreadsheet or a message to a developer. Those are your priorities.
Rights and records
- Write the profiles (who sees, who edits, who approves, who deletes) before the screens.
- Decide what must be logged, for how long, and who can read the log.
- Plan for leavers and cover: who removes access, and when.
Actions and mistakes
- List the useful bulk actions (approve twenty records at once, export a selection).
- Decide what can be undone and what cannot, and protect the second group with a confirmation step.
- Lock as read-only whatever serves as evidence: an approved amount, a check status, a sent date.
The test
- Make a clickable mock-up of the two or three main screens and test it with the people who will use them. I explain why I go through a clickable prototype before development: you find the pointless back-and-forth before it costs code.
If the checklist fits within the settings of your current tool, you do not need to build anything. That is an entirely possible outcome, and a good one.
06When I would not build a custom back office
I do not recommend it while the need is still vague. If the team changes the way it works every month, a built tool will freeze the version from the month you ordered it. A well-kept spreadsheet, or an assembled base, can be changed in an afternoon.
I do not recommend it either as a way round a management system that has not been fully set up. One more screen on top of a badly configured ERP adds a layer to maintain without fixing the cause. And I do not build native mobile apps: if your internal tool has to live on field staff's phones, you will need someone else for that part.
Finally, custom work keeps costing after delivery. Every framework update, every new profile, every export the finance team asks for goes through someone who knows the code. You need to know that before signing, not after.
07Where to start this week
Spend an hour with the two or three people who handle the data day to day. Ask them for the five decisions they make most often, and where they lose time on each. Write down who has access to what today, including the shared accounts nobody mentions. With those two lists, you will know whether a setting is enough, whether an assembled tool will do, or whether building is justified.
If you would like an outside view on that choice, I do this kind of scoping in a few days, and you can see what I build and how I work. Happy to talk it through.