How I build websites as complete systems

I begin with a concrete customer action and follow it until the business can respond. Then I trace backward: what must be true before the interface is allowed to offer that action?

For an inquiry, this might end with one email accepted by Resend. For a booking, “success” may require a held slot but not yet an owner-approved appointment. For an order, it may require server-calculated totals and a captured payment before staff can begin fulfillment. The words on the button are simple; their contracts are not interchangeable.

Information architecture answers what a person needs to understand before acting. Interaction design answers what the system must reveal while that action is underway: prerequisites, price, availability, privacy boundaries, progress, errors, and a recovery path.

I map the happy path and the hesitant path. A customer who already knows what they want should move quickly. Someone who is unsure should be able to compare options without opening a second site or calling for basic information. That is why a useful architecture includes content ownership and state design, not only routes.

Responsive behavior, keyboard access, readable focus, reduced motion, and honest loading states belong here too. They are not a final accessibility pass. They decide whether the workflow can be completed at all.

Most expensive system mistakes begin when two parts of the product believe they own the same fact. The browser should not decide a commercial price. A database projection should not overrule a payment provider. A webhook should not be treated as a once-only message. An admin panel should not expose controls the underlying authority cannot honor.

Zube’s Grub makes this distinction especially concrete: Square owns payments, orders, and the operational catalog; Supabase holds application workflow and projections; the browser carries cart intent; staff controls move through protected server boundaries. By contrast, Kora Studio intentionally has no lead database. Its successful terminal state is an accepted owner email notification, so adding persistence would create a second responsibility without improving the workflow.

“Smallest” does not mean the fewest files. It means no subsystem exists without a responsibility, and no required responsibility is left to a manual accident. I escalate architecture only when the business workflow introduces a new kind of state, authority, or recovery obligation.

Five systems, five justified shapes

The browser is untrusted and disposable. It can help someone assemble intent, but the server must reload or validate every fact that affects money, permission, availability, privacy, or durable state. I keep that boundary legible: a route or server action accepts a bounded input, enforces the contract, calls one domain operation, and returns a user-safe result.

request
  → normalize and allow-list fields
  → reject unsafe or incomplete input
  → enforce authorization and abuse limits
  → ask the authoritative service to perform the work
  → persist only the workflow state the business owns
  → return an honest success, conflict, or recovery path

The shape is visible in real differences. Kora Studio uses a Server Action so the contact form can still submit when JavaScript fails; the server validates, rate-limits, sends one notification, and reports failure rather than claiming the message arrived. Divine Care’s Cloudflare function removes forbidden clinical keys and accepts only allow-listed scheduling and administrative fields. Elevate reloads availability before reserving a slot and removes an orphan lead if the hold loses a race.

Integrations live behind the same boundary. Secrets never enter browser bundles. Money stays in integer cents. External identifiers are treated as references, not proof that an operation succeeded. User-facing success waits for the level of evidence promised by the interface.

An admin interface is justified when someone repeatedly needs to review state, resolve exceptions, or change information without a code deployment. It is not justified because “professional websites have dashboards.”

Security is not only middleware around an already-decided form. It changes what the form is allowed to ask, where records may live, who can act on them, and what the system says when a dependency is unavailable.

Divine Care is the clearest example. The public site is intentionally zero-PHI. Its endpoint strips forbidden keys including diagnosis, medications, DOB, insurance identifiers, and clinical messages; it does not simply add a warning and hope people comply. The interface routes users toward scheduling and administrative callbacks while preserving phone and office contact paths for anything outside that boundary.

Other recurring controls include server-derived staff authorization, authenticated owner routes, row-level database rules, request size limits, origin checks, honeypots, rate limits, and provider signature verification. I choose controls in proportion to the data and action—not from a generic “security checklist”—but privileged state always stays behind the server.

Distributed work is not finished when an API returns 200 once. Providers retry webhooks, networks time out after accepting work, two people claim the same slot, credentials expire, and an email can fail after the underlying state changed. The system needs enough durable identity to determine what happened without repeating a side effect.

My recovery design depends on the consequence:

• Human inquiry: fail visibly and provide a direct alternative contact path.
• Competing booking: return a conflict, remove orphan state, and ask the customer to choose again.
• Payment or order: use idempotency, monotonic provider projections, signed webhooks, retryable claims, and reconciliation.
• Owner confirmation: make the transition explicit and make follow-up delivery retryable without repeating the decision.

This is why Zube’s Grub’s architecture contains durable webhook claims and reconciliation while Kora Studio’s contact form does not. The cost of ambiguity and the amount of state to repair are fundamentally different.

I treat build success as one signal, not the release gate. Verification follows the responsibilities introduced by the architecture: schema and unit tests for domain contracts, integration tests for persistence and providers, browser checks for complete user paths, and deployment checks for routing, headers, configuration, and recovery.

Handoff completes the operational story. The owner needs to know what they can change, what failure looks like, where work appears, and which external accounts the system depends on. Documentation should describe the current system rather than preserve every abandoned plan.

1. Trace the customer action into the business.

   The page is not complete until the resulting work reaches a state someone can act on.

2. Name the owner of every important fact.

   Browser intent, application policy, provider truth, and operator state must not compete silently.

3. Add architecture only when responsibility requires it.

   A database, dashboard, queue, or custom integration has to close a real workflow gap.

4. Make failure states honest and recoverable.

   Success copy should reflect accepted work, not optimistic intent.

5. Verify the same path the customer and owner use.

   Tests, deployment checks, and operational handoff should prove the system as a connected whole.