In Alistera CRM, I separated the space, contract, invoice and payment. An office may be occupied and an invoice issued while the money has not yet arrived. To understand how the business operates, these states need to be linked without losing their distinctions.
I built a separate operational CRM for Alistera. It includes a space catalog, contracts, invoices, payments, planning and access management. It is a standalone product alongside the public website and the game: each has its own purpose and data.
This screen shows fictional offices, their states and rental relationships. It is a working catalog-interface example, not current Alistera space availability.
Office catalog
Archived interface · demo data
A space exists over time
The catalog contains 93 entries: 71 offices, 12 desks and 10 shared spaces. But a list alone is not enough. “Is this space available?” requires a date or period. The same office may be occupied today and available in a month.
A contract is therefore linked to an interval, and overlaps must be checked when data changes. The calendar helps a person see a conflict; server-side validation prevents one from arising from two tabs open at the same time.
An invoice is a request; a payment is an event
The financial model separates the invoiced amount, confirmed payment and its allocation. A partial payment does not have to settle the entire invoice. One transfer may need to be allocated across obligations. A “status” field cannot reliably replace these relationships.
Below are demo invoices and payment records. You can examine how the interface distinguishes an obligation from money received without using real financial data.
Invoices and payments
Archived interface · demo data
Money is stored as whole numbers in fils. This avoids common floating-point arithmetic surprises when adding and comparing amounts. That choice does not fix accounting by itself; it removes one unnecessary source of errors.
The history of financial actions is preserved. A correction should explain what changed rather than pretend the earlier state never existed. A business sometimes needs an uncomfortable truth about yesterday, not a perfectly tidied table for today.
The work does not end with the interface
The application uses React, Vite, Cloudflare Worker and D1. Sign-in and profiles are connected to the permission system; authorization is checked by the API, not just by hiding buttons. Planning is available as a list, a kanban board or a Gantt chart. The views differ; the tasks must remain the same.
An implemented CRM does not prove that the entire business already uses it for daily operations. At the verified stage, I can show the model, functions and technical checks; I do not invent usage figures or time savings.
This stage implements the catalog, contracts, financial records and planning. They can be examined using demo offices and invoices. Full daily adoption and measuring the benefit to the team are a separate stage, so there are no usage or time-saving figures here.
Related stories: Control and report versions · Alistera public website.
@nevsky_alexander
On Instagram: Dubai beyond the postcard — family, the city, discoveries and life between projects. On Threads: thinking out loud about design and AI. On YouTube: videos that need more room than a story. Follow me wherever you feel at home, and let’s keep in touch