# Buyer Brief Web App and Follow-up SOP

**Document type:** Specification and standard operating procedure  
**Owner:** full/REFIT  
**Status:** Active  
**Version:** 1.0  
**Effective date:** September 20, 2026  
**Review trigger:** Any failure involving duplicate client assets, mismatched terms, untracked URLs, public source code, unverified deployments, or accidental client communication

## 1. Objective

Create one coherent buyer journey from discovery evidence through a verified client-facing web app and controlled follow-up. The process must reduce buyer decision weight, preserve source provenance, and prevent agents from sending client correspondence.

## 2. Governing principles

1. Discovery evidence produces one buyer brief, not several overlapping artifacts.
2. The brief and proposal repeat the same diagnosis, commercial terms, and next action.
3. Every buyer-facing URL and version is recorded when it is created and when it is sent.
4. The first follow-up asks about the buyer's decision blocker.
5. The second follow-up may offer a short walkthrough.
6. After the second follow-up, stop generating explanations and wait for buyer re-engagement.
7. Every web app is stored in a private GitHub repository and deployed to Vercel unless Paul explicitly requests another production platform.
8. A new Vercel project's name and default domain use the shortest clear description of the project.
9. Agents never send, schedule, queue, post, or transmit client correspondence. They prepare copy for Paul.

## 3. Scope

This SOP applies to:

- Personalized proposal pages
- Post-call buyer briefs
- Client decision pages
- Client portals and small web apps
- Follow-up copy linked to those pages
- GitHub and Vercel publication of client-facing web applications
- Version and delivery records

It does not authorize:

- Sending email, Slack messages, direct messages, texts, calendar invitations, or other client correspondence
- Publishing confidential discovery evidence that the buyer does not need
- Changing approved commercial terms without a new decision from Paul
- Making a private repository public
- Creating a second app when a healthy existing client app can carry the new route

## 4. Required roles

**Paul**

- Approves the final buyer-facing copy when review is requested
- Sends all client correspondence manually
- Decides any change to price, payment timing, scope, or buyer promise

**Agent or operator**

- Gathers and reconciles evidence
- Builds, tests, versions, publishes, and verifies the web app when authorized
- Produces message copy for Paul
- Records URLs and source receipts
- Never transmits correspondence to a client

## 5. Source hierarchy

Use this order when sources disagree:

1. The latest message actually sent to the buyer
2. The current live proposal the buyer can open
3. Signed or approved commercial terms
4. Call recordings and transcripts
5. Discovery forms and buyer notes
6. Internal plans, summaries, and agent-generated reports

An internal plan cannot silently override what the buyer was told.

## 6. Buyer brief specification

A buyer brief must contain:

1. **Situation:** the buyer's present operating condition in plain language
2. **Observed friction:** the concrete failures or handoffs consuming time
3. **Diagnosis:** the common cause beneath the visible symptoms
4. **What stays:** useful systems, people, or practices that should be preserved
5. **Prescribed solution:** the staged operating change, not an unbounded wish list
6. **First engagement:** exact duration, output, price, payment timing, and follow-up
7. **Proof standard:** observable evidence that the first change worked
8. **Honest unknowns:** facts that require the paid discovery or working session
9. **Next action:** one primary action and no more than one secondary reference action

Exclude unnecessary private details, invented guarantees, unsupported technical architecture, and language that makes the buyer absorb the same explanation twice.

## 7. Application architecture decision

Before creating a Vercel project, inspect the buyer's existing production applications.

### Use the existing app when all are true

- It belongs to the same buyer or engagement
- Its production routes are healthy
- The new page can be isolated at a stable route
- Adding the route will not change the existing proposal's behavior
- The source can be placed under a verified private repository

### Create a new app only when one is true

- The artifact belongs to a different buyer
- The existing app has an incompatible runtime or security boundary
- The existing app is deprecated and migration is approved
- The project needs a different access model or production lifecycle
- Reusing the app would create material deployment risk

When reusing an app, add a short descriptive route such as `/next-step/`. Do not create another Vercel project for one page.

## 8. Private GitHub repository procedure

1. Inspect existing repositories with GitHub's authenticated control plane.
2. Confirm whether the production app has a dedicated source repository.
3. If it does, verify that repository is private before adding work.
4. If it does not, create a dedicated private repository with the shortest clear project name.
5. Include only reviewed source files, a README, the prompt changelog, and required runtime assets.
6. Exclude credentials, environment files, local platform metadata, temporary files, and unrelated client artifacts.
7. Run the full local verification gate.
8. Stage only intended files.
9. Inspect the staged diff and staged file list.
10. Commit with a specific release message.
11. Push to the default branch.
12. Read back repository visibility, default branch, remote commit, and URL.

**Required evidence:** private visibility, repository URL, commit SHA, and a clean or explained worktree.

## 9. Vercel project and domain procedure

### Existing project

1. Inspect the project ID, framework, build command, output directory, and current production deployment.
2. Link the verified source directory to that exact project.
3. Connect the project to the private GitHub repository when supported.
4. Deploy the reviewed commit to production.
5. Preserve all existing production routes.

### New project

1. Choose the shortest clear descriptive name.
2. Avoid personal initials, internal task labels, dates, and vague words such as `site`, `app`, or `project` when the subject already identifies the app.
3. Probe GitHub, Vercel, and the target alias before creation.
4. Create the private repository first.
5. Connect Vercel to that repository.
6. Set framework and build fields explicitly.
7. Deploy the reviewed commit.

Example naming logic:

- Good: `barry-client-brief`
- Worse: `barry-lenson-client-follow-up-landing-page-final`
- Good: `eleanor-filing-cabinet`
- Worse: `client-app-v2-production`

## 10. Release verification gate

A deployment is complete only after all checks pass:

- GitHub repository is private
- Remote branch contains the intended commit
- Vercel reports the production deployment as Ready
- Stable alias resolves to the intended project
- Exact new route returns HTTP 200
- Existing proposal and recap routes still return HTTP 200
- Real-browser test renders route-specific identity text
- Browser reports no page errors or failed required assets
- Mobile widths show no horizontal overflow
- Public page contains no sensitive discovery details
- Static page bytes or build identity match the reviewed source
- Every external call-to-action link reaches the intended destination

A Vercel CLI success receipt does not close the release.

## 11. URL and version record

For every buyer-facing route, record:

- Buyer
- Artifact name
- Canonical URL
- Source repository
- Source commit
- Vercel project
- Deployment ID
- Production verification date
- Status: draft, approved, live, sent, superseded, or archived
- Date sent and channel, entered only after Paul confirms delivery
- Superseded URL, when applicable

Never mark an artifact sent because it is live.

## 12. Follow-up sequence

### Delivery message

The delivery message contains one primary link. It does not repeat the entire brief or attach another deck.

### First follow-up

Ask whether a specific concern is preventing a decision. Do not send a generic “checking in” message and do not create another explainer.

### Second follow-up

Offer a short walkthrough with one scheduling link. Keep the message brief.

### Stop condition

After the second follow-up, record the opportunity as awaiting buyer response. Do not create or send more explanations until the buyer replies or Paul makes a new commercial decision.

## 13. Correspondence safety protocol

This boundary is absolute.

Agents must never:

- Send email
- Click a Send button
- Schedule email
- Queue an automated message
- Post in a client Slack channel
- Send a direct message or text
- Create a calendar invitation addressed to the client
- Trigger an n8n, CRM, or automation path that communicates with the client

Default drafting method:

1. Write the message in a local Markdown file.
2. Put the verified live URL directly in the copy.
3. Label the artifact `Draft only. Not sent.`
4. Return the exact text to Paul.
5. Do not open a compose window or client communication surface.
6. Record delivery only after Paul confirms he sent it.

If a tool combines draft creation and send capability, do not invoke it unless Paul explicitly requests draft placement and the tool can prove that sending is disabled. Local Markdown remains the safer default.

## 14. Quality gate for message copy

The message must:

- Use one link
- Contain no attachment
- State why the page is worth opening
- Ask for one action
- Avoid repeating the page
- Preserve the current commercial terms
- Sound like Paul rather than a campaign sequence
- Be short enough to read without scrolling on a phone

## 15. Completion report

Report:

1. Live URL
2. Private GitHub URL
3. Commit SHA
4. Vercel project and deployment ID
5. Routes verified
6. Local canonical artifacts
7. Exact message copy for Paul
8. Explicit statement that nothing was sent to the client
9. Any remaining owner action

## 16. Failure handling

- **Existing app source is missing:** recover or reconstruct it before deployment, then create a private repository.
- **Existing app has unrelated dirty work:** isolate the release in a clean directory or worktree.
- **Vercel project is manually deployed:** reconcile source into GitHub before claiming Git-backed provenance.
- **Live route differs from source:** stop, inspect build output and aliases, repair, and reverify.
- **Commercial terms conflict:** latest buyer-facing promise wins until Paul decides otherwise.
- **A message was accidentally sent:** stop all automation, preserve provider evidence, notify Paul immediately, and do not send a corrective message without instruction.

## 17. Acceptance criteria

The SOP has been followed when:

- One buyer brief exists as the active explanation
- Proposal and brief agree
- Source is in a private GitHub repository
- The app is live on Vercel at a short descriptive domain or an approved existing domain
- Production and existing routes are verified
- The URL and version receipt are recorded
- Paul has ready-to-send copy
- No agent transmitted correspondence