Galal Osama Law Firm & Legal Consultations

We started from how the firm actually receives work rather than from a page layout. Three things shaped every decision that followed.

The first is that enquiries are short. A prospective client does not write a brief; they write two lines saying what the matter is about. Building an open-ended message box would have produced long, unstructured text that nobody reads. We capped the enquiry field instead.

The second is that the firm answers by phone. Whatever the website collects, the next step is a call. So the record the office sees is built around the phone number, and every contact detail on it is actionable rather than merely displayed.

The third is that a law firm cannot publish unvetted statements about itself. Client reviews are valuable and cannot be an open comment box. That single constraint is what turned this from a brochure into a system with a gate in the middle of it.

The system enforces one rule, and that rule is the reason it is a system rather than a set of pages: anyone may submit, only the firm may publish. It applies twice, in two chains that run end to end without anyone retyping anything.

Consultation intake. A visitor completes the form. The record appears in the office inbox immediately, flagged new and outlined so it stands out. When someone has spoken to the client they mark it contacted, and the record's state changes permanently. The enquiry is capped at 50 characters, so what lands in the inbox is a summary the office can scan rather than an essay.

Review moderation. A client writes a review and is told plainly, at the moment of submission, that it will appear after the firm has reviewed it. The review is stored immediately but withheld. It sits in a moderation queue, badged as held, until an administrator releases it. The moment they do, it is live on the public site — no rebuild, no redeploy, no developer.

The withholding is not a convention in the interface that a determined visitor could route around. It is enforced in the database rules: a review may only be created in the unapproved state, and the public may only read reviews that are already approved. The interface and the rules say the same thing, and the rules are the ones that count.

Access to client data is a single, auditable boundary. The database rules define what may be done by an anonymous visitor and what requires a session, and everything not explicitly permitted is denied by a catch-all rule at the end. Six rule statements cover the two collections and that final denial.

Every consultation and every review carries a server-assigned timestamp, so the order of arrival is the database's account of events rather than the client's. Consultations carry a contacted flag; reviews carry an approval flag. Both are states in the record, not something an administrator has to remember.

The access boundary is shown being enforced rather than asserted: a rejected sign-in, a self-service password reset, and an in-panel password change with its strength requirements.