Trust & Security

The marketing sites I build, this one included, are static-first: pages are pre-built and served from a global edge network over TLS, not assembled live by a plugin CMS with a database behind it. There is no plugin stack to patch on a Tuesday night and no admin login bolted to the public site. Most of the attack surface that keeps small-business website owners up at night simply is not there.

The same architecture is why these sites stay fast under load. A traffic surge hits pre-built pages on an edge network, not a database.

Authentication

Where a project has client areas or dashboards, sign-in runs on dedicated authentication infrastructure (Supabase) with role-based access, never a homegrown password table.

Payments

Card payments are processed by Stripe, which is PCI-DSS certified. I never see or store card numbers, on my projects or my own site.

Code custody

Every project lives in version control from the first commit. Clients own their code, their content, and their accounts. If we ever part ways, everything comes with you. I build on that principle because I would demand it as a client.

Deployment

Changes ship through a build pipeline with type checks and build gates, not by editing files on a live server. If a build fails its checks, it does not deploy.

This site collects the minimum: contact form details you send me, and anonymous aggregate analytics. It runs without ad trackers, tracking pixels, or consent-banner theater, because there is nothing running that would require one. The full detail lives in the privacy policy.

Some of the providers behind this site (Stripe, Supabase, Vercel, Google) operate outside Canada, so data they process can be stored or processed outside Canada. I say that here because the privacy policy says it too.

For institutional projects, data location follows the engagement: where a public body requires hosting on its own infrastructure or within specific jurisdictions, the project is built to that requirement and the data-location posture is stated in writing per engagement.

I use an AI-assisted delivery toolchain, and it runs under written rules: client data enters third-party AI systems only with prior written approval, and every deliverable ships after my own verification. The full policy is public, because a policy that only exists when someone asks is not a policy.

Security questions get answered by the person who built the system, not routed through a ticket queue to someone who has never seen your project. That is the practical meaning of a single accountable builder: when something needs attention, there is no handoff chain to lose it in.

If you have a security question about this site or a project, email hello@kootenaymade.ca. Anything that looks like a vulnerability report gets read first and fixed fast.