Documentation topic

Architecture & Engineering

How we structure Next.js sites, choose rendering boundaries, control dependencies, and keep business websites understandable as they grow.
Architecture is where most of our performance, maintainability, and ownership advantages begin. These guides explain why we separate content from layout, why browser-side JavaScript has to earn its place, when a database is justified, and how we keep the codebase legible enough to hand to another developer.

15 guides

All Architecture & Engineering documentation

How connectrader websites are structured

How we separate routes, reusable components, MDX content, metadata, and deployment concerns so a business website stays understandable as it grows.

Read
Why we use Next.js for business websites

Why Next.js fits our business websites: server rendering, static generation, predictable routing, metadata control, image tooling, and a clean path to custom application behavior.

Read
Server Components and Client Components

One of the biggest architecture decisions in a modern Next.js site is deciding what needs to run in the browser and what does not.

Read
Why we prefer small server routes over unnecessary backend systems

Why a narrow server route is often enough for validation, provider handoffs, secure cookies, and trusted state without turning a marketing site into a backend-heavy application.

Read
Static generation, server rendering, and when we use each

Not every page needs the same rendering strategy. We choose based on how often the content changes and what the visitor needs.

Read
What a page builder changes about website architecture

How visual page builders change the content model, runtime, admin surface, dependency graph, and portability of a website before the business asks for those tradeoffs.

Read
Routing and URL design

URL structure is part of the product. It affects navigation, search behavior, analytics, redirects, and how easy a site is to maintain.

Read
Why we keep Client Components small

Why browser-side React stays limited to the interactions that need state or browser APIs while the rest of the page remains server rendered.

Read
Our component design standard

How we decide what becomes a reusable component, how shared components prevent drift, and why reuse should simplify the code instead of fragmenting it.

Read
Why our website content usually lives in the repository

Why we often keep business website content in version-controlled MDX files instead of adding a CMS, database, login surface, and runtime dependency that the project does not need.

Read
Why we do not add a database to a marketing website by default

Why ordinary marketing sites usually stay simpler without local persistence, and when accounts, workflows, or durable application state justify adding a database.

Read
Why our marketing sites are server-first instead of client-first

Why we prefer server-rendered and statically generated content for business websites, then add client-side React only around the interactions that truly need browser state.

Read
Why we build route families instead of copying pages

How one tested route template can power services, locations, articles, products, case studies, and documentation without turning every new page into a new maintenance problem.

Read
Next.js vs WordPress for service-business websites

A practical comparison of Next.js and WordPress for service businesses, including editing workflow, performance, ownership, plugins, SEO control, and maintenance.

Read
How to tell if a website is actually custom-built

What buyers can look for when an agency says a website is custom-built, from source ownership and route systems to runtime behavior, integrations, and deployment.

Read

From explanation to proof

Where this connects to the work

This category is the clearest technical proof that our sites are built as maintainable software rather than assembled as isolated pages.