The admin is the product

A visitor spends ninety seconds on your public site. A receptionist spends eight hours a day in your back office, five days a week, for years.

Now compare how the budget was split.

Almost every project I inherit has spent it the wrong way round: months on the marketing site, and an administration interface that is whatever the framework generated, never opened by the person who commissioned it. The staff work around it. They keep a parallel spreadsheet, because the spreadsheet is faster. And then the system's data is wrong, and everyone blames the system.

What "the admin is the product" means concretely

The screen matches the decision, not the table

A default admin gives you one form per database table, which is a picture of your schema rather than of anyone's job. The receptionist is not editing an Appointment row - she is fitting a patient in on Thursday while looking at who else is in that day. Those need different screens even though they touch the same table.

Anything the owner might change is a row, not a deploy

Prices, opening hours, email wording, the consent text, the legal footer, which fields are required. If changing any of those means a developer, then you have not delivered a system, you have delivered a dependency on yourself. I treat "would somebody plausibly want to change this without me?" as the test, and the answer is yes far more often than it feels.

The dangerous actions look dangerous

Deleting, refunding, sending to every customer, overriding a lock. These need friction proportional to their consequence, and - more importantly - a record of who did it. Not to catch anyone out, but so that "what happened here?" is a question with an answer.

It works on the machine it will be used on

Often an old laptop on a slow connection at a reception desk, or a phone in a warehouse. An admin that is pleasant on a developer's monitor and unusable on the hardware it is meant for is not finished.

The test I use

Before handover, I sit with the person who will use it most and watch them do a normal day. Not a demo - their actual work, with me saying nothing.

Every time they hesitate, that is a design defect. Every time they open a spreadsheet instead, that is a missing feature. Every time they ask "can I undo that?", something needs a confirmation or a history.

It takes an hour and it is the single most valuable hour in any project I have done. It has never once produced no changes.

Why this is a commercial argument, not an aesthetic one

The public site's job is to get an enquiry. The back office's job is to make the business run. Bad marketing costs you leads you never knew about; a bad back office costs you an hour a day, every day, per member of staff, plus the data quality that every report and every decision downstream depends on.

Spend accordingly.

Although the cheapest version of this is not building the back office at all, if somebody already sells one that fits. That is the note about when not to build.