VRM:Streamlining sales, inventory, and reporting for food businesses.
VRM
VRM:Streamlining sales, inventory, and reporting for food businesses.
VRM
VRM: Streamlining sales, inventory, and reporting for food businesses.
VRM: Streamlining sales, inventory, and reporting for food businesses.
Building VRMs back office, front office and mobile application platforms to create a clear trustworthy, and easy-to-use restaurant mangement experience.
Building VRMs back office, front office and mobile application platforms to create a clear trustworthy, and easy-to-use restaurant mangement experience.
Project overview
Project overview
Designers: Femisola Fatogun(Lead),Kehinde Orugun,Courage Egbude
Duration: 6 months
What I worked on
What I worked on
Design Direction
Back Office Module (Core screens)
Design system development
Prelude
Prelude
Some products begin with a bold vision. This one began with friction.
Running a food business should not feel like stitching together five different systems just to understand what was sold, what was left in stock, what needed to be reordered, and whether the business was actually making money. That was the tension sitting at the heart of VRM. We were not trying to make operations look more modern. We were trying to make them feel less heavy. The ambition was to have a connected system for ordering, point of sale, automatic reordering, menu costing, stock alerts, and reporting. That was the promise we were designing towards.
Some products begin with a bold vision. This one began with friction.
Running a food business should not feel like stitching together five different systems just to understand what was sold, what was left in stock, what needed to be reordered, and whether the business was actually making money. That was the tension sitting at the heart of VRM. We were not trying to make operations look more modern. We were trying to make them feel less heavy. The ambition was to have a connected system for ordering, point of sale, automatic reordering, menu costing, stock alerts, and reporting. That was the promise we were designing towards.
Why this had to exist
Why this had to exist
When we started, the real problem was not a lack of effort from restaurant teams. It was that too much effort was being wasted. Sales lived in one place, stock lived in another, and important decisions were still being made without a clear real-time picture of the business. In discovery, I participated in interviews with roughly 20–30 customers, repeated focus groups, and one recurring truth stood out: people wanted an all-in-one system, but many of them were not deeply tech-savvy, so whatever we built had to be powerful without becoming too intimidating. The team also reviewed products such as Square and Lightspeed, not to copy them, but to understand where the patterns were already strong and where a more grounded solution could be shaped for our own users.
When we started, the real problem was not a lack of effort from restaurant teams. It was that too much effort was being wasted. Sales lived in one place, stock lived in another, and important decisions were still being made without a clear real-time picture of the business. In discovery, I participated in interviews with roughly 20–30 customers, repeated focus groups, and one recurring truth stood out: people wanted an all-in-one system, but many of them were not deeply tech-savvy, so whatever we built had to be powerful without becoming too intimidating. The team also reviewed products such as Square and Lightspeed, not to copy them, but to understand where the patterns were already strong and where a more grounded solution could be shaped for our own users.
What we built
What we built
The product began to make sense once we stopped thinking of it as a single dashboard and started treating it like an operating system with two distinct layers.
The back office became the business brain: onboarding, dashboard, configuration, inventory, products, money management, payroll, and reporting. The front office became the rhythm of service: clock-in, register, dining, orders, and menu handling. That separation mattered. It meant owners and managers could shape how the business ran, while service teams could focus on speed and execution without being dragged through administrative complexity.
This was the point where the project became emotionally real for me. I was no longer designing isolated features. I was designing for the moment a business owner needed to trust the system, for the moment a staff member needed to take an order quickly, and for the moment a team needed one version of the truth instead of several conflicting ones. The dashboard had to orient. Inventory had to reassure. Configuration had to feel deliberate. Front-office flows had to move with the speed of service, not the pace of enterprise software.
The product began to make sense once we stopped thinking of it as a single dashboard and started treating it like an operating system with two distinct layers.
The back office became the business brain: onboarding, dashboard, configuration, inventory, products, money management, payroll, and reporting. The front office became the rhythm of service: clock-in, register, dining, orders, and menu handling. That separation mattered. It meant owners and managers could shape how the business ran, while service teams could focus on speed and execution without being dragged through administrative complexity.
This was the point where the project became emotionally real for me. I was no longer designing isolated features. I was designing for the moment a business owner needed to trust the system, for the moment a staff member needed to take an order quickly, and for the moment a team needed one version of the truth instead of several conflicting ones. The dashboard had to orient. Inventory had to reassure. Configuration had to feel deliberate. Front-office flows had to move with the speed of service, not the pace of enterprise software.
Challenges We Faced
Challenges We Faced
As with any large-scale project, the biggest challenges were not inventing features but knowing where to stop. The complexity of the platform demanded restraint, each screen had to be simple enough that users, regardless of their tech-savviness, could trust it from day one.
It wasn’t just about making a product work; it was about ensuring users could feel its ease. Navigating this balance between functionality and simplicity, especially under the pressure of deadlines, was emotionally taxing. But it was necessary. Confusion in a restaurant management system could cost businesses time and money.
As with any large-scale project, the biggest challenges were not inventing features but knowing where to stop. The complexity of the platform demanded restraint, each screen had to be simple enough that users, regardless of their tech-savviness, could trust it from day one.
It wasn’t just about making a product work; it was about ensuring users could feel its ease. Navigating this balance between functionality and simplicity, especially under the pressure of deadlines, was emotionally taxing. But it was necessary. Confusion in a restaurant management system could cost businesses time and money.
The Road to Beta
The Road to Beta
As the project neared the beta stage, we knew we had crossed the threshold between idea and execution. The platform had evolved from sketches to something people could use, test, and react to. Over 25 businesses had already onboarded, offering early feedback to refine the product.
While I left the team before the final launch, the product had already grown into something tangible; a product that would help food businesses thrive with the clarity and efficiency they so desperately needed.
As the project neared the beta stage, we knew we had crossed the threshold between idea and execution. The platform had evolved from sketches to something people could use, test, and react to. Over 25 businesses had already onboarded, offering early feedback to refine the product.
While I left the team before the final launch, the product had already grown into something tangible; a product that would help food businesses thrive with the clarity and efficiency they so desperately needed.
Closing Reflection
Closing Reflection
In the end, this wasn’t just about creating a product. It was about shaping the future of food businesses, helping them move from fragmented tools to a unified, intuitive experience. Despite the hurdles, seeing the project come to life, with tangible results and the potential to make a real impact, was a victory in itself.
In the end, this wasn’t just about creating a product. It was about shaping the future of food businesses, helping them move from fragmented tools to a unified, intuitive experience. Despite the hurdles, seeing the project come to life, with tangible results and the potential to make a real impact, was a victory in itself.