Scaffold a Broker-Facing Lead Qual Repo

Build a GitHub repo that pitches a lead-qualification system to real estate brokers.

Introduction

30 Second Summary

A real estate broker will not read your GitHub repo unless the first screen answers one question: "Why should I care?"

In this project, you will scaffold a complete GitHub repository that pitches a lead-qualification system to a 5-agent Austin brokerage. You will prompt Claude Desktop in plain English to draft every file, from the ROI worksheet a broker fills out over coffee to compliance posture docs that show you know the rules before she asks.

What You'll Build

A push-ready GitHub repo scaffold that tells the ROI story on page one, backs every claim with evidence, and handles TREC/TCPA/CAN-SPAM compliance awareness on day one.

By the end of this project, you'll have:

  • A 7-block README that tells the ROI story in 20 seconds, written at a reading level a non-technical broker can follow.
  • A one-page ROI worksheet tuned for a 5-agent Austin boutique that a broker can fill out over coffee in 3 minutes, with real CRM cost comparisons and payback math.
  • Compliance posture declarations, an ADR locking GCP as primary cloud, Terraform stubs, shell scripts, and a claim-evidence file that backs every README claim with a specific file or number.
  • A second ROI worksheet variant for a 10-agent suburban brokerage to show the math works at different scales (Secret Mission).

Are there any prerequisites?

You need basic comfort with Git and the command line. Familiarity with real estate brokerage operations is helpful but not required. Step 1 includes verification commands for all tools (Git, Terraform, gcloud CLI, Claude Desktop) with install links if anything is missing.

Set Up Repo, Folder Structure, and Verify Tools

Before you can draft a single broker-facing document, the repo needs a clean skeleton that organizes everything by purpose.

In this step you will create the repository, build out the directory tree, verify that every tool is installed, and establish a commit convention that keeps the repo history readable.

In This Step, Get Ready To:
  • Create the repo and full folder structure with placeholder files.
  • Verify that Git, Terraform, gcloud CLI, and Claude Desktop are installed and responding.
  • Set up a conventional commit convention so the repo history reads clean.
Create the Repo and Directory Tree

The folder structure separates concerns so a broker's tech advisor can scan the repo and immediately see where compliance lives, where infrastructure lives, and where the business case lives.

  • Open your terminal and create a new project directory.
mkdir lead-qualification-repo
cd lead-qualification-repo
  • Initialize a new Git repository.
git init
  • Create the full folder structure and placeholder .gitkeep files.
mkdir -p docs/adr docs/compliance docs/broker infra scripts pilot

touch docs/.gitkeep docs/adr/.gitkeep docs/compliance/.gitkeep docs/broker/.gitkeep
touch infra/.gitkeep scripts/.gitkeep pilot/.gitkeep

What are .gitkeep files?

Git does not track empty directories.

A .gitkeep file is a convention that forces Git to include the folder in version control. The file itself is empty. Once you add real files to a directory, you can delete its .gitkeep.

  • Stage all files and commit with a conventional commit message.
git add .
git commit -m "chore: initialize repo with folder structure"

What is a conventional commit?

Conventional commits follow the format type(scope): description. The chore: prefix tells anyone reading the repo history that this commit is maintenance work, not a new feature or documentation change.

Verify All Tools

Every tool you need for this project should already be installed. This substep confirms they are all responding correctly before you start drafting files.

  • Check your Git version.
git --version
  • Check your Terraform version.
terraform --version
  • Check your gcloud CLI version.
gcloud --version
  • Open Claude Desktop and confirm it responds to a test message like "Hello."

I see version numbers for everything

You are all set. Every tool is installed and responding.

Something is missing

Install whichever tool is missing:

Still having trouble installing?

Help me troubleshoot my tool installation.

Now set up the GitHub remote and push your initial commit.

  • Create a new repository on GitHub (free tier). Name it lead-qualification-repo or something similar.
  • Do not initialize the GitHub repo with a README, .gitignore, or license. You already have a local repo with a commit.
  • Add the remote and push.
git remote add origin [[YOUR_REPO_URL="https://github.com/YOUR_USERNAME/lead-qualification-repo.git"]]
git branch -M main
git push -u origin main

What should I see?

Your terminal should show a successful push to the main branch. If you visit your GitHub repo in a browser, you should see the folder structure with .gitkeep files in each directory.

Set Up Conventional Commit Discipline

Conventional commits follow a structured format that makes the repo history machine-readable.

This project uses four commit types: docs: for documentation changes, feat: for new features, chore: for maintenance, and build: for build system changes. If a broker's tech advisor inspects the repo, a clean commit history signals professionalism.

  • Open Claude Desktop and enter the following prompt.
Write me a short COMMIT_CONVENTION.md for a documentation-heavy repo. Use conventional commits format. Include types: docs, feat, chore, build. Keep it under 20 lines.
  • Review the output Claude generates. Make sure it lists all four commit types with a short description of each.
  • Copy the output and save it as COMMIT_CONVENTION.md in the repo root.

Pro tip: push back on Claude

If Claude generates more than 20 lines or adds commit types you do not need, tell it to shorten. You are the editor. Claude is the first-draft writer.

  • Stage and commit the file.
git add COMMIT_CONVENTION.md
git commit -m "docs: add commit convention guide"
  • Push the commit to GitHub.
git push

Your repo skeleton is live on GitHub with a clean folder structure and a commit convention in place. Next up, you will prompt Claude Desktop to draft the 7-block README that tells the broker the ROI story in 20 seconds.

Draft the 7-Block Broker-Facing README

Your repo has a clean folder structure and every tool is verified. Now you need the file that matters most: the README. A broker who opens your repo will spend about 20 seconds deciding whether to keep reading or close the tab. This step uses Claude Desktop to draft a README that answers the broker's real questions in those 20 seconds: what does this do, what does it cost, and do you know the rules.

In This Step, Get Ready To:
  • Prompt Claude Desktop to generate a 7-block broker-facing README in plain English.
  • Review the output for hype words and replace them with specific, measurable claims.
  • Commit the README with a conventional commit message.
Draft the README With One Claude Prompt

The README has exactly 7 blocks, each answering a question a broker would ask in a real conversation. The blocks are: a 20-second sell, a data handling statement, a cost ceiling, a compliance posture summary, a pilot-outreach status, an architecture placeholder, and a next-iteration pointer. You will give Claude Desktop one prompt that covers all seven.

  • Open Claude Desktop and start a new conversation.
  • Paste the following prompt into the chat.
Write a README.md for a lead-qualification system repo targeting a 5-agent
Austin real estate brokerage. Include exactly 7 blocks:

1. 20-second sell explaining what this system does and why the broker should care.
2. Data handling statement explaining what data the system touches and what it
   does not touch.
3. Cost ceiling statement showing the system runs at $200/month or less.
4. TREC/TCPA/CAN-SPAM posture summary with links to the full posture docs in
   docs/compliance/.
5. Pilot-outreach status showing current warm contacts as initials only.
6. Architecture placeholder saying full architecture is coming in iteration 2.
7. Next-iteration pointer listing what ships next.

Write at a 7th-grade reading level. No jargon. Define any technical term in
one short sentence before using it again. Spell out every acronym on first use.

Why 7 Blocks Instead of a Standard README?

A standard open-source README leads with installation instructions and API docs. A broker does not care about that. These 7 blocks are ordered by what a non-technical person asks first: "What is this?" then "What does it cost?" then "Is it legal?" Each block answers one question so the broker can stop reading the moment she has enough information to say yes or no.

Claude will generate the full README. Before you save it, you need to review it carefully.

  • Scan the output for hype words like "robust," "seamless," "enterprise-grade," or "cutting-edge."
  • Replace every hype word with a specific, measurable claim. For example, replace "robust lead management" with "tracks up to 20 leads per agent per month."
  • Check that the cost ceiling block says $200/month or less. This number must match the ROI worksheet you will create in Step 4.
  • Verify that the compliance summary links point to docs/compliance/trec-posture.md and docs/compliance/tcpa-canspam-posture.md. You will create these files in Step 5.
  • Confirm that every acronym is spelled out on first use. TREC should appear as "TREC (Texas Real Estate Commission)" the first time. TCPA should appear as "TCPA (Telephone Consumer Protection Act)." CAN-SPAM should appear as "CAN-SPAM (Controlling the Assault of Non-Solicited Pornography And Marketing Act)."

Pro tip: push back on Claude

If Claude's output still sounds like marketing copy after your review, reply with: "Remove all adjectives that are not backed by a number. Replace each one with a specific claim." Claude responds well to direct editing instructions.

  • Once you are satisfied with the output, save it as README.md in the repo root, replacing the default file.
Read It Out Loud and Commit

Reading out loud is the fastest way to catch sentences that are too long or too dense. If any sentence takes more than one breath, it needs to be shorter.

  • Read the entire README.md out loud from top to bottom.
  • Split any sentence that requires a pause for breath into two shorter sentences.
  • Save your changes.
  • Stage and commit with a conventional commit message.
git add README.md
git commit -m "docs: add 7-block broker-facing README"

What Does This Commit Message Mean?

The docs: prefix tells anyone reading the repo history that this commit is a documentation change. The description after the colon says exactly what changed. This follows the conventional commits format you set up in Step 1.

Claude Gave Me Fewer Than 7 Blocks?

Sometimes Claude combines blocks or skips one. Reply with: "I need exactly 7 separate sections with their own headings. You missed block [number]. Add it as its own section." If you are still having trouble, help me get Claude to produce all 7 README blocks.

Your README now tells the ROI story before a broker finishes her first sip of coffee. Next up, you will build the economics primer that shows her exactly how much she is overpaying for her current CRM.

Draft the Broker-Economics Primer

Your README tells the broker what the system does and why she should care. Now she needs to see the price gap between what she is already paying for CRM software and what this system costs. In this step, you will prompt Claude Desktop to draft a 2-page economics primer that puts real CRM prices side by side with a $200/month system so the broker sees the math before she has to ask.

In This Step, Get Ready To:
  • Prompt Claude Desktop to draft a broker-office economics primer comparing four real CRM platforms against your $200/month system.
  • Review the output for pricing accuracy using verified April 2026 data.
  • Commit the primer to your repo with a conventional commit message.
Draft the Primer With Real CRM Pricing

A broker already pays for a CRM (Customer Relationship Management) platform to track leads and manage client relationships. These platforms cost anywhere from $345 to $3,500 per month. Your system costs $200/month. The economics primer makes that gap impossible to miss.

The primer compares four popular real estate CRMs using verified April 2026 pricing. Here is what those platforms actually cost:

  • kvCORE (now branded BoldTrail) starts at ~$499/month for a single agent and ~$1,200/month for teams of 5+ agents.
  • BoomTown starts at ~$1,000/month (Launch plan) plus a $750 setup fee.
  • Follow Up Boss starts at $69/user/month or $58/user/month billed annually. That is $345/month for 5 agents on monthly billing.
  • CINC starts at ~$899/month for solo agents. True all-in costs often reach $1,800 to $3,500/month including ad spend.

You will feed these numbers to Claude Desktop so it builds the comparison document with accurate data instead of guessing.

  • Open Claude Desktop and enter the following prompt:
Write a 2-page Markdown document called broker-office-economics.md for a real
estate broker who runs a 5-agent office in Austin, TX. Compare the monthly cost
of four popular real estate CRMs against a $200/month lead-qualification system.
Use these real prices verified as of April 2026:

- kvCORE (now branded BoldTrail) starts at ~$499/month for a single agent and
  ~$1,200/month for teams of 5+ agents.
- BoomTown starts at ~$1,000/month (Launch plan) plus $750 setup fee.
- Follow Up Boss starts at $69/user/month or $58/user/month billed annually
  ($345/month for 5 agents on monthly billing).
- CINC starts at ~$899/month for solo agents, with true all-in costs often
  $1,800-$3,500/month including ad spend.

Show the broker what she is paying now versus what this system costs. Write at a
7th-grade reading level. No financial jargon. Spell out CRM as Customer
Relationship Management on first use. Keep it to 2 pages max.

What Does This Prompt Do?

This prompt tells Claude exactly what document to create, what pricing data to use, and how to write it. By including the verified numbers directly in the prompt, you prevent Claude from guessing or hallucinating prices. The "7th-grade reading level" instruction keeps the output accessible to a non-technical broker.

Claude will generate a Markdown document comparing all four CRMs against your $200/month system. Before you save it, review the output for accuracy.

  • Check that each CRM price matches the numbers you provided in the prompt. If Claude changed any number, correct it.
  • Look for hype words like "robust," "seamless," or "enterprise-grade." Replace them with specific, measurable language.
  • Confirm that CRM is spelled out as Customer Relationship Management on first use.
  • Make sure the document stays at or under 2 pages. If it runs long, cut the least essential section.
  • Save the reviewed output as docs/broker/broker-office-economics.md.

Pro tip: read it out loud

Read the primer out loud as if you are explaining it to a broker sitting across the table. If any sentence makes you stumble or take a second breath, it is too long. Shorten it. A broker will not re-read a confusing sentence. She will just stop reading.

Why Compare Against Real CRM Prices?

A broker does not evaluate your system in a vacuum. She compares it against what she already pays. If you say "$200/month" without context, she has no frame of reference. When you show her that kvCORE costs $1,200/month for the same team size, the $200 number suddenly means something.

Using verified, current prices also builds trust. If the broker checks one of your numbers and finds it accurate, she is more likely to trust the rest of the document.

Commit the Primer

With the primer reviewed and saved, commit it using a conventional commit message.

  • Stage the file:
git add docs/broker/broker-office-economics.md
  • Commit with the conventional commit format:
git commit -m "docs: add broker-office economics primer with CRM cost comparison"

Why the docs: Prefix?

The docs: prefix follows the conventional commits format you set up in Step 1. Since this file is a documentation artifact, it gets the docs: type. This keeps your commit history readable if a broker's tech advisor inspects the repo.

Your repo now has the economics primer that makes the cost conversation concrete. Next up, you will build the one-page ROI worksheet that lets the broker plug in her own numbers and see the payback math in under 3 minutes.

Draft the One-Page ROI Worksheet

Your broker-economics primer shows the cost gap between existing CRMs and your $200/month system. Now you need to make that gap personal. The ROI worksheet is the document that makes or breaks the coffee meeting. The broker circles her own numbers, sees the math, and decides whether to keep listening.

ROI means Return on Investment. It answers one question: how quickly does the money spent on this system pay for itself through extra deals closed?

In This Step, Get Ready To:
  • Prompt Claude Desktop to draft a one-page ROI worksheet tuned for a 5-agent Austin boutique brokerage.
  • Validate the payback math yourself so the README never claims faster payback than the worksheet proves.
  • Commit the worksheet with a conventional commit message.
Draft the ROI Worksheet With Claude Desktop

This worksheet is not a financial model. It is a napkin sketch a broker fills out over coffee in 3 minutes. Every number has a blank line or bracket where she writes her own reality.

  • Open Claude Desktop and enter the following prompt.
Write a one-page ROI worksheet in Markdown called roi-worksheet.md for a broker
running a 5-agent boutique in Austin, TX. Use these realistic Austin market
inputs as defaults the broker can change (all verified as of April 2026):

- Median home price $455,000 (Austin metro area median sold price per Austin
  Board of REALTORS/Unlock MLS data, April 2026)
- Average commission rate 5.7% split between buyer and seller sides so the
  brokerage side is roughly 2.85%
- Average leads per month per agent: 20
- Lead-to-client conversion rate: 2-3%
- Average deals closed per agent per year: 6-8
- System cost: $200/month

The worksheet should have blank lines or brackets where the broker circles or
writes her own numbers. Show the math so she can see how quickly $200/month
pays for itself. If one extra deal closes per year across the office because
of better lead qualification, show what that means in commission dollars.

Push back if this reads like a financial model. It should read like a napkin
sketch a broker fills out over coffee in 3 minutes.

Why these specific numbers?

The $455,000 median comes from Austin Board of REALTORS/Unlock MLS data for the Austin metro area as of April 2026. The city of Austin proper median is higher at roughly $540,000, but a 5-agent boutique likely serves the broader metro area. The 5.7% total commission rate is the current Austin average, fully negotiable per Texas law. The 2.85% brokerage side is half of that total.

  • Review the output Claude generates. If it has more than 10 lines of math, it is too complex. Ask Claude to simplify.
  • Check that every default number has a blank line or bracket next to it where the broker can write her own number.
  • Push back if Claude uses hype words like "robust," "seamless," or "game-changing." Replace with specific, measurable language.
  • Save the output as docs/broker/roi-worksheet.md.

Pro tip: read it out loud

Read the worksheet out loud as if you are sitting across from a broker at a coffee shop. If any sentence makes you pause to decode the math, it needs to be simpler. The broker should be able to follow the entire worksheet without a calculator.

Validate the Payback Claim

Before you commit this file, you need to run the math yourself. The README will reference the payback timeline from this worksheet. If the math does not hold, the claim-evidence file you build later will flag it.

  • Calculate the gross commission from one extra deal: $455,000 multiplied by 2.85% equals roughly $12,967.
  • Calculate the annual system cost: $200/month multiplied by 12 months equals $2,400/year.
  • Compare the two numbers. One extra deal across the entire 5-agent office generates roughly $12,967 in gross commission. That is more than 5 times the annual system cost.

At $2,400/year in system cost, payback from a single extra deal happens in under 2.5 months. Across 5 agents, if the system helps close even one extra deal total per year, payback is measured in weeks.

Match your README to the math

If your README currently claims "payback in under 2 weeks," check whether that matches what the worksheet actually proves. The "under 2 weeks" figure only works if you measure a single month's system cost ($200) against the commission from one extra deal ($12,967). At the annual level, payback is under 2.5 months. Adjust the README claim to match whichever framing your worksheet uses. Never claim faster payback than the worksheet proves.

  • Open your roi-worksheet.md and confirm the payback line matches your manual calculation.
  • If the worksheet shows a different payback timeline than your README claims, update the README now.
  • Commit the worksheet.
git add docs/broker/roi-worksheet.md
git commit -m "docs: add one-page ROI worksheet for 5-agent Austin boutique"

What does this commit message mean?

The docs: prefix follows the conventional commit format you set up in Step 1. It tells anyone reading the repo history that this commit adds or changes documentation, not application code or infrastructure.

Your ROI worksheet is committed and the math checks out. Next up, you will draft the compliance posture declarations and the ADR that locks in your cloud provider choice. These are the documents that show the broker you know the rules before she has to ask.

Draft Compliance Posture Docs and ADR-001

Your ROI worksheet gives the broker a reason to care about the numbers. Now you need to give her a reason to trust that you understand the rules. In this step, you will draft compliance posture declarations for TREC, TCPA, and CAN-SPAM, plus an ADR (Architectural Decision Record) that locks GCP as your primary cloud. These documents show the broker you know the regulatory landscape before she has to ask.

In This Step, Get Ready To:
  • Draft TREC advertising and TCPA/CAN-SPAM compliance posture declarations using Claude Desktop.
  • Draft ADR-001 in MADR format documenting why GCP is the primary cloud.
  • Commit all three documents with a single conventional commit.
Draft TREC and TCPA/CAN-SPAM Posture Declarations

TREC (Texas Real Estate Commission) is the state agency that regulates real estate advertising and licensing in Texas. TCPA (Telephone Consumer Protection Act) is the federal law governing calls and texts. CAN-SPAM (Controlling the Assault of Non-Solicited Pornography And Marketing Act) is the federal law governing commercial email. These posture declarations are not legal advice. They are awareness statements showing the broker that you know the rules exist.

  • Open Claude Desktop and enter the following prompt for the TREC posture declaration:
Write a one-page Markdown posture declaration called trec-posture.md for a
lead-qualification system used by a Texas real estate brokerage. This is NOT
legal advice. It is a posture statement showing awareness of TREC (Texas Real
Estate Commission) advertising rules. Cover these points:

- TREC Rules 535.154 and 535.155 (effective May 15, 2018) require the broker's
  name in all advertisements at least half the size of the largest contact info.
- Any communication designed to attract the public to use brokerage services
  counts as an advertisement under TREC rules, including emails, texts, and
  social media.
- The sponsoring broker is responsible for ensuring all agent advertising
  complies, and both agent and broker can be disciplined for violations.
- Team names must end with "team" or "group" and cannot imply independent
  brokerage.
- Include a disclaimer that this is not legal advice and the broker should
  consult a real estate attorney.

Spell out every acronym on first use. Write at a 7th-grade reading level.

Why a Posture Declaration Instead of a Compliance Checklist?

A compliance checklist implies you have verified legal compliance. A posture declaration says "we are aware of these rules and have designed the system with them in mind." That is a safer, more honest framing for a pilot-stage project. The broker's attorney handles actual compliance.

  • Review Claude's output. Verify that it mentions Rules 535.154 and 535.155 with the effective date of May 15, 2018.
  • Confirm the output includes the broker-name-size requirement (at least half the size of the largest contact info).
  • Confirm the output includes a legal disclaimer.
  • Save the file as docs/compliance/trec-posture.md.

Now prompt Claude Desktop for the TCPA/CAN-SPAM posture declaration:

  • Enter the following prompt in Claude Desktop:
Write a one-page Markdown posture declaration called tcpa-canspam-posture.md
for a lead-qualification system. Spell out every acronym on first use. Cover:

- TCPA (Telephone Consumer Protection Act of 1991) requires express written
  consent before marketing texts or automated calls.
- Texts are treated the same as calls under TCPA.
- Penalties are $500-$1,500 per violation with a 4-year statute of limitations.
- Calling hours are 8 AM to 9 PM recipient local time.
- The FCC one-to-one consent rule (effective January 27, 2025) requires consent
  naming the specific company. Blanket consent to "marketing partners" no
  longer meets the standard.
- The FCC revocation rules (effective April 11, 2025) require honoring opt-out
  requests within 10 business days via any reasonable method.
- CAN-SPAM (Controlling the Assault of Non-Solicited Pornography And Marketing
  Act of 2003) requires an unsubscribe link, physical address, accurate
  headers, and honest subject lines in commercial emails.
- CAN-SPAM does not require prior consent for email but does require easy
  opt-out.
- Include a disclaimer that this is not legal advice.

Write at a 7th-grade reading level.
  • Review Claude's output carefully. Check for these specific dates and details:
  • Save the file as docs/compliance/tcpa-canspam-posture.md.

What Is the FCC One-to-One Consent Rule?

Before January 27, 2025, a lead form could say "I consent to be contacted by Company X and its marketing partners." That blanket consent covered dozens of companies. The FCC's one-to-one consent rule changed this. Now, consent must name the specific company that will contact the consumer. Each company needs its own separate consent. This matters for real estate because many lead generation platforms used to sell one lead to multiple agents.

Draft ADR-001 in MADR Format

An ADR (Architectural Decision Record) captures one architecture decision, why you made it, and what alternatives you considered. MADR (Markdown Architectural Decision Records) is the industry-standard template format. It includes sections for Status, Date, Context, Decision Drivers, Considered Options with pros and cons, Decision, and Consequences. Writing an ADR for your cloud choice turns "we picked GCP" into a documented, defensible decision.

  • Enter the following prompt in Claude Desktop:
Write an Architectural Decision Record called 001-use-gcp-as-primary-cloud.md
in MADR (Markdown Architectural Decision Records) format.

Status: Accepted.

Context: We need a cloud provider for a lead-qualification system serving a
5-agent Austin brokerage. The system must cost under $200/month total and
support future expansion.

Decision Drivers:
- Cost ceiling of $200/month
- Free tier availability
- gcloud CLI already installed
- No vendor lock-in on core logic

Considered Options:
1. GCP (Google Cloud Platform) - offers $300 free trial credit for 90 days,
   always-free tier with 1 e2-micro VM and 5 GB Cloud Storage per month, and
   the gcloud CLI is already installed.
2. AWS (Amazon Web Services) - largest market share and broadest free tier but
   requires installing new CLI tooling.
3. Azure (Microsoft Azure) - strong enterprise presence but higher complexity
   for small projects.

Decision: GCP.

Consequences:
- Positive: zero cost during pilot phase
- Negative: smaller community compared to AWS

Write at a 7th-grade reading level. Spell out every acronym on first use.

Why GCP Instead of AWS or Azure?

GCP's always-free tier includes 1 e2-micro VM per month, 5 GB of Cloud Storage, and 2 million Cloud Run requests per month. New accounts also get $300 in free trial credit valid for 90 days. For a pilot-stage system that needs to stay under $200/month, GCP's free tier covers the entire pilot phase at zero cost.

AWS has a broader free tier overall, but the gcloud CLI is already installed on your machine. Avoiding new CLI setup keeps this step focused on documentation, not tooling.

  • Review Claude's output. Confirm it follows the MADR structure with Status, Context, Decision Drivers, Considered Options (with pros and cons for each), Decision Outcome, and Consequences sections.
  • Verify that all three cloud providers (GCP, AWS, Azure) appear in the Considered Options section.
  • Save the file as docs/adr/001-use-gcp-as-primary-cloud.md.

Pro tip: one decision per ADR

Each ADR captures exactly one decision. If you later decide on a database or a frontend framework, those become ADR-002 and ADR-003. Never reopen an accepted ADR. If a decision changes, create a new ADR that supersedes the old one.

Commit All Three Documents
  • Stage all three new files:
git add docs/compliance/trec-posture.md docs/compliance/tcpa-canspam-posture.md docs/adr/001-use-gcp-as-primary-cloud.md
  • Commit with a conventional commit message:
git commit -m "docs: add TREC posture, TCPA/CAN-SPAM posture, and ADR-001 GCP decision"

What Does This Commit Message Mean?

The docs: prefix follows the conventional commits format you set up in Step 1. It tells anyone reading the git log that this commit adds documentation. The description after the colon names all three files so the commit history stays scannable.

  • Run git log --oneline to verify your commit appears in the history.

What Should I See?

Your git log should show the new commit at the top with the message docs: add TREC posture, TCPA/CAN-SPAM posture, and ADR-001 GCP decision. You should also see your earlier commits from previous steps below it.

Your repo now has compliance posture docs that show regulatory awareness and an ADR that documents your cloud decision with alternatives considered. Next up, you will create the Terraform stubs, shell scripts, and the claim-evidence file that backs every README claim with proof.

Write Terraform Stubs, Shell Scripts, and Claim-Evidence File

Your compliance docs and ADR prove you know the rules and made deliberate infrastructure choices. Now you need the infrastructure stubs that show what the system will look like when it ships, plus the quality gate that keeps every README claim honest.

Terraform is an IaC (Infrastructure as Code) tool that lets you define cloud resources in configuration files written in HCL (HashiCorp Configuration Language). In this project, the Terraform files are stubs only. You never run terraform apply. They exist to show what the future infrastructure will look like.

In This Step, Get Ready To:
  • Create Terraform HCL stubs for future GCP infrastructure.
  • Write shell scripts for spinup, teardown, and cost-check operations.
  • Build a claim-evidence mapping file that backs every README claim with a specific file or number.
Draft Terraform Stubs and Shell Scripts

The Terraform stubs give a broker's tech advisor something concrete to inspect. The shell scripts show that spinup, teardown, and cost monitoring are planned from day one. None of these files execute anything automatically.

  • Open Claude Desktop and enter the following prompt to generate the Terraform stub:
Write a minimal Terraform main.tf file that defines a GCP (Google Cloud Platform)
project stub for a lead-qualification system. Include a google provider block with
a placeholder project ID and region us-central1. Add a commented-out
google_compute_instance resource for a future e2-micro VM. Add a commented-out
google_storage_bucket resource for future lead data storage. Add a header comment
saying these are stubs only and should never be applied without reviewing the GCP
free tier limits. Use Terraform 1.14.x required_version constraint.
  • Review the output. Confirm the required_version constraint references 1.14.x and that both resource blocks are fully commented out.
  • Save the file as infra/main.tf.
  • Enter the following prompt in Claude Desktop to generate the shell scripts:
Write three short Bash scripts for a lead-qualification system repo.
(1) spinup.sh that echoes the gcloud commands needed to create a project and
enable billing but does NOT run them automatically.
(2) teardown.sh that echoes the gcloud commands to delete resources and disable
billing.
(3) cost-check.sh that runs gcloud billing accounts list and gcloud billing
projects describe to show current spending.
Each script should have a safety header that says "This script echoes commands.
Review before running. Nothing executes automatically."
  • Review each script. Confirm that spinup.sh and teardown.sh use echo to display commands rather than executing them directly.
  • Confirm that cost-check.sh actually runs the gcloud billing commands (these are read-only queries, so they are safe to execute).
  • Save the scripts to scripts/spinup.sh, scripts/teardown.sh, and scripts/cost-check.sh.
  • Make all three scripts executable:
chmod +x scripts/*.sh

What Does This Command Do?

chmod +x adds execute permission to a file. Without this, the shell will refuse to run the scripts. The *.sh wildcard applies the permission to all three scripts at once.

Why Are the Stubs Commented Out?

Running terraform apply on uncommented resource blocks would create real cloud resources and potentially incur charges. By keeping the resources commented out, the file serves as a blueprint a tech advisor can read without any risk of accidental provisioning.

What Is Terraform's License?

Terraform uses the Business Source License (BSL) 1.1. This allows internal production use but restricts building competing commercial products. For this project, where the .tf files are stubs that never get applied, the BSL has zero impact on your work.

Draft the Claim-Evidence Mapping File

The claim-evidence file is a quality gate. Every claim the README makes maps to a specific file or number in the repo. If a claim cannot produce evidence, it gets reworded or deleted. This prevents the repo from making promises the files do not back up.

  • Enter the following prompt in Claude Desktop:
Write a claim-evidence.md file for a lead-qualification system repo. Create a
Markdown table with three columns: Claim, Evidence, Verified. Add rows for every
major claim the README makes:
(1) system costs $200/month or less, evidence points to docs/broker/roi-worksheet.md
cost line.
(2) ROI worksheet shows payback math at realistic Austin inputs, evidence points to
the payback calculation in roi-worksheet.md.
(3) TREC compliance awareness, evidence points to docs/compliance/trec-posture.md.
(4) TCPA/CAN-SPAM compliance awareness, evidence points to
docs/compliance/tcpa-canspam-posture.md.
(5) GCP selected as primary cloud with alternatives considered, evidence points to
docs/adr/001-use-gcp-as-primary-cloud.md.
(6) All 7 README blocks present, evidence is visual inspection of README.md section
headers.
Mark all rows as verified with a checkmark emoji.
  • Review the output. Confirm that every evidence path matches a file that actually exists in your repo.
  • Open your README.md and cross-check each claim row against the actual README text. If the README makes a claim that the table does not cover, add a row. If the table lists a claim the README does not make, remove it.
  • Save the file as docs/claim-evidence.md.

Pro tip: catch drifting claims early

Any time you edit the README in a future iteration, re-open claim-evidence.md and verify the new claim has a matching evidence row. The claim-evidence file only works as a quality gate if you keep it in sync.

Commit Everything
  • Stage all new files:
git add infra/main.tf scripts/spinup.sh scripts/teardown.sh scripts/cost-check.sh docs/claim-evidence.md
  • Commit with a conventional commit message:
git commit -m "feat: add Terraform stubs, shell scripts, and claim-evidence mapping"

Why Is This a feat: Commit?

The feat: prefix signals a new capability added to the repo. The Terraform stubs, shell scripts, and claim-evidence file are new features of the project scaffold, not just documentation updates. Your COMMIT_CONVENTION.md from Step 1 defines when to use each prefix.

  • Push to GitHub:
git push

Having Trouble Pushing?

If Git rejects the push, your local branch may be behind the remote. Run git pull --rebase first, then try pushing again. Help me debug my Git push error.

Your repo now has infrastructure stubs, operational scripts, and a quality gate that keeps every claim honest. Next up, you will draft the pilot contact list and send your first real pitch message to a broker.

Draft Pilot Contacts and Send One Real Pitch Message

Your repo now has the README, the economics primer, the ROI worksheet, compliance posture docs, infrastructure stubs, and a claim-evidence file backing every promise. The only thing missing is a real human on the other end of a conversation. In this step, you create a privacy-safe pilot contact list and send one real pitch message to a broker you actually know.

In This Step, Get Ready To:
  • Create a pilot contact list using initials only to protect privacy.
  • Draft and send one real pitch message to a warm broker contact.
  • Update the contact list with outreach status and commit the changes.
Create the Pilot Contact List

The pilot contact list tracks which brokers you plan to reach out to. You use initials only so the repo stays safe to push publicly. No full names, emails, or phone numbers go into version control.

  • Create a new file called pilot/warm-contacts.md.
  • Add 3-5 entries for real broker contacts you know personally.
  • Use only initials for each person. Format each entry with: initials, how you know them, last contact date, and status.

Here is an example of what the file should look like:

# Pilot Warm Contacts

Privacy note: initials only. No full names, emails, or phone numbers in this file.

| Initials | How I Know Them | Last Contact | Status |
|----------|----------------|--------------|--------|
| J.M. | Former colleague, runs 5-agent office in South Austin | March 2026 | not yet contacted |
| R.T. | Met at Austin Board of REALTORS event | January 2026 | not yet contacted |
| S.K. | Friend of a friend, manages boutique brokerage in Cedar Park | February 2026 | not yet contacted |

Why initials only?

This repo may be pushed to a public GitHub repository. Storing full names, emails, or phone numbers in version control creates a permanent record that is difficult to remove. Initials give you enough context to remember who each contact is without exposing their personal information.

  • Replace the example entries with your own real contacts.
  • Set every contact's status to not yet contacted for now.
  • Save the file.
  • Commit with a conventional commit message:
git add pilot/warm-contacts.md
git commit -m "docs: add initials-only pilot contact list"
Draft and Send One Real Pitch Message

This is the moment the repo stops being a folder of files and becomes the start of a real conversation. You will use Claude Desktop to draft a short pitch message, customize it for one specific contact, and send it through whatever channel you normally use with that person.

  • Open Claude Desktop.
  • Enter the following prompt:
Write a short pitch message I can send to a real estate broker I know personally. The message should be under 100 words. It should say I am building a lead-qualification system for small Austin brokerages, it costs under $200/month, and I would like 15 minutes of her time to show the ROI (Return on Investment) worksheet. Do not use hype words. Do not promise anything the repo cannot back up. Write it like a text message from a friend, not a sales email.

What makes this prompt effective?

The prompt sets a hard word limit (under 100 words) to keep the message short enough for a text. It explicitly bans hype words so Claude does not produce something that sounds like a sales email. It also anchors the ask to something concrete: 15 minutes and the ROI worksheet. A specific, small ask gets more replies than a vague "let's chat sometime."

  • Review the output Claude generates.
  • Check for hype words like "robust," "seamless," "revolutionary," or "enterprise-grade." If any appear, ask Claude to rewrite without them.
  • Customize the message for your specific contact. Use their first name in the actual message you send, not in the repo. Reference something specific about how you know them.

Pro tip: match the channel

Send the message through whatever channel you normally use with this person. If you usually text them, text it. If you usually email them, email it. A pitch that arrives on an unfamiliar channel feels like spam.

  • Send the message to your chosen contact.
  • Open pilot/warm-contacts.md and update that contact's status from not yet contacted to message sent.
  • Save the file.
  • Commit with a conventional commit message:
git add pilot/warm-contacts.md
git commit -m "feat: send first pilot outreach message and update contact status"

Why is this a feat commit instead of docs?

In conventional commits, feat: means a new feature or capability was added. Sending the first outreach message is a milestone for the project. It is not just a documentation change. It is the first time the repo's content reached a real person.

  • Push your changes to GitHub:
git push origin main

Having trouble pushing to GitHub?

If you see an authentication error, make sure your GitHub remote is configured correctly and your credentials are set up. Help me troubleshoot my git push.

Your repo is now complete. Every file tells a piece of the story. The README sells in 20 seconds. The economics primer shows the cost gap. The ROI worksheet lets the broker do her own math. The compliance docs prove you know the rules. The claim-evidence file backs every promise. And now one real broker has your pitch in her inbox.

Secret mission

Add a 10-Agent Suburban ROI Variant

Your ROI worksheet proves the math for a 5-agent Austin boutique. But what if the broker runs a bigger office in the suburbs where homes cost less? Build a second worksheet that shows the system pays for itself at a different scale and price point.

Before you go

Clean Up Your Resources

This project runs entirely locally using Git, Markdown files, and Claude Desktop. There are no cloud resources running and no ongoing costs. Decide whether to keep your repo as-is, pause by archiving it, or delete everything.

Resources you used:

  • Local Git repository with all project files (README, docs, infra stubs, scripts, pilot contacts).
  • GitHub remote repository.
  • Claude Desktop conversation history (prompts and drafts).
  • Terraform CLI installed locally (stubs only, never applied).
  • gcloud CLI installed locally (no GCP project created, no billing enabled).

Keep everything running

No action needed. Choose this if you are still actively building on the repo, refining your pitch, or waiting to hear back from your pilot contact.

  • Your local repo and GitHub remote stay as they are.
  • No cloud resources are running, so there is nothing to shut down or pay for.
  • The Terraform stubs in infra/main.tf were never applied, so no GCP resources exist.

Pause - I'll come back to this later

Archive the repo to keep it available without cluttering your active projects.

  • On GitHub, go to your repository's Settings page.
  • Scroll to the Danger Zone section and click Archive this repository.
  • Archiving makes the repo read-only. You can unarchive it anytime to resume work.
  • Your local files stay on your machine. No need to delete them.

Delete - I don't want to use this again

Remove all project resources and start fresh.

  • On GitHub, go to your repository's Settings page.
  • Scroll to the Danger Zone section and click Delete this repository.
  • Confirm by typing the repository name when prompted.
  • Delete the local project folder from your machine by running rm -rf your-project-folder in your terminal.
  • Terraform and gcloud CLI can stay installed on your machine. They are useful for future projects.
  • If you want to remove Terraform, delete the binary from wherever you installed it.

Mission accomplished

That's a Wrap!

Nice work! You just built a repo that does not look like a developer talking to herself. It looks like someone who understands what a broker needs to hear before she will spend 15 more minutes listening.

You've learned how to:

  • Scaffold a broker-facing repo with a 7-block README, ROI worksheet, real CRM cost comparisons, compliance posture declarations, an ADR in MADR format, Terraform stubs, and a claim-evidence file that backs every promise with a specific file or number.
  • Use Claude Desktop as a drafting tool by writing plain-English prompts that produce professional documentation, then reviewing and pushing back on hype words until every sentence earns its place.
  • Frame a technical system in broker language by leading with ROI math, showing TREC and TCPA/CAN-SPAM awareness before the broker asks, and sending a real pitch message to a warm contact.
  • Build a second ROI worksheet variant for a 10-agent suburban brokerage to prove the payback math holds at different scales and price points.

Ready to quiz yourself?