Development, builder, and community pages

Solum public detail pages help buyers understand a new-construction option in context:

• What is being offered?
• Who is building it?
• Where is it located?
• What data is available now?
• What should be confirmed before making a purchase decision?

These pages are public unless a specific action, such as document download, requires sign-in.

Page types at a glance

Use the most specific page available. If a buyer wants follow-up about one development, open the development page before submitting an inquiry.

Before relying on a page

Check:

1. The page name matches the builder, community, or development the buyer is asking about.
2. The section you need exists on the page.
3. Any document being used is the correct document for that development.
4. The pricing and availability details are confirmed with the builder before decisions are made.

Development pages

A development page is the main public page for a specific builder offering. It can include:

• Image gallery.
• Development name.
• Builder and community links.
• Construction status badge.
• Location.
• Share button.
• Price or price range.
• Home type.
• Bedroom, bathroom, and square footage ranges.
• Estimated completion.
• Floorplans.
• Documents.
• External builder website or project details link.
• Builder profile card.
• Inquiry call to action.

Sections appear only when the underlying data exists. For example, a development with no documents will not show a documents section.

Development header

The header shows the development name and links to the builder-in-community page. The status badge can show values such as:

If a status looks wrong, report it with Feedback and include the development URL.

Header links

Header and breadcrumb-style links are useful for moving between levels of context:

• Development to builder-in-community.
• Development to builder.
• Development to community.
• Builder-in-community to development cards.

If a link is missing, the related builder, community, or development relationship may not be available in the published catalog data.

Pricing and ranges

Development pages may show:

• Starting price.
• Price range.
• "Pricing coming soon" or a fallback state when price data is unavailable.
• Floorplan-level price when a floorplan has its own price.

Treat price as a comparison signal, not a guarantee. Builders may update base prices, lot premiums, incentives, deposits, upgrade packages, included features, and availability.

Confirm current price, availability, incentives, deposit requirements, included specifications, and completion timing directly with the builder or assigned follow-up contact.

Floorplans

Floorplans appear when structured floorplan data is attached to the development. A floorplan card can include:

• Floorplan name.
• Hero image.
• Price.
• Bedrooms.
• Bathrooms.
• Square footage.
• Description.

If the floorplan section is missing, Solum may not have reliable structured floorplan data for that development yet. Missing floorplans do not necessarily mean the builder has no plans available.

Documents

Development documents can include PDFs such as brochures, plan packages, specification sheets, or other project materials.

Documents are for review and comparison. The builder remains the source of truth for final specifications, terms, incentives, pricing, and availability.

If a document is stale or missing, use Feedback with the development URL and the document name or expected document type.

For more detail, see Documents, sharing, and data accuracy.

External links

A development page may include:

• Builder website when the development or builder has a website URL.
• Project details when a project details or shared document URL is available.

External links open outside Solum. Solum cannot guarantee the availability or accuracy of third-party pages.

Inquiry call to action

Development pages include the buyer inquiry section when the development can receive inquiries. Select Take the next step to open the inquiry form.

The inquiry form is tied to the specific development page where it is opened. If you are comparing multiple developments, submit from the page that best matches the option you want to discuss.

Builder pages

Builder pages collect public builder context. A builder page can include:

• Builder logo.
• Builder name.
• Development count.
• Builder website link.
• Share button.
• Builder-community cards grouped by where the builder operates.
• Development cards when grouping data is unavailable.

If a builder has no public developments, the page shows an empty state.

Community pages

Community pages explain the place where developments are located. A community page can include:

• Cover image.
• Community name.
• Tagline.
• Location.
• Home type badges.
• Description.
• Share button.
• Builder clusters.
• Development cards.

If a community has no linked public developments, the page shows an empty state.

Builder-in-community pages

A builder-in-community page groups one builder's offerings inside one community. It can include:

• Builder and community names.
• Community cover image.
• Location.
• Home type badges.
• Share button.
• Price range.
• Construction status badges.
• Bedroom, bathroom, and square footage ranges.
• Earliest estimated completion.
• Development cards.
• Builder website link.

Use this page when you know the builder and community but want to compare that builder's available developments in one place.

Sharing pages

Use the share button on development, builder, community, or builder-in-community pages to send the page to someone else.

If the browser supports native sharing, Solum opens the native share sheet. If native sharing is unavailable, use the browser URL.

Why a section may be missing

Reporting incorrect details

Use Feedback when a public page has incorrect or stale data. Include:

• Page URL.
• Builder, community, or development name.
• The detail that looks wrong.
• The expected value, if known.
• A source link or note if you have one.

For price-sensitive or contract-sensitive decisions, confirm directly with the builder before relying on any public page.

Support notes

When troubleshooting a public page, collect:

• Page URL.
• Page type.
• Builder, community, and development names.
• Missing or incorrect section.
• Whether the user is signed in.
• Whether the issue concerns display, document download, external link, share behavior, or inquiry submission.