Our approach
Many store breaches start with an outdated plugin, a shared password, or third-party code nobody reviewed. We avoid those by design: custom code instead of plugins, as few moving parts as possible, and tight access control on every account we touch.
This website
- Served over encrypted HTTPS connections.
- Built as a static site, so there's no database, login, or server-side code for attackers to target.
- No analytics, advertising, or chat scripts. The only outside services it uses are Google Fonts for its typefaces and Formspree to deliver the contact form.
Stores we build
Every store is built for its owner, but these practices apply to every project:
- No plugin sprawl. Features are built into your system, so there's no marketplace code with its own update schedule and vulnerabilities.
- Encrypted everywhere. HTTPS on every page, plus DDoS protection at the edge network.
- Secrets out of the code. API keys for payments, shipping, and accounting live in encrypted environment settings, never in the code.
- Tracked changes. Every change goes through version control, so it's reviewed, recorded, and can be rolled back.
- Kept current. On an ongoing retainer, we apply security updates to your store's frameworks and libraries.
Payments
Card payments go through PCI DSS compliant processors such as Helcim. We use the processor's secure payment fields, so card numbers go straight to the processor and are never sent through or stored on the store's servers. That keeps most of the PCI compliance burden with the processor.
Account access
- We work from our own logins with only the access we need, and you can revoke it at any time.
- We use two-factor authentication on every account we use to work on client projects.
- When a project ends, or whenever you ask, we remove our access to your accounts.
Reporting a vulnerability
If you think you've found a security issue in this site or a store we built, email [email protected] with a description, steps to reproduce it, and any relevant URLs or screenshots.
When testing, please:
- give us reasonable time to fix the issue before sharing it publicly;
- don't access, change, or delete data that isn't yours, and stop once you've confirmed the issue;
- don't run denial-of-service, spam, or social engineering tests.
We'll confirm we received your report, keep you updated while we fix it, and credit you if you'd like. We won't take legal action against good-faith research that follows these guidelines.
Our contact details are also published in security.txt.