A complete software product, built from scratch: five interfaces on one database, installed on the customer's own server.
Role: sole developer and designer — architecture, database, backend, all five frontends, the mobile app, the licensing system, and the product website.
Type: a product sold to multiple organizations, not a one-off build for a single client.
An organization with more than one building knows its people and knows its buildings — but not the relationship between them. Floor plans are CAD files only one person can open, seating lives in a two-year-old spreadsheet, room bookings sit in a calendar nobody can see, and maintenance requests are messages in a group chat. Then comes the question that costs millions — "do we lease another floor?" — and it gets answered by impression.
International products solve this, but they are cloud-only, priced per user per month, and their Arabic is a translation rather than a design. And most Saudi organizations — government and semi-government especially — will not put their building plans, their staff seating and their visitor logs on a third party's cloud.
A facility and workspace management system that installs inside the organization, bringing buildings, floors, spaces, employees, meetings, visitors and maintenance into one database, read and written by five interfaces:
| Interface | For |
|---|---|
| Admin panel | The facility manager: every module, report and permission |
| Employee panel | Employees in the browser: where a colleague sits, book a room, report a fault |
| Mobile app (iOS & Android) | Employees on the move — and a second mode that turns any tablet into a room-door screen |
| Room door tablet | Room status in a colour visible down the hall, instant booking, check-in |
| Signage screens | Floor directory, announcements, evacuation plan |
On top of it, a floor-plan editor that runs entirely in the browser: upload the plan, draw the spaces over it, calibrate with a single reference line, and the spaces carry real square metres.
These are not features. They are trade-offs I chose:
1. On-premise instead of cloud. Operationally the harder choice — no central updates, no access for diagnostics — but it is what makes selling to a government entity possible at all. The system runs inside an air-gapped network with no internet; what it would reach outward for (mobile push, cloud calendar sync) is optional and switches off with no effect on the rest.
2. Licensing switches a module off, it does not hide it. Each module is licensed on its own, and when it is off both its pages and its API endpoints disappear — a real reduction in attack surface, not a hidden menu item.
3. An image of the plan is enough; CAD is not required. Demanding CAD files with clean layers means a digitisation project before the customer can even start. So I built the editor to accept an image or a PDF and calibrate manually — that alone cut onboarding from weeks to hours.
4. Geometry is stored as ratios, not pixels. Every polygon is held as 0–1 coordinates of the plan's dimensions, so it renders correctly on the admin screen, on an employee's phone and on a door tablet with no recalculation. And it is sanitised structurally — the array is rebuilt point by point from bounded floats — rather than by cleaning a string.
5. No new password for employees. Sign-in is a one-time code to their work email, or SSO. A system that asks someone to create an account before they can report a broken light will not be used.
6. Arabic by design, not by translation. Right-to-left throughout, search that finds a name however it was spelled, correct Arabic in generated PDFs, and email templates editable in both languages.
I built the product's marketing site and the CMS behind it: Twig templates, content modules, landing pages, structured data, a sitemap, and a dynamic llms.txt.