We design and build digital products and software around real business processes. So your organization isn't forced into someone else's software.

The systems your staff open every morning.

The booking system, the till, the dashboard your staff open every morning, designed around how the work actually happens, not how software usually assumes it happens.

Build

From idea to usable product: discovery, UX research, wireframes, prototypes, and design systems.

Product design

Reservations

Front desk

Housekeeping

Rates and inventory

Payments and billing

Night audit

Reporting

Administration

Hotel Operations Command Center

Channels poll on an interval. The honest design holds a small availability buffer per room type during peak periods rather than promising instant synchronisation. The hotel has to accept occasionally selling one fewer room than it could.

Channel sync is not real-time, and pretending otherwise causes double bookings.

If housekeepers do not update status from their phones, the system degrades to an expensive booking book. The mitigation is designing that screen first, testing it with the actual housekeeping team in Phase 3, and being willing to change the process rather than the software if they will not use it.

Housekeeping adoption is the whole project.

Booking widget

Rates and availability

Channel sync

Payments

Booking management

Direct Booking Engine and Channel Sync

The honest design holds a small buffer per room type during peak periods, which means occasionally selling one fewer room than available. A hotel that refuses the buffer is choosing double bookings, and should choose it knowingly.

Channel sync is never instantaneous, and selling the last room on three channels at once is a real risk.

Room status board

Housekeeper application

Assignment

Inspection

Maintenance

Consumables

Housekeeping and Maintenance Mobile System

This is the smallest concept in the hotel set and the one most likely to fail, for reasons that are entirely about people. The application must be designed and tested with the actual housekeeping team before it is built, and the hotel must be willing to change the process rather than blame the staff.

If housekeepers will not use it, nothing else in the system matters.

Patient identity and registration

Appointments and queue

Clinical

Pharmacy

Laboratory

Billing

HMO and claims

Inpatient

Access control

Hospital Operations & Patient Flow Platform

The honest design allows free text as the default with structure applied where it is genuinely needed, allergies, diagnoses, prescriptions, and accepts that the narrative portion will be less analysable. Forcing full structure produces either empty fields or fabricated ones.

Doctors will abandon structured notes if structure costs them time.

Digitising every existing card before go-live delays launch by months and much of it is never consulted again. The recommendation is to launch on new encounters and digitise a patient's history opportunistically at their next visit, accepting an incomplete record set for the first year.

Migrating a paper file room is a project in itself.

Strict role separation protects confidentiality but blocks emergency care. The system permits override, logs it heavily, and surfaces it in a review report, which only works if management actually reads the report. That is a process commitment, not a software feature.

Break-glass access is a genuine conflict.

Patient login

Appointments

Documents

Tasks

Billing visibility

Secure messaging

Consent and preferences

Patient Portal & Care Coordination

This depends on the underlying clinical and billing record being reasonably current. A hospital still running paper alongside the portal will show a patient a stale balance or a missing document, which damages trust faster than having no portal at all. Sequencing matters: this comes after the operational platform is stable, not before it.

A portal that reads from a record the hospital doesn't yet keep well has nothing good to show.

A patient who messages and hears nothing for three days will call anyway, and the portal becomes one more channel instead of a replacement for the phone. The hospital has to commit to a stated response window and staff to meet it, or the messaging module should stay off at launch.

Messaging with a care team creates a response-time expectation that has to be managed explicitly.

Student records and admissions

Classes and staff

Attendance

Assessment and results

Fees

Communication

Parent portal

Reporting and administration

School Operations & Parent Portal Platform

A parent transferring from a personal account with no reference cannot be identified automatically. The system narrows the work, matching by amount, by sender name against guardian names, by exact reference, and presents the bursar a short queue instead of a full statement. The honest claim is that it turns a fortnight into an afternoon, not that it eliminates the task.

The transfer-matching problem is not fully solvable and should not be sold as if it were.

Teachers who currently hand in a paper mark sheet are being asked to type. The mitigation is a spreadsheet import as a permanent supported path, not a temporary concession, plus mark entry designed for a phone. A school that forces the issue gets marks entered by one overworked administrator at term end, which reintroduces every error the system was meant to remove.

Teacher adoption of mark entry is the risk.

Most parents will keep calling the office for the first year. The portal earns its place through automated messages pushing information outward, not by waiting for parents to log in.

Parent portal adoption is slow.

Menu and pricing

Order capture

Kitchen

Inventory

Payments and accountability

Delivery

Customers

Restaurant Operations & Channel Control Platform

Portioning varies, spillage happens, recipes are approximate. The value is in the size and direction of the variance over time, not in any single count. This has to be explained to the owner during scoping or the tool becomes a weapon and staff start defeating it.

Theoretical stock will never match counted stock, and a system that presents variance as theft will be switched off.

Where a platform offers no API, orders are entered manually and that double entry is a permanent cost, not a temporary workaround. Saying so upfront is better than discovering it at go-live.

Aggregator integration is partial and outside Afivox's control.

Some kitchens genuinely work better on paper. The honest recommendation in a small kitchen may be a printed ticket driven by the system rather than a screen, and the design should support both.

A kitchen display replaces a physical ticket that staff can hold, mark and move.

Menu browsing

Order placement

Loyalty

Customer profile

Feedback

Table Reservations & Loyalty Experience

A points balance nobody can be bothered to redeem is a cost with no benefit. The honest design keeps redemption to one step at the point of sale, and the restaurant should expect low early redemption rates rather than treat that as failure. It takes time for customers to learn a program exists.

Loyalty only works if redemption is genuinely easy, or it becomes a program nobody uses.

Selling loyalty and reservations before order and kitchen operations are stable means building a nice front door onto a shaky house. Matching the parent platform's own trade-off note, this is a genuine phase two, not a starting point.

This depends on the operational base already being trusted.

Order intake

Dispatch

Driver application

Tracking and customer communication

Exceptions

Fleet

Costing and invoicing

Customer portal

Fleet Dispatch & Delivery Control Tower

Continuous location tracking drains battery, consumes data, and changes the relationship with drivers, particularly contracted ones. The recommendation is location captured at status events rather than continuous breadcrumbing, which answers the questions that actually get asked at a fraction of the cost and friction. A business that insists on continuous tracking should do so knowingly.

Live GPS tracking of drivers is a management decision before it is a feature.

Riders paid per delivery will not use an application that slows them down or costs them data. The application must be small, must work offline, and must be tested with actual riders before it's rolled out. Where riders are contracted rather than employed, the business may have no authority to mandate it at all, and that has to be established before the build, not after.

Driver adoption is the project.

Traffic here is not predictable enough to promise a time. The system communicates a window and tracks performance against it. Promising precision the operation cannot deliver converts a logistics system into a complaint generator.

Estimated delivery times will be wrong.

Point of sale

Repairs

Warranty

Purchasing and suppliers

Staff and accountability

Retail & Electronics Operations Platform

Without it, none of the warranty, theft-tracing or true-margin features function. They are all downstream of that one discipline. The honest framing during scoping is that this is a process change the owner has to enforce, and the software can only make it fast, not optional. A shop unwilling to commit to it should buy a simpler system.

Scanning every IMEI at intake and at sale is real work, and shops resist it.

Two units of the same model can have different costs, conditions and warranty terms. Modelling stock at the unit level rather than the product level is heavier to build and heavier to use, and it is the only honest design for this trade. It is the reason generic retail software fits this business badly.

Refurbished and used stock breaks single-price logic.

The system can enforce a recorded quote, which is correct, but it changes how staff work and will be resisted. Expect this to be the adoption fight, and decide during scoping whether the owner will back it.

Repair pricing is frequently negotiated at the counter and not recorded.

Fee structure

Concessions

Invoicing

Family billing

Payment recording

Statement import

Holding queue

Part payment and plans

Receipts

Debtors

Fees and Payment Reconciliation System

A parent transferring from a personal account with no reference is not identifiable by any algorithm. What the system does is narrow the work, exact-reference matches clear themselves, amount and name matching produce ranked suggestions, and the bursar is left with a short queue instead of a full statement. The honest claim is that it turns a fortnight into an afternoon. It does not eliminate the task, and a school expecting elimination will be disappointed by a system that is working correctly.

Transfer matching cannot be fully automated, and selling it as though it can is how this project fails.

Class structure

Register

Absence detail

Alerting

Summaries

Messaging

Delivery tracking

Message log

Attendance and Parent Communication

A school of 400 students sending two messages a term to every family is not expensive; a school sending absence alerts daily during a flu week is. The system must show projected and actual messaging spend, and the school must decide its own alert thresholds with that cost visible. A vendor who does not raise this before go-live is setting up an argument in month two.

Messaging costs money per message, and schools routinely underestimate it.

Stock dashboard

Order intake check

Pick list

Packing

Dispatch handover

Warehouse Inventory & Last-Mile Coordination

If staff pick from the shelf without confirming on the device, the system's stock figure drifts from reality within days. The honest design makes confirming fast, a scan, not a form, but the business has to actually enforce it, or the count becomes exactly as unreliable as before, just with a screen in front of it.

Real-time stock accuracy depends on picking discipline, and the system can't create that discipline by itself.

A parcel marked dispatch-ready here has to actually reach the dispatch board on the other side. If that handover isn't reliable, a parcel can sit ready in the warehouse while dispatch thinks it doesn't exist yet. The integration between the two needs to be treated as seriously as either system on its own.

Warehouse and dispatch are two systems that have to agree, and the handover between them is where problems hide.

Dispatch board

Multi-stop trips

Job detail

Status progression

Proof of delivery

Failure capture

Cash on delivery

Sync

Driver Application and Proof of Delivery

This has to be established before the build. A rider paid per delivery, using their own phone and their own data, is being asked to absorb a cost for the company's benefit. The workable answers are a data allowance, a small per-job uplift, or employment. All commercial decisions, none of them software. A business that assumes compliance will discover at go-live that half its riders are still using WhatsApp.

Where riders are contracted rather than employed, the business may have no authority to mandate the application at all.

Tracking link

Status display

Delivery window

Notifications

Proof access

Corporate view

Failure communication

Customer Tracking Portal

If drivers are inconsistent about marking collection, customers see deliveries stuck at "collected" for a day and lose more confidence than the phone calls were costing. This should not be sold to a business that has not first fixed capture, which usually means the Driver Application and Proof of Delivery concept comes first, even though this is the smaller and more attractive purchase.

This system is only as good as the status data behind it, and publishing bad data to customers is worse than publishing none.

The design shows status and location at status events only, which answers the question customers actually ask.

Exposing a driver's live location to customers is a privacy decision affecting a third party who has not consented.

Intake

Custody terms

Job ticket

Diagnosis

Quotation and approval

Parts

Technician

Status flow

Notification

Collection

Uncollected ageing

Device history

Repair Workshop Management

Repair pricing here is routinely negotiated face to face and adjusted mid-job. The system can require a recorded quote and approval, which is the correct design and the only thing that protects the shop in a dispute, but it removes flexibility staff currently rely on. Whether the owner will back that enforcement is a Phase 2 decision, and if the answer is no, the feature should be advisory rather than blocking. A blocked workflow that staff resent gets bypassed within a week.

Enforcing a recorded quote changes how the counter works, and staff will resist it.

Product design

From idea to usable product

Discover

Define

Design

Prototype

Build

Improve

A hospital doesn't just need a website

Related work

Hotel Operations Command Center

Direct Booking Engine and Channel Sync

Housekeeping and Maintenance Mobile System

Hospital Operations & Patient Flow Platform

Patient Portal & Care Coordination

School Operations & Parent Portal Platform

More from Build

Custom software

Web applications

Mobile applications

Business systems

Let's map how your operation actually runs.