What "custom-built" actually means

"Custom" gets used loosely enough in web development that it's worth pinning down before you pay for it. There are really three paths, and they solve different problems.

Site builders and hosted platforms

Squarespace, Wix, and similar tools get you a working site in a weekend with no engineering involved. That's the entire pitch, and for a small business that needs an online presence and nothing more, it's a reasonable one. The trade-off shows up later, when you want something the builder wasn't designed for: a specific integration, an unusual layout, or performance tuning beyond what the platform exposes.

Themes and template-based CMS sites

WordPress and its equivalents sit a level up. You get a real content management system, a large plugin ecosystem, and editors can update copy without touching code. The cost is accumulated over time rather than upfront: every plugin is another dependency to keep patched, and performance tends to degrade as more of them stack up on the same install.

Hand-coded, custom-built sites

This is a site built from scratch in a framework like Next.js or React rather than assembled from a theme. There's no plugin layer to maintain, no template constraints to work around, and the architecture can be built to support what the business actually does, not just what a generic theme anticipated. It costs more to build. It also doesn't accumulate the same kind of debt a template stack does, because there isn't a stack of third-party code sitting underneath it.

Which one actually fits

The honest answer depends on how differentiated the site needs to be and what it's going to grow into. A local service business that just needs hours, contact info, and a few photos rarely needs custom engineering. A business planning to add a client portal, a booking system, or an internal tool on the same foundation usually does, because rebuilding a template site into something that can carry real application logic tends to cost more than starting custom would have.

We've laid out a fuller side-by-side on the comparison page, including what tends to go wrong with each approach a few years in.