A founder asked me this week what to build toward before his marina operations platform had a live website. That question is more useful than it sounds. Most companies fix AI visibility after the site is built and indexed, once the cost of every change has multiplied. The founder who asks before building anything is the one who never has to retrofit. This guide is the full answer: what to decide, what to build, and what to publish in the weeks before a homepage exists, so that the day it goes live it inherits authority instead of starting from zero.

Why pre-launch is the cheapest time to earn AI visibility

Every AI-visibility fix has two prices: the price to decide it once, and the price to correct it across a live business later. Before launch, the two are the same number. After launch, they separate fast.

Consider the arithmetic. Defining your company name once costs a short conversation. Correcting it after it appears on a website, five directories, a LinkedIn page, and three press mentions costs a coordinated cleanup across every one of them, plus the time an AI system spends unlearning the old versions. Schema built into a page template is one decision. Schema added to forty live pages is forty audits. Specific homepage copy written from the first draft is free. Rewriting vague copy after it has been indexed, shared, and cited is a project with a timeline.

The founder who plans this window treats it as the one moment when the entire visibility foundation is still a set of choices rather than a set of repairs.

How AI systems decide who to recommend

Before any tactic makes sense, the mechanism has to be clear. When a buyer asks an AI assistant “which companies handle connected marina operations,” the system is doing three things at once, and each one can be influenced before a website exists.

A company that satisfies all four gets named. A company that satisfies none gets skipped, regardless of how good the product is. The rest of this guide is how to satisfy each one before launch.

Fix your entity before you fix your website

Entity consistency means your company name, location, and service description read identically everywhere they appear. Not similar. Identical.

This is the cheapest fix available and the most commonly skipped. A company that registers on five directories, a LinkedIn page, and a future website with five slightly different versions of its own name gives AI crawlers five uncertain half-matches instead of one confirmed source. The system cannot tell whether it is looking at one company or several, so it hedges, and hedging means leaving you out of the answer.

Do this before the first listing goes live. Write a one-page entity sheet and treat it as the single source of truth: the exact company name with its exact capitalisation and spacing, the legal entity name if it differs, the primary location, a one-sentence description in fixed wording, and the founder’s name and title. Every profile, listing, and page copies from that sheet, character for character. Decide it now, while there are still only one or two places it appears. Every week you wait, there are more places to correct.

Build schema in, don’t bolt it on

Schema.org markup tells a crawler what kind of thing it is looking at: an organisation, a service, a review, a location. AI systems and search engines both read it to build a structured picture of a business before they read a single sentence of marketing copy.

A development team building a site from scratch can add Organization and Service schema at close to zero cost, it is a template decision made once. A team retrofitting schema into a live site months later is auditing every page, one at a time. The difference is the difference between a line in a spec and a project on a roadmap.

For a pre-launch company, three schema types carry most of the weight: Organization for the company itself, Service for each thing it sells, and Person for the founder. Even before the site is built, the content of that markup can be written, because it is the same entity information from your entity sheet, expressed in a format machines read first.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company Name",
  "description": "Connected marina operations platform for berth tracking, vessel check-in, and maintenance scheduling.",
  "areaServed": "Europe",
  "knowsAbout": ["berth management", "vessel check-in", "marina maintenance scheduling"],
  "founder": { "@type": "Person", "name": "Founder Name" }
}

Specificity is the whole mechanism

AI search rewards matched language over confident language. A buyer searching for a marina management platform types something specific: berth tracking, maintenance scheduling, vessel check-in. A homepage that answers in the buyer’s own words gets cited. A homepage that answers in marketing language gets passed over, because the words never line up with the question.

The specific version does three things the generic version cannot. It names the capabilities a buyer actually searches for. It gives a size range, so the system can match you to the right question. And it reads as a fact rather than a claim, which is the register AI systems weigh most heavily. This applies before a company has customers. Write the specific version from the first draft. It is the same length as the vague version, only less familiar, because most marketing copy defaults to the vague one out of habit.

The same rule governs the homepage, the LinkedIn headline, the directory description, and the schema. Say the concrete thing, in the buyer’s words, everywhere.

Third-party proof outweighs self-description

AI systems treat a company’s own claims about itself as unverified until something outside that company confirms them. A case study on a partner’s site, a mention in a trade publication, a named pilot customer. These are the citations that move a company from “claims to do X” to “confirmed to do X” in an AI system’s model of the world.

None of these require a finished product. They require a plan for the moment each one becomes possible, and a founder who starts building toward them during the pre-launch window rather than after.

One named source outweighs a page of self-description. Two independent sources that describe you the same way turn a maybe into a recommendation.

The founder’s personal brand is the fastest-moving asset

A new company website has no history, no backlinks, and no crawl authority. It takes months to earn any of the three, no matter how well it is built. A founder’s personal LinkedIn profile, especially one that already exists and has some activity history, can start appearing in AI answers to relevant questions well before the company site catches up. This is the asset with the least distance to travel, so it is where the pre-launch effort pays back first.

The mechanism is identical to the website: entity consistency, specificity, and consistent publishing. Applied to a person, it becomes a short playbook.

A founder who posts specifically about connected marina operations, in precise language, several times over the weeks before launch, is building the exact signal a company website spends months trying to earn. When the site does go live, it launches into an AI landscape that already recognises the founder and the company as one confident, corroborated entity.

A 90-day pre-launch sequence

The work has an order. Doing it in sequence means each step feeds the next, and nothing needs to be redone.

Common mistakes that waste the pre-launch window

Where to Start

There is no audit to run on a site that does not exist yet. There is a decision to make now: pick the entity name, plan the schema, write the specific version of the homepage copy before the vague one becomes the default, and start posting with precision on the founder’s own profile.

Once there is anything live, even a single landing page, run it through the Maritime AI Visibility Audit to see exactly where it stands and what to fix next.