The strongest local proof is not a feature count. It is one connected, inspectable journey in which salon-authored information remains authoritative from the public page through appointment creation and change management.
Customers pay the salon. ilinara does not process salon-customer appointment payments.
The guest arrives at a known salon and location, reads salon-controlled information, and continues into that salon's services. This is not a marketplace-discovery claim.
Selections that change duration, informational value, capability, or resources are resolved before availability. The browser displays the validated result; it does not invent it.
The journey requests times for the resolved service, location time zone, booking window, notice rules, and capable professional. A displayed time can still change before creation.
The server rechecks current information when the guest submits. The result can be confirmed, requested, or changed; the interface must not turn a click into a false confirmation.
The current build can be evaluated for viewing, rescheduling, and cancelling without a customer account. The full management URL is sensitive and must not enter help, analytics, or public copy.
Expired quotes, changed slots, changed policies, waitlist offers, and invalid links do not silently resubmit or fabricate success. Valid choices are preserved only where the current contract allows.
These boundaries keep the product's current scope explicit.
Start with the salon handoff that creates the most questions. The utility returns one practical action without asking for contact details.
Explore the Aysu demonstration