Alpha PMS replaces the messy middle of a business: spreadsheets, disconnected tools, double entry, and reports no one trusts. We build hotel platforms, GPS fleet tracking, ERP/CRM, AI automation, and internal web apps around how operators actually work.
System map Select a node to inspect its role.
Company record · 2026
01 What we build
Our own products run in the field, so custom work starts from what we already know: rooms, vehicles, stock, invoices, approvals, users, and money. The job is simple to say and hard to do: put the work in one system and make the numbers reconcile.
S—01 In production
Hospitality platform
AlphaPMS is our hotel and restaurant platform: reservations, front desk, procurement, accounting, and POS in one place. It is software used by operators, not a slide deck, which keeps our custom builds grounded in real hotel work.
S—02 In production
GPS & telematics
Alphatrace tracks fleets and valuable assets in places where signal, roads, and recovery workflows are not always neat. Operators get live location, trip history, geofences, alerts, and dashboards they can act on.
S—03
Bespoke enterprise systems
Most companies do not need another generic CRM. They need one place for customers, documents, approvals, inventory, invoices, and reporting. We build that around the way the company already works, then tighten the parts that need controls.
S—04
Automation inside the workflow
AI belongs where the work already happens. We add extraction, review queues, decision support, and LLM features inside the business system, with logs, permissions, and a human review path when confidence is low.
02 The stack
When one team owns the schema, services, and interface, fewer things get lost in translation. The ledger balances, tenant isolation is enforced at the data layer, and automation has a clear place to stop and ask a person.
-- double-entry posting · isolated by RLS
insert into journal_lines
(entry, account, ccy, debit, credit)
values
(:e, '1000-cash', 'AED', 0, :amt),
(:e, '4000-revenue', 'AED', :amt, 0);
-- a posting that can't balance can't exist
select sum(debit) - sum(credit); -- => 0// role-scoped: a clerk only sees their property
export const postCharge = procedure
.input(z.object({
folioId: z.string(),
amount: z.number(),
}))
.mutation(async ({ ctx, input }) => {
await assertRole(ctx, 'front_desk')
return ledger.post(ctx.tx, input)
})# extract line items — escalate low-confidence
doc = await extract(invoice, schema=LineItems)
for item in doc.items:
if item.confidence < 0.92:
queue_for_review(item) # ask a human
else:
post(item)03 Selected work
Names stay private — we work under NDA as standard. The shape of the work does not: these are the kinds of systems we build and run.
W—01
Hotel group · Dubai
W—02
Industrial group · Central Africa
W—03
Hospitality operator
W—04
AI tooling engagement
04 Engineering standards
Principles, not certificates. These hold on every engagement, at every size.
Row-level security in the database itself. Tenant boundaries live next to the data, so isolation does not depend on every service-layer check being right.
Financial records are double-entry by construction. An unbalanced posting is rejected, not recorded.
Permissions are scoped to roles and enforced in the service layer. A front-desk login sees the front desk, nothing else.
Postings and automated decisions are recorded with their author and their timestamp. Corrections are new entries — history is not rewritten.
Systems go live with automated backups and a written recovery procedure.
Client data belongs to the client. Schemas are documented, and full export in open formats is available on request.
Automation acts alone only above a set confidence threshold. Everything below it is routed to a person, and logged.
These are engineering standards, not certificates. Ask how any of them is implemented and we will walk you through it.
05 How an engagement runs
Every engagement runs the same way. The people who scope the system build it, and the people who build it answer for it in production.
Before screens, we map how work moves today: who approves, what must reconcile, where errors enter, and what must not break.
You receive A written scope with architecture, timeline, and price.
Schema, access model, and ledger come first. Roles, audit trails, posting rules, and tenant boundaries are part of the first version, not cleanup work.
You receive A deployed skeleton — database, security policies, and core services, running.
Working software ships weekly into an environment you can open and use — real workflows and edge cases, not a demo of the happy path.
You receive A weekly release with a changelog measured against the scope.
We run the system in production, then transfer it in a state your team can hold: conventional tooling, clear naming, documented decisions.
You receive Source code, documentation, credentials, and runbooks, with support terms in writing.
06 Company
Alpha PMS FZCO is a software company licensed in the Dubai Multi Commodities Centre (DMCC), United Arab Emirates. We design, build, and operate production systems for hospitality, fleets, finance, and operations across the Middle East and Africa.
The company is founded and led by Joseph Hamze, and works directly with founders and operators.
I put my name on every system we ship. I review the schema, the access model, and the ledger before anything goes live, and I answer for the result in production. There are no hand-offs.
Joseph Hamze — Founder, Alpha PMS FZCO
07 Start a project
Tell us what is messy, slow, or stuck in spreadsheets. A useful brief is simple: what the business does, what needs to change, who uses the system, and what must not break. We work under NDA as standard, and you will hear back within one business day — from the person who scopes the work.