What founders should expect from a Next.js company site

A Next.js marketing website should leave a founder with three things they can point at: a public site that shows the offer quickly, a repository the company owns, and a place where the words can change without a rescue project. The framework is the means. Those three outcomes are the point.

You should be able to open the homepage and read it before any extra script has finished its work. You should be able to hand the code to another engineer. You should be able to tell which pages are stable and which writing is meant to be edited. The rest is detail you can ask about. You do not need a tour of framework internals to judge whether the work was done.

A public site that arrives as a page

The useful property of Next.js, for a company site, is that a visitor can receive HTML. The headline, the supporting sentence, and the link are in the first response. The browser does not have to boot a blank application and then ask it what the company does.

That matters on a phone, which is where a founder usually checks the site, and where a stranger often arrives. web.dev describes the loading metric that matches this feeling. Largest Contentful Paint should occur within 2.5 seconds of the page starting to load if the experience is going to count as good. A hero that waits on a huge image, or a page that waits on a large script before it has any text, misses that line even when the visual design is strong.

Google's guidance on helpful content sits next to that speed target. The page has to be people-first: useful to someone who came to you directly, with a clear purpose, written so they can leave having understood the offer. A framework does not supply that purpose. It can get out of the way so the purpose is what paints.

On a Hanabi build, the marketing pages are treated as pages. Navigation, type, and the primary action are ordinary web structure, styled with the site's system, and shipped as a production front end. Motion, when it exists, is an addition. The offer does not depend on it.

A repository you can hand to someone else

The second thing you should expect is the code in an account your company controls. The repository holds the pages, the components, and the history of how the site changed. Hosting, for this stack, is often Vercel. Hosting is where the site runs. The repository is what you own if you later change hosts or hire a different engineer.

Ownership here is practical, not ceremonial. A later engineer should be able to clone the project, read where the homepage lives, change a sentence, and deploy. If the only copy of the site sits in a studio account you cannot open, you did not buy a site. You rented one.

Next.js projects are still code. They use React for the interface and, on a Hanabi site, TypeScript so the pieces fit together when someone edits them. You are not expected to learn that stack to run the company. You are expected to have it in your account, with a short note on how to run it and how to ship a change. A README that says which command starts the site, which environment variables exist, and where content is edited is part of the delivery.

Ask who is allowed to deploy. A calm setup gives the company that right, and uses a preview for each change so a broken headline is caught on a private URL before it replaces the live site.

A place for the words

The third expectation is a home for content. Some words change twice a year: the positioning line, the list of services, the description of a product. Those can live in the repository if an engineer, or the studio, is the person who will change them. Other words change often: articles, notes, a changelog, a small set of case studies. Those need an editor.

Hanabi keeps its own writing in Payload, separate from the client portal. The portal holds brand files, documents, and project updates after delivery. The writing desk is a different tool, with drafts, so an article can be reviewed before it is public. Your project may not need that split. It does need a decision. Name who edits, and put the editable words where that person can reach them.

Google's people-first questions are a good test of whether the setup is working. After a change, is it still obvious who the company is? Would a visitor who came directly still find the page useful? Is the editing path calm enough that pages do not go out hasty and half-written? A CMS that can publish in one click is only a benefit if someone is responsible for the click.

Structured fields beat a blank canvas for a company site. A homepage section can expose a headline, a paragraph, and an image. The editor changes those. The layout stays the layout. The sibling question, how to choose that editor when the team is small, is the next decision, and it is covered in Choosing a CMS when the marketing team is small.

What you can ignore

You can ignore most framework trivia in a sales conversation. You do not need a position on rendering modes, bundlers, or file-system routing to know whether the site is any good. Those choices matter to the people writing the code. They should be made in service of the three outcomes above, and explained in one sentence if you ask.

A few phrases are worth recognizing so you are not bluffed by them.

• A static page is one that can be prepared ahead of the visit. Company homepages are good candidates. The offer does not change per visitor.
• A preview is a private URL for a change that is not live yet. You should get one.
• A component is a piece of interface used more than once: a button, a project card, a section. Shared pieces are why the second page looks related to the first.
• An environment variable is a secret or a setting that stays out of the public code: a key, a site URL, a flag. You should know they exist and who can see them. You should not paste them into a chat.

If a proposal leads with those words and never mentions the offer, the repository, or the editing path, ask for those three in writing. The vocabulary can follow.

What to look for in the first week

Judge the build by what you can do, not by the badge on the proposal.

Open the staging site on a phone. The offer should be readable without waiting for a performance. The largest element, often the hero image or the headline, should not be a multi-megabyte file pretending to be craft.

Open the repository. Your company should be the owner, or the transfer should be dated. The homepage should be findable by a person who was not in the project. A stranger-to-the-repo test is fair: can someone who knows the stack locate the headline in a few minutes?

Change one safe sentence on a preview. If that requires a meeting and a developer for every comma, decide whether that is acceptable. For a homepage you touch twice a year, it may be. For a journal you want to publish from, it is the wrong shape, and the content tool should arrive with the site.

Hanabi's services include this kind of company site: design and production code together, so the page you approve is the page that ships. The expectation to hold, whoever builds it, stays the same. A fast public site. A repository you own. A deliberate place for the words.