LuxorItPro

Sheet 04/16Business websiteCompleted

LuxorItPro website and contact pipeline

This site — React front end, Supabase storage, Cloudflare hosting, email notification.

Fig. 01 How an inquiry is stored before it is sent
How an inquiry is stored before it is sent How an inquiry is stored before it is sent. Contact form (Checked before the network). Then Submission row (Insert-only for the public). Then Edge Function (Asked after the row exists). Then Email notification (Failure is not a lost inquiry). Arrows show the write path between components; a dashed arrow marks data derived from another component. Contact form CHECKED BEFORE THE NETWORK Submission row INSERT-ONLY FOR THE PUBLIC Edge Function ASKED AFTER THE ROW EXISTS Email notification FAILURE IS NOT A LOST INQUIRY

Drawn from the Approach section. The email is best-effort: the row is already stored before the notification is attempted.

Problem

The previous site described services in general terms, and there was no dependable path from an inquiry to an inbox. A contact form that loses a message is worse than an email address, because the sender believes the message arrived.

Our role

Design, build, deployment, and the contact pipeline end to end. This is our own site: it is a completed build, not a client engagement.

Approach

The site is a single-page React and Vite build with a hand-written design system — no component library, no page builder — deployed through Cloudflare Pages on Cloudflare DNS. The shell revalidates on every request while hashed assets are cached permanently, so a deploy is picked up immediately without refetching unchanged files.

The contact path is deliberately two-step. A submission is validated in the browser, then written to a Supabase table under an insert-only policy for the public role: the form can add a row and nothing else. Only after the row exists does the browser ask a Supabase Edge Function to send the notification email through Resend, from [email protected]. If that call fails, the submission is already stored — the failure is a notification problem, not a lost inquiry.

Spam is handled with a honeypot field that is invisible to people, plus length and format checks before anything touches the network.

Representative code

The ordering is the design decision worth showing: persist first, notify second, and never let the notification failure undo the record.

const { error } = await deps.client.from('contact_submissions').insert([{
  name: values.name,
  email: values.email,
  phone: values.phone || null,
  company: values.company || null,
  service: label || null,
  message: values.message,
}]);

if (error) {
  return { ok: false, reason: 'server', message: `We could not save your message…` };
}

try {
  await deps.fetchImpl(`${deps.config.url}/functions/v1/send-email`, {
    method: 'POST',
    headers: { apikey: deps.config.anonKey, Authorization: `Bearer ${deps.config.anonKey}` },
    body: JSON.stringify({ name: values.name, email: values.email, service: label, … }),
  });
} catch {
  // Stored already; the email notification is best-effort.
}

return { ok: true };

Outcome

One codebase to extend, and a contact form verified end to end: a submission is stored, the notification is delivered, and the sender and recipient addresses were confirmed rather than assumed. The legal pages, metadata, and structured data are part of the same repository, so the site and the company it describes stay in step.

Notes

The notification email is best-effort by design: if Resend is unavailable the row is still stored, and the inquiry is recovered from the table rather than from a dead letter queue. No analytics or advertising scripts are loaded, so there are no traffic figures to quote here.

All case studies Start a project