Documentation topic
Architecture & Engineering
Core guides
Start with the architecture
These guides carry the main argument for this topic. The full library below goes deeper into individual implementation decisions.
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 the guideWhy 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 the guideWhy 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 the guideWhy 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 the guide15 guides
All Architecture & Engineering documentation
How we separate routes, reusable components, MDX content, metadata, and deployment concerns so a business website stays understandable as it grows.
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.
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.
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.
Not every page needs the same rendering strategy. We choose based on how often the content changes and what the visitor needs.
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.
URL structure is part of the product. It affects navigation, search behavior, analytics, redirects, and how easy a site is to maintain.
Why browser-side React stays limited to the interactions that need state or browser APIs while the rest of the page remains server rendered.
How we decide what becomes a reusable component, how shared components prevent drift, and why reuse should simplify the code instead of fragmenting it.
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.
Why ordinary marketing sites usually stay simpler without local persistence, and when accounts, workflows, or durable application state justify adding a database.
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.
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.
A practical comparison of Next.js and WordPress for service businesses, including editing workflow, performance, ownership, plugins, SEO control, and maintenance.
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.
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.