# Help first custom-build buyers understand the first decisions.

First custom-build content should explain unfamiliar project decisions without assuming the reader is buying a home for the first time. Show which documents support each question, which role reviews them and what remains unresolved. Give buyers a public starting path that reflects your verified process, with clear preparation for the next conversation.

## How is a first custom build different from a first home purchase?

The phrases describe different experiences. A person approaching a custom build may have owned homes before. Another may have reviewed building plans without owning a home. Neither history tells you which parts of your process need explaining. Write for the question the reader brings, rather than assigning knowledge from an ownership label.

Your content can define the working vocabulary without making the reader declare a background. Explain what you mean by a current plan set, a specification or a selection. Describe how your team uses each document. Avoid the suggestion that everyone must arrive with the same records before asking an initial question.

Keep this starting path distinct from [defining project fit](/articles/positioning/defining-your-ideal-buyer/). Fit explains the work your operation supports. Starting content helps someone understand that explanation. The two pages should use the same project terms while answering different questions.

## Which starting questions belong on the public page?

Choose questions that help the reader describe the current project. Do plans exist? Is land identified? Which aspects of the proposed house are still ideas? Who is already involved? Ask for the status of each input, including an honest unknown. An incomplete project description is useful when its gaps remain visible.

Put the document and the responsible role beside the question. Treat the following table as an editorial worksheet. Replace its suggested roles and records with the ones your company verifies. A role in a draft does not become responsible merely because the writer put it in a table.

| Reader question | Record to identify | Role to confirm | Next question to explain |
| --- | --- | --- | --- |
| I have not identified land. Where do I begin? | A project note stating that no site is identified | The role handling initial project review | Does your process support a conversation at this point? |
| I have drawings. Are these enough? | The available drawing set and its stated revision | The role coordinating plan review | What information is missing for the proposed review? |
| I have inspiration images. Are these specifications? | A preference list separated from approved selections | The role explaining design and selection scope | How will an idea become a documented project choice? |
| Who answers an unresolved project question? | The current question list and communication guide | The role assigned to that subject | What input does that person need before answering? |
| What should I prepare for a conversation? | The builder's current meeting preparation note | The role confirming the meeting purpose | Which records should I bring if they exist? |

Do not turn this table into a universal construction sequence. Your plan path may change with the project entry point. Say which condition starts a review. Keep dates, approval requirements and financial commitments out of the explanation until the appropriate project sources support them.

## How do you verify the starting path before writing it?

Open your current intake instructions and a redacted project file with the team responsible for early conversations. Compare the public explanation with the decisions recorded there. If the documents disagree, record the conflict for the process owner. Do not choose the most convenient version for the website.

1. **Identify an entry condition.** Describe the land and plan status the page needs to explain.

2. **Collect the working questions.** Ask the responsible team which questions belong to that entry condition.

3. **Match each answer to a record.** Mark missing or conflicting information as unresolved.

4. **Confirm the responsible role.** Check who reviews the input and who can approve public wording.

5. **Write conditional next steps.** Explain what changes when the required information is unavailable.

6. **Read the draft against the source.** Confirm every instruction matches the current operating process.

The [guide to writing down your build process](/guides/writing-down-your-build-process/) provides the broader document method. For this page, extract only the entry decisions. Leave the complete explanation available through a link instead of compressing every project phase into a crowded introduction.

## What would a fictional starting page contain?

Consider an unnamed fictional builder drafting a starting page. Its declared editorial scope covers initial project review and meeting preparation. The example does not establish a real builder's capabilities. The team must verify its own roles, supported plan paths and required inputs before adopting any wording.

The page begins with this proposed introduction: “Describe where the project stands today. Tell us whether land is identified, whether drawings exist and which questions remain open. Our initial conversation follows the project information available. Check the preparation note for records to bring if you already have them.”

Below that introduction, the fictional page has separate sections for no identified site, an identified site with unresolved questions, and available drawings. These are reading routes, not automatic acceptance decisions. Each section describes the information the team can discuss and identifies the role that confirms the next review.

A section titled “Before the meeting” then points to the [first custom builder meeting agenda](/articles/sales-process/first-meeting-with-a-custom-builder/). Its task is preparation. It does not promise an estimate, completed design or construction date from a preliminary conversation.

The final section lists questions that remain project-specific. The fictional builder marks plan suitability and missing site information for review. It supplies no invented answer. That makes the page usable even when the reader cannot yet complete the project description.

## How can short public answers explain uncertainty clearly?

Use the same pattern in each answer: identify the question, explain the current information and name the next review. Avoid an answer that begins with reassurance and never tells the reader what to do. The answer should work when copied into a meeting preparation note.

For a fictional FAQ about drawings, use: “Bring the drawings you have and identify their revision if known. The plan review contact will explain what can be discussed from that material. A set of drawings does not by itself establish that the project is ready for the next phase.”

For a fictional FAQ about not having land, use: “State that no site is identified. Ask which early conversations the builder supports before a site is available. Site-specific questions remain open until the necessary information and review are available.”

For a fictional FAQ about inspiration images, use: “Label images as preferences. Note which part of each image matters to your proposed home. Ask how the builder records and reviews those ideas before any feature becomes part of the agreed project scope.”

These are proposed editorial examples. Publish them only after the responsible team replaces any generic role or process wording with a verified explanation.

## What should the copyable content brief include?

Copy this brief into your working document. Keep the evidence fields internal. The published page needs the approved explanation, not private project files or staff correspondence. Use a redacted document excerpt only when you have reviewed its intended public use.

```
Page purpose: Explain the first project decisions.
Reader question: What can I prepare from my current project status?
Entry condition: [Land status and plan status.]
Known inputs: [Available records and their revision status.]
Unknown inputs: [Questions the page must leave open.]
Supported conversation: [What your team can discuss at this point.]
Required record: [The source supporting each instruction.]
Responsible role: [Who reviews the input.]
Alternative path: [What happens when the input is missing.]
Public proof: [Approved excerpt or process explanation.]
Next page: [The meeting or process resource that fits.]
Approver and review date: [Complete before publication.]
```

A useful brief includes a deliberate omission. Name the conclusion the page cannot support, such as whether a particular drawing set is sufficient. This prevents a later edit from replacing a qualified instruction with an unsupported assurance.

Use the [builder proof points guide](/articles/positioning/builder-proof-points/) to decide which working examples can support the public explanation. A blank template illustrates a record. It does not prove that a review has happened for the reader's project.

## Where should the starting page connect to the wider site?

Place it within your [positioning library](/articles/positioning/) so the vocabulary stays connected to project fit. Keep its next reading choice specific. A reader asking about the first meeting should reach preparation guidance, rather than a general page that repeats the introduction.

The [Positioning stage](/process/positioning/) explains how supported project claims connect. Keep the starting page within that scope. Do not use it to announce a new design, financing or advisory service that your operation has not verified.

A first custom build can also involve a deliberate change in how the proposed home will be used. The companion guide to [downsizing content based on daily use](/articles/positioning/downsizing-custom-home-buyer-content/) provides questions about tasks, belongings and unresolved layout choices. Link it as a relevant project question, without assigning a reader to a demographic group.

## What else should first custom-build content explain?

### Does first custom build mean first-time homebuyer?

No. First custom build describes experience with a building process, while first home purchase describes ownership history. Builder content should explain project questions without assuming either history establishes the reader's knowledge or readiness.

### Should a starting page publish a fixed build sequence?

A first custom-build starting page should describe the builder's verified process and identify conditions that change it. Use project entry points and required inputs. Do not present an illustrative reading path as a universal construction sequence.

### What should the page say when buyers have no plans?

A first custom-build page should tell readers how to state that plans do not exist and which conversation the builder supports at that point. The responsible team must verify that explanation before publication.

### Can the page answer project-specific questions?

A first custom-build page can explain who reviews a project-specific question and what information the review needs. Keep the conclusion unresolved when the necessary documents or professional review are unavailable.