Project Warmth Audit

1. Define warm in terms of a user outcome

Start with one sentence: a specific person arrives from a specific source, completes a specific action, and receives a specific result. For a waitlist, the result might be a confirmed subscription and a useful next step. For a paid tool, it might be a successful checkout followed by access. For a marketplace, it might be a submitted request that appears in the correct operator queue. If the sentence contains words such as works, active, or healthy without naming an observable result, rewrite it.

The outcome statement prevents the audit from collapsing into an uptime checklist. An HTTP 200 can coexist with a broken form, invalid canonical, missing email, rejected webhook, or inaccessible control. Google SRE guidance separates symptoms from causes and encourages monitoring what users experience. Apply the same discipline here: record the outcome, the safe test, the expected evidence, and the consequence if the check fails. The project is warm only when the path and its operating response both function.

• Name the user, entry source, action, expected result, and time limit.
• Choose a safe test account or reversible test mode.
• Describe the receipt: URL, event, email, database row, provider ID, or screenshot.
• Name the owner who can act when the receipt is missing.

2. Check the website as a promise, not a brochure

Open the canonical homepage and the primary conversion page in a private window, on a phone-sized viewport, and without relying on a remembered session. Confirm the page returns the intended content rather than a login shell or generic SPA fallback. Read the title and first screen as a new visitor would. Then follow the primary CTA. A page is not warm because it looks polished in the founder's browser; it is warm when a new visitor can understand and act without hidden context.

Record technical discovery signals separately. Confirm the canonical URL agrees with redirects, internal links, and sitemap entries. Fetch robots.txt and the sitemap as their actual content types, not merely a 200 response. Search Essentials and sitemap guidance make clear that these are discovery signals, not indexing guarantees. Save the status, MIME type, canonical tag, source-check date, and any redirect chain. That receipt is more useful than a dashboard badge that cannot explain what it tested.

• Homepage and primary landing page render useful content while signed out.
• Exactly one primary CTA reaches a real next step.
• Canonical host, redirects, internal links, and sitemap URLs agree.
• Robots and sitemap bodies match their declared MIME types.
• About, contact, privacy, and terms are reachable from public navigation.

3. Audit acquisition for recency and traceability

Inventory only the channels the project intentionally operates. A dormant account is not automatically a problem if it is not part of the strategy; an advertised channel with a six-month-old message is. For each active channel, record the last useful public artifact, whether its links still work, and whether the message matches current positioning. Do not reward activity volume. One accurate, useful resource that routes cleanly to activation is warmer than twenty generic posts with no measurable next step.

Follow one tagged link from each meaningful channel. Preserve source, medium, campaign, and content identifiers through the landing page and into the first product action. The Google campaign builder explains the basic URL parameters, while your own event taxonomy defines activation. Test the path rather than assuming parameters survived a redirect. If attribution disappears at authentication, store the first-touch context before the handoff and attach it when the user signs up or starts the product workflow.

• List intentional channels and archive abandoned experiments honestly.
• Verify the newest useful artifact and its destination.
• Check message, offer, and beta status against the current product.
• Trace UTM and content context into signup and activation.
• Name the first-party activation event that determines success.

4. Test support as a closed loop

A visible contact address is only the beginning of a support path. Send a clearly labeled test message from an external account. Verify delivery to the intended inbox or ticket queue, assignment or ownership, the response template, and the ability to close the item. Avoid using a real customer issue as the test. Record the message ID and timestamp, then delete or archive according to the published retention practice.

The human operating rule matters more than the tool. Define the expected first response, the escalation route for security or billing, and the backup owner when the primary person is unavailable. If an AI drafts replies, require review for claims, account changes, refunds, sensitive data, or safety issues. A support queue can look empty because messages are being dropped; the warm evidence is a complete external-to-internal-to-response loop.

• Public contact route reaches a monitored destination.
• A safe external test creates a traceable message or ticket.
• Response target, primary owner, and backup owner are documented.
• High-consequence categories have a human approval and escalation rule.

5. Verify payments and lifecycle events end to end

Use provider test mode whenever the product supports it. Exercise the intended payment or subscription journey, including success and a representative failure. Confirm that the browser result, payment provider record, application state, receipt, and entitlement agree. Stripe's webhook guidance emphasizes retries, duplicate delivery, ordering, and signature verification; your check should therefore include idempotency and a durable event record rather than trusting a success screen alone.

Map post-purchase lifecycle paths too: cancellation, failed renewal, refund, and access removal. Do not run destructive production tests without explicit authorization and a reversal plan. The audit is allowed to mark a path unknown when safe verification is unavailable. Unknown is actionable: name the missing environment, test fixture, or provider control, assign an owner, and set a date for proof. It is safer than converting assumption into green status.

• Test-mode checkout or equivalent provider flow succeeds.
• Signed webhook processing is idempotent and recorded.
• Application entitlement matches the provider state.
• Failure, cancellation, and refund paths have owners and expected evidence.
• Production checks require a documented safe-test boundary.

6. Inspect product delivery and recovery

Choose the smallest task that represents delivered value and run it as a new or low-privilege user. Confirm input validation, useful progress, completion, and a recoverable error. If the product produces a file, message, report, or scheduled action, verify that artifact at the final destination. Avoid a test that stops at button click. The user's outcome is the delivered artifact or changed state, not the front-end event.

Then ask how the workflow is restored after a bad deploy, unavailable vendor, expired credential, or corrupted record. NIST contingency planning separates systems by impact and documents recovery priorities, alternate processing, communications, and testing. A solo founder does not need a federal binder, but does need a short recovery card: dependency, failure signal, safe mode, restoration steps, access location, owner, and last tested date.

• Representative product task reaches its promised final artifact.
• Errors are visible, actionable, and do not silently lose work.
• Critical dependencies have a failure signal and fallback decision.
• Restore or rollback procedure was tested on a stated date.
• Recovery access is not trapped in one unavailable person's device.

7. Make ownership explicit across humans and automation

For every recurring task, distinguish the accountable owner from the automation operator and the reviewer. Automation can collect a metric, draft a post, or run a health check, but it cannot absorb accountability. GitHub CODEOWNERS illustrates one way to tie paths to responsible reviewers; the broader lesson is that ownership belongs next to the asset and change process, not in one person's memory. Record who decides, who executes, who reviews evidence, and who is paged when the routine fails.

Search for ownerless seams: a scheduled job with no alert recipient, a domain in a personal account, a support alias with no backup, a dashboard nobody checks, or a provider token that only one laptop can refresh. Give each seam an escalation clock. If a task fails twice, evidence is missing, or a deadline passes, the system should produce a named decision rather than an endless retry. A warm queue contains work that someone can accept, reject, or reschedule.

• Accountable owner is named for every critical recurring task.
• Automation operator and human reviewer are separate roles where risk requires it.
• Evidence failure has an escalation threshold and destination.
• Domains, deploys, analytics, payments, support, and social accounts have backups.

8. Grade evidence quality instead of counting checks

Use an evidence ladder. Weak evidence says the page exists. Better evidence says the intended action completed today. Strong evidence includes the input, timestamp, authoritative source, output, and expected state, with sensitive values redacted. The best receipt is small enough to review and durable enough to compare later. Screenshots can help with provider interfaces, but prefer URLs, IDs, structured responses, and versioned test output when available.

Separate current proof from historical context. A successful checkout from last quarter does not prove today's deployment. A provider dashboard viewed while signed out does not prove account ownership. A search result about the brand does not prove indexing of the intended canonical page. Write the exact blocker when proof is absent. Honest red status protects the operator; vague green status shifts risk to the next incident.

• Receipt identifies check, environment, source, timestamp, and expected result.
• Sensitive data is minimized or redacted.
• Current proof is clearly separated from older evidence.
• Failed or unavailable checks preserve the exact blocker.
• A reviewer can reproduce the conclusion without private oral context.

9. Convert the audit into a prioritized maintenance queue

Do not average away a critical failure. Rank findings by user harm, business consequence, time sensitivity, reversibility, and effort. A broken checkout or inaccessible recovery credential outranks a stale social post even if both are marked no. Put legal, security, privacy, payment, and destructive-action issues behind explicit human decisions. For the remaining work, choose the smallest repair that restores the user outcome and creates better evidence next time.

Each queue item needs six fields: observed condition, consequence, owner, next action, evidence required, and review date. Add dependencies and stop conditions when automation is involved. Limit work in progress so the audit produces closure rather than a second backlog. A useful first week often contains one conversion repair, one ownership repair, one discovery repair, and one recurring check—not twenty simultaneous improvements.

• Rank consequence before convenience.
• Restore broken user outcomes before polishing lower-risk channels.
• Require an evidence definition before work begins.
• Set a review date and stop condition.
• Keep the initial repair queue deliberately small.

10. Re-audit on the rate at which evidence decays

Different evidence expires at different speeds. A checkout or webhook path may deserve a safe daily synthetic check. Support ownership may need a weekly queue review. Domain and recovery access might be reviewed quarterly and after personnel changes. Legal copy should be reviewed when practices or laws change, not on a cosmetic calendar. Match cadence to consequence, change frequency, and the cost of silent failure.

Keep historical results so you can see repeated failure classes, not to manufacture a benchmark. A project that loses UTM context after every authentication change needs a stronger integration test. A support alias that repeatedly becomes ownerless needs an account policy. The audit becomes authority when it produces transparent, longitudinal learning and corrected systems. It becomes theater when dates roll forward while checks and evidence stay the same.

• Daily: highest-consequence automated user-path checks.
• Weekly: support, acquisition freshness, failed jobs, and evidence queue.
• Monthly: full conversion, attribution, sitemap, and trust-page review.
• Quarterly or on change: access, recovery, vendor, legal, and ownership review.
• After every incident: update the check, owner, or recovery card that failed.

Put this into practice

Run the companion self-assessment now, but treat its score as a prioritization aid. The real deliverable is a small set of dated receipts and owned repairs. When the website, activation, support, payment, product, and recovery paths have current evidence—and every weak signal has an owner—the project is warm in a way that another person can verify and maintain.