Internal operations tools

Most internal processes work fine until two things happen together: volume rises, and the person who holds the process in their head is busy. What breaks is rarely the decision-making. It is the handoff — a step done twice, a step skipped, a status nobody can see without asking somebody.

So an internal tool gets judged on unglamorous questions. Is this the one place the state lives? Can a manager see status without interrupting anybody? Can a new employee follow it without a tutorial? Does it stop people keeping a private spreadsheet on the side? If the answer to the last one is no, the tool is not finished yet.

This is easy to underestimate, because the admin side is invisible from outside. The Domino Ra'anana project, about two months in total, shipped management screens for products, deals, categories, pizza sizes, beverages, sauces, delivery zones, site settings and orders. That list is the operational reality of a pizza branch, and every entry is something staff need to change themselves without calling a developer.

The design question inside each screen is which rules the tool enforces and which it leaves to a person. Delivery zones carry a delivery cost and a minimum order amount, so the tool enforces them at checkout. Deals can contain several products with their own selectable options, so the data model has to preserve that structure instead of flattening a deal into a discounted line item — otherwise the admin screen quietly loses the ability to express real promotions.

The most valuable part of an internal tool is often the point where it hands work to something else. On the Domino build a card order creates a pending order and a Cardcom payment URL, and only a successful payment triggers the rest: the status update, the customer and admin emails, and delivery of the order to the Aviv POS. Orders arrive at the register without anybody retyping them, which the owner, Eran Atra, describes as the biggest change the site has had.

Every handoff needs three answers before it is built: what proves the other system accepted the work, what happens when it does not, and who finds out. Skipping the second and third is how an integration looks finished in a demo and generates phone calls in production.

Reporting is the usual candidate: dashboards built before anybody has a question to ask of them tend to go unread. So are notifications for events nobody acts on, and permission schemes with more roles than the team has people.

The Domino project's own next steps are a good example of restraint. Pull the checkout rules into shared pure functions, so pricing, minimums and zone eligibility can be tested without rendering a page. Add the per-order event timeline. Add abandoned-cart follow-up only if the branch turns out to lose enough orders to justify it. That last condition is the part most feature lists are missing.

Domino's two months covered both sides: the public ordering flow and the admin and integration work behind it. A purely internal tool — one workflow, one team, a tracker with roles, notifications and exports — is a narrower job than that, because there is no customer-facing surface to design and no payment provider in the path.

What pushes it back toward two months is integration. Every external system the tool has to read from or write into is real work, and the POS handoff was one of the more demanding parts of that build. It is worth pricing the integrations separately in your own head before you judge whether an estimate is high.