From choosing a service to a prepared property visit.to a prepared property visit.

The obvious option would have been one generic property form with a few fields shown or hidden depending on the selected service. I decided against that.

A buyer needs to explain the property they are considering, asking price, financing, whether an offer has already been made, where they are in the transaction, what worries them, and which questions are still unanswered.

A seller comes with a different situation. Relevant context may include ownership, whether the property is already listed, current asking price, known issues, previous buyer objections, work carried out, and what they want to improve before the next stage of the sale.

Those differences continue into the backend as separate validated data models rather than one oversized form full of unrelated optional fields. The public experience follows the same logic: calmer decisions for buyers and better preparation or regained control for sellers.

When somebody starts checkout, the application first creates its own booking reference together with the selected service and expected amount. That reference follows the transaction into Stripe.

The browser returning from checkout is not enough evidence that the booking should continue. The server still needs to know which booking was paid for and whether the payment matches what the application expected.

The Stripe webhook verifies the completed session server-side, including the booking reference, payment state, amount, and currency, before changing the booking to paid. Webhook events are recorded as well, because Stripe can legitimately deliver the same event more than once. State updates are protected so two requests cannot silently complete the same transition.

Only after payment is confirmed does the client receive access to the next part of the process.

A booking can include contact details, property addresses, asking prices, transaction status, financing context, concerns, access information, and other details about the property. Clients can also provide documents for the advisor to review before the appointment.

Stripe processes payments, Cal handles availability and appointments, and Resend handles transactional email. Each external service stays focused on its own job.

Once the booking is paid and access is verified, the client can see available appointment times and choose a slot. From there, the process moves into the buyer or seller intake.

The form is intentionally detailed because the information has a job to do. It tells the advisor what stage the client is at, what is already known, where the uncertainty is, and what should be reviewed before the appointment.

Clients can also attach supporting documents. Uploads are checked on the server, not only in the browser: file size and allowed formats are validated, and the file contents are checked rather than relying only on the filename or MIME type.

Once the final submission succeeds, the appointment is created and connected to the booking, client information, and intake. By the time the advisor opens the appointment, the administrative preparation should already be done.