How to tell if a website is actually custom-built

"Custom website" can mean several very different things.

One agency may mean a completely custom application built from source. Another may mean a custom visual design implemented inside a page builder. Another may mean a purchased theme with custom colors and copy.

Those can all be legitimate products.

The problem is that the word custom does not tell a buyer what they are actually receiving.

Ask what the client receives at handoff

One of the simplest questions is also one of the most revealing:

What do I own when the project is finished?

For a repository-based custom build, the answer should usually include the source code and a clear description of the external systems required to run it.

That may include the Git repository, deployment configuration, domain settings, environment variables, form destinations, analytics, and any application services.

If the site only exists inside an agency-owned account or proprietary builder, the buyer should understand what can and cannot move.

Our ownership and handoff documentation goes deeper into this distinction.

Ask how repeated pages are implemented

A site with twenty service, location, article, or portfolio pages should not require twenty unrelated implementations.

A custom application often has route families.

One route template can render many pages from structured content while sharing metadata rules, schema, layouts, and responsive behavior.

That is different from duplicating a page in an editor twenty times and changing the copy.

Neither method is invisible to the visitor, but the maintenance consequences are significant.

Ask what runs in the browser

A custom-coded site does not automatically mean a small browser bundle, but a technical team should be able to explain why JavaScript exists.

Menus, forms, galleries, filters, and application interactions may need client-side behavior.

Most service copy does not.

If the entire marketing site behaves like a browser application because the framework or builder requires it, that is an architectural choice worth understanding.

Our JavaScript budget explains how we think about that cost.

Ask how metadata and SEO infrastructure are generated

A serious implementation should have a coherent answer for:

• canonical URLs
• titles and descriptions
• Open Graph data
• structured data
• sitemaps
• redirects
• preview indexing
• robots behavior
• dynamic route metadata

The answer does not need to be custom code for every field.

The important question is whether the system is intentional and maintainable.

On our sites, those rules often live in shared metadata utilities and build-time checks rather than being typed independently into every page.

Ask what happens on a staging deployment

A real development workflow usually distinguishes preview work from production.

That can include branch-based deployments, environment-specific robots behavior, protected previews, build checks, and a controlled promotion path.

If every change happens directly on the live site, the workflow is telling you something about the engineering process.

See why preview and production are treated as different systems.

Ask how a feature is added

Suppose the business needs a gated resource, custom calculator, account area, API integration, or unusual form flow six months later.

A custom application stack should be able to absorb that feature without abandoning the original architecture.

This is one of the real advantages of starting from code.

The site can grow into software when the business problem requires it.

A builder can also integrate custom behavior, but the team should be able to explain where that behavior lives and how it is deployed.

Do not judge only by the framework badge

A website using React or Next.js is not automatically custom in the meaningful sense.

A team can still assemble generic templates, ship excessive dependencies, and create a codebase nobody understands.

The quality is in the implementation.

Look for coherent components, content models, route systems, source ownership, build validation, environment separation, and a technical explanation of the tradeoffs.

The portfolio should support the claim

Custom engineering should show up somewhere in the work.

That might be unusual content architecture, application behavior, performance, migrations, search infrastructure, integrations, or a clean handoff model.

A portfolio made entirely of screenshots can prove visual design.

It cannot by itself prove how the site was built.

That is one reason this documentation library exists. Our architecture hub explains the decisions behind the visible work so a buyer does not have to infer engineering quality from a homepage screenshot.