Case study 03
From a business-specific operations system to a reusable multi-business platform
PAON began as a practical operations system designed around the needs of one real café. Building it raised a broader question: which parts belonged specifically to PAON, and which were operational patterns that would look much the same in a restaurant, a shop or a small retail business? That distinction became the foundation for IMTISERVE.
Product StrategyOperations DesignPlatform ArchitectureMulti-Business Systems
The first task was not to design a platform. It was to make one café’s day work — the till, the menu, the stock room, the supplier orders and the wastage bin — inside a single system the people running the place would actually open.
PAON was built for a working café: a menu that changes, stock that spoils, suppliers who deliver late, and an owner who needs to know what happened today before deciding what to order tomorrow. Those constraints were not collected in a workshop. They were the conditions the software had to survive.
Selling, purchasing and inventory are usually separate products. In a café they are the same afternoon. PAON was designed so that what is sold, what is held, what is bought and what is thrown away are records in one operating environment rather than in four that have to be reconciled afterwards.
The system had to reach the customer, not only the back office. The item a customer orders and the stock the kitchen depletes are two ends of one record; separating them into unrelated systems is precisely how sales and stock stop agreeing with each other.
I worked from the operating problem through to the product architecture: analysing how the café actually ran, designing and building the system around it, learning from what implementation exposed, and restructuring the reusable parts into a broader platform direction.
The work described here is my own — the analysis, the product decisions, the design and the implementation. Where something is architectural intent rather than something built, this case says so rather than implying otherwise.
Worked through how the café actually operates: what sells and when, how the menu is configured, how stock moves, how purchasing is decided, and where wastage and adjustments enter the record.
Defined the operating surface — which activities belong in the same environment, what each record has to carry, and how the customer-facing and back-office sides connect to each other.
Implemented the system rather than specifying it for someone else to build. It is the reason the lessons in this case come from implementation rather than from review.
Ran real operating scenarios through the product — taking orders, moving stock, recording purchases and wastage — and checked that the resulting position agreed with what had actually happened.
Separated the requirements that belonged specifically to this café from the operational patterns that were not café-specific at all.
Reorganised those patterns so that business identity, terminology and presentation sit in configuration and modules rather than inside the platform core.
Carried the reusable operations into IMTISERVE as a business-neutral workspace, with business and location context established at entry rather than assumed.
Kept PAON as the business-specific reference environment rather than discarding it, so platform decisions could still be checked against a real operation.
PAON is the reason this case has anything to say. Product thinking that starts from a platform concept has nothing to test itself against. Product thinking that starts from a working business does.
The day’s selling sits next to the things that decide tomorrow’s: what is low, what has run out, what was purchased and what was wasted. It is a single business context rather than a set of reports that have to be assembled.
Stock position is presented as something to act on rather than something to look up — which is the difference between an operations system and a reporting screen.
The customer-facing ordering experience is driven by the same items, categories and prices the back office maintains. One record, two ends — which is what keeps sales and stock in agreement.
Building the system was what made the distinction visible. Some of what PAON needed was genuinely about this café. Much of it turned out not to be about cafés at all.
Belongs in configuration, content or a module
Belongs in the shared platform
This is an architectural classification, not a feature checklist. The capabilities on the right were not all built at the same time or to the same depth. Listing one here says where it belongs in the structure — it is not a claim about its maturity.
The move from one business to a platform was not a rewrite, and it was not a rebrand. It was a sequence of decisions about what deserved to become reusable.
Business-specific implementation
Build for one real operation, with its identity, vocabulary and workflow preferences intact rather than generalised away.
Observe real workflows
Run the operation on it. What the design smoothed over shows up here, and it does not show up anywhere earlier.
Identify repeated operational structures
Notice that selling, stocking, buying, counting and losing stock have the same shape in a café as they do in a shop — and that the differences are mostly in what they are called.
Separate configuration from platform logic
Decide, capability by capability, what is business configuration and what is shared core — and resist the temptation to answer that question generically.
Reusable multi-business operations platform
A business-neutral workspace that a specific business is configured into, rather than one that has been built around a particular business.
Business-specific behaviour belongs in configuration, not in the platform core.
A café, a restaurant, a shop and a small retail business share more operational structure than their vocabularies suggest. All of them sell items, group those items, hold stock, buy from suppliers, lose some of it, count what is left, and need to know what the day earned. What differs is what they call those things, what they sell, how they present it to a customer, and which rules they run by.
Selling, catalogue, inventory, supply, movement between locations, user and role context, and operating visibility. These are structured to be shared, because their shape does not change with the type of business.
Identity, vocabulary, catalogue content, presentation and the rules a particular operation runs by. These are designed to be set per business rather than written into the platform.
Where an operation genuinely needs something the others do not — food-service recipe logic, for instance — the platform direction is to hold it as a module rather than make every business carry it.
If those differences are written into the core, every new business becomes a change to the platform. If they sit in configuration and in modules, a new business becomes a setup. That is the whole of the argument.
This describes an architectural intent and a product direction. It is not a claim that the platform suits every business type, and where a capability is described as designed for, it is not being presented as a finished feature.
The clearest evidence of the shift is the first screen. PAON opens as PAON. IMTISERVE opens by asking which business you are entering.
A business code asked for before a user name means the workspace is not assumed. Business context is established at the door, and only then does the platform decide what this person is looking at — which is what allows one operating environment to serve businesses that have nothing to do with each other.
In PAON, that question never had to be asked. There was only ever one business, so its identity could sit in the product itself. Removing that assumption is a small change on screen and a structural one underneath.
This is what the access experience demonstrates: business context is established before the operational workspace. How that context is implemented underneath is not something a sign-in screen shows, and nothing about it is claimed here.
Inside, the vocabulary has changed. PAON’s Menu Items are IMTISERVE’s Products. PAON’s SELL, MENU and OPERATE groupings are IMTISERVE’s OPERATE, MANAGE and OVERSEE. The operations underneath are recognisably the same ones — what has gone is the assumption about what kind of business is running them.
Point of sale, shifts, sales, products, categories, inventory, purchases and transfers — the operating surface PAON needed, named in a way that does not presume a café.
The categories screen makes the architectural point in product copy: aisles, sections or departments, whatever the business calls them. Naming is something a business brings, not something the platform imposes.
The workspace carries a business and a named branch, and reports position by location. Shown here with a single branch — the point is that the structure a second one would occupy is already there rather than waiting to be retrofitted.
These are not two versions of one product, and the comparison is not a competition. One is a business-specific implementation. The other is the platform direction that came out of building it.
Business-specific implementation
Reusable platform direction
PAON was not replaced, renamed or discarded, and it is not a prototype that failed. It is the implementation that made the platform argument possible — and the environment where that argument can still be tested against a real operation.
The PAON implementation solved for one operating environment. More importantly, building it exposed which workflows were genuinely business-specific and which were reusable operational patterns.
Working implementation — the product thinking started from a functioning business-specific system rather than from an abstract platform concept.
Operational depth — customer-facing ordering, selling, inventory, purchasing and wastage were connected inside one operating environment.
Pattern recognition — implementation, not planning, revealed which operational structures could be reused elsewhere.
Platform abstraction — business identity, vocabulary and presentation could be separated from the shared capabilities underneath.
Broader product direction — the architecture moved toward multiple businesses and locations rather than remaining fixed to one café.
Stated precisely: this describes implemented software and a product direction. No market adoption, customer count, number of businesses using the platform, revenue, productivity figure, cost saving or production scale is claimed, and no claim is made that the platform suits every business type.
This was not primarily a question of making the original system bigger. It was a question of deciding what should remain specific — and what deserved to become reusable.
Building for one operation forces specificity: real constraints, real vocabulary, real edge cases a generic design would never have to answer. Building a reusable platform requires the opposite discipline — going back through those specifics and deciding which of them belonged to the business and which were never about the business at all.
The cases before this one each solve a bounded operational problem, or design a product around a domain. This one is about what happens after the first thing works: recognising the patterns inside a working implementation, and generalising them without hard-coding one business’s identity into the core of the platform.
Observe Implement Recognise Separate Generalise
PAON provided the operating reality. IMTISERVE emerged from the work of finding the patterns inside that reality and translating them into a broader platform structure — with PAON still there to check the translation against.
This case study shows implemented product views from PAON and IMTISERVE. No customer, supplier, employee, credential, private address, internal identifier or confidential commercial figure appears. The IMTISERVE captures are from a demonstration environment; the PAON captures are from a business date with no trading activity recorded. Menu items and prices are the café’s own published customer-facing information. Window chrome, browser chrome, a development host address and a desktop taskbar were removed by cropping. The product-evolution diagram is an editorial representation of the design progression, not a depiction of software.
Contact
If a system that works for one operation is being asked to work for several — and the question is what to generalise and what to leave alone — describe the situation. I'll tell you how I'd approach it.