Checklists you can use today.

Guide 01

The Local Business Website & Domain Ownership Checklist

Use this when a shop, a nonprofit, or a conference is not sure who actually owns the website. The goal is simple: the organization can log in, the mail keeps working, the site is on HTTPS with real security headers, the hosting bill is explainable, and every edit is in version control.

Confirm the registrar is yours

1. Look up the domain at the registrar’s public WHOIS or RDAP record. Write down the registrar name, the registrant organization, the registrant email, and the expiration date.
2. Log in to that registrar with an email address the organization controls. A designer’s personal Gmail, a former employee, or a host that will not hand over the login means you do not own the name yet.
3. If the account is not yours, get the authorization code and move the domain to a registrar account in the organization’s name. Turn on auto-renew and put a card the organization controls on the account. Add a second human as a recovery contact.
4. Lock the domain against transfer once it is in the right account, and turn on any registrar two-factor option that does not depend on one person’s phone alone.

Confirm DNS is yours, separately from the website

1. Export every DNS record before you change anything: A, AAAA, CNAME, MX, TXT, NS, and SRV. Save the export in the same folder as the project notes.
2. See which nameservers the domain uses. Then log in to that DNS host. Registrar login and DNS login are often two different accounts. You need both.
3. Mark which records are the website and which are mail, SPF, DKIM, DMARC, and any service verification (search console, Microsoft 365, Google Workspace). The website move does not get to take the mail with it by accident.
4. If you move DNS to Cloudflare or another host, lower TTLs a day ahead, copy the records across, change nameservers, and watch mail for a day before you delete the old zone.

HTTPS and security headers

1. Open the bare domain, the www host, and one inner page. Each should land on HTTPS with a certificate that matches the name and is not close to expiry.
2. HTTP should redirect once to HTTPS. Avoid a chain of three or four redirects.
3. Set, and then actually request, these response headers: Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy, X-Frame-Options or an equivalent frame policy, and a Content-Security-Policy you have loaded the real pages against. A policy that blocks your own CSS is not finished.
4. Click through the public pages on a phone. Mixed-content warnings and missing images are part of this checklist, not a later polish pass.

Cut hosting bloat, and keep the edits tracked

1. List the monthly bill. Theme licenses, page-builder add-ons, security plugins, form plugins, backup plugins, and managed hosting for a brochure or event site often land in the $150–$300 a month range. Write each line. That list is the bloat. Do not guess the replacement cost until the pages are scoped.
2. Decide what is still earning its line: mail, a payment account, a CRM, a donation tool. Cancel the overlap after the replacement works, not before.
3. Put the new site in a repository the organization can clone. A login to a closed builder, with no export, is not ownership.
4. Ship changes through version control. A person should be able to see what changed, who changed it, and roll it back. Production is not the place a vendor edits live with no diff.
5. Keep a one-page runbook: where the domain lives, where DNS lives, where the repository lives, who can deploy, and who gets the renewal email.

If you want this done with you, start a web project. The same checks are how we begin a rebuild.

Guide 02

CRM & Registration Funnel Audit Checklist

Use this on a conference, a class, a fundraiser, or a store. The failure mode is quiet: someone picks a ticket, the next page errors, and you have no name and no email. The funnel should keep the person even when they stop, and every button that looks like a purchase should return a real page.

Capture the person on step one

1. Step one asks for name and email, and stores them, before ticket type, donation amount, workshop choice, or payment. A drop-off after step one should still leave a lead. A blank CRM row is a broken funnel.
2. Make every later field earn its place. Mailing address, job title, and dietary notes can wait until you have the email.
3. Say, next to the form, what you will do with the address. One sentence. Who sends mail, and whether a person can opt out.
4. If the event is bilingual, both languages post to the same CRM with a language field. Two inboxes that nobody reconciles will drop one of the languages.
5. Reject an obviously bad email on the form. Store the record in the CRM, not only in a notification email that someone might miss.
6. Submit a test from a phone. The form should complete without horizontal scrolling, and the confirmation should be readable without pinching.

Every pricing path has to answer

1. List every pricing card, register button, sponsor PDF, and checkout link on the page. Open each one. The response should be HTTP 200 on the page you meant, not a soft 404, a parked domain, or a login wall the buyer cannot pass.
2. Check the thank-you page and the receipt email with a real test purchase or a zero-dollar test if the tool allows it. A thank-you URL that 404s after a successful charge is how you lose the relationship you just paid to create.
3. Confirm the amount, the name of the ticket, and the currency match on the card, the checkout, and the receipt. A card that says “General” and a cart that says “VIP” is a broken link even when both URLs load.
4. Retest after any CMS or theme change. Pricing buttons are the first thing a visual edit knocks loose.

Keep checkout friction near zero

1. Let people check out as a guest unless an account is doing work for them. Account creation before payment is a second product they did not come to buy.
2. Count the fields between “I will take this” and “paid.” Cut the ones the fulfillment team does not use. Prefill anything you already captured on step one.
3. Show the full price before the card fields: ticket, tax, and fees. A surprise line on the last click is friction.
4. Offer the payment methods your buyers already have. Do not add a wallet, a points program, or a coupon box that nobody on the team can explain.
5. Make the error text specific. “Card declined” is usable. “Something went wrong” sends people backward with no idea which field failed.
6. After a real registration, confirm three things the same day: the CRM row has the name and email from step one, the payment or RSVP status is correct, and the confirmation reached an inbox you do not control (a personal address, not the website’s own admin).

Conference and membership flows are a standing part of our web work, including the bilingual admissions and registration surveys underway for TRIZCON 2026. Send the current URL if you want the audit run on your funnel.

Guide 03

Practical AI Operations Playbook for Small Teams

Use this when a team of a few people wants AI in the workweek without turning a chatbot into the person who emails customers or merges code. The pattern Societas runs, and the pattern we install, is the same: the model may research, draft, and audit. A human signs every external send and every code merge.

Where the model is allowed to work

1. Research. Let it gather sources, compare pages, and outline a question. A person checks the claims you are about to repeat in public. If you cannot find the source, the claim does not ship.
2. Drafting. First passes of a page, a letter, an agenda, or a checklist are fair game. The draft is not the send. Edit it in the tool where the real document lives, not only in the chat window.
3. Audits. Ask it to look for broken links, inconsistent prices, missing alt text, or a step that contradicts an earlier step. Then click the things it flagged. A model’s “all links passed” is a lead, not a result.
4. Daily briefings. One digest, one owner, a length a person will finish. The briefing recommends. It does not email the list.

The review gate

1. Write the gate in one sentence and put it where the work happens: no external email, social post, customer message, or code merge goes out on model output alone.
2. The person who signs has to be able to reject it. A gate that always clicks approve is a log of obedience, not a review.
3. Record who signed and when. A line in the pull request, the CRM, or a shared note is enough. You want to be able to answer “who let this leave?” a month later.
4. Code changes go through a pull request a person reads. Publishing a site, a form, or a DNS change is the same kind of act as a merge.
5. If the model was wrong, the person who signed owns the mistake. That is the reason the gate exists. It keeps responsibility on the team.

What stays out of the prompt

1. Do not paste passwords, API keys, donor files, unpublished financials, or a full customer export into a tool whose retention you have not read.
2. Keep the source of truth in the repository or the CRM. A chat transcript is not the record. If the answer matters, copy the decision into the system the team already trusts.
3. Start with one workflow that already eats a morning: the daily inbox triage, the registration exceptions, the page that has to be updated every time a price changes. Finish that one. Then pick the next.
4. Write down what this automation will not do. “Will not email attendees.” “Will not change DNS.” “Will not merge.” The negative list is part of the operating note.

The longer version of why the gate is non-negotiable is the field note on human-in-the-loop AI. To put a gate on a workflow you already have, write us.