Custom Web Development: Built Right, From the First Line of Code

The right CMS depends on four things: how content is authored day to day (structured or open-ended, single-team or multi-team), what integrations the site needs (CRM, marketing automation, ecommerce, analytics, third-party APIs), how the site will scale (content volume, multi-region, multi-language, personalization), and what the internal team’s technical capacity is (self-managed vs. dependent on the agency). Watson Creative works fluently in WordPress, Webflow, React (headless setups), and Drupal, and recommends the platform against the actual work rather than defaulting to a preferred stack. A WordPress site with the right theme and plugin discipline can outperform a badly-configured enterprise CMS; a marketing-team-authored Webflow site can outperform a WordPress site the marketing team never quite learned. The choice is scoped in the UX & Digital Strategy engagement upstream and validated at the build stage.

Custom development (React, headless setups, custom back-end code) fits when the site needs behavior that platforms cannot deliver cleanly — complex integrations across systems, product configurators, membership platforms with role-specific experiences, or interfaces that behave more like applications than marketing sites. Platform builds (WordPress with well-scoped theming, Webflow with structured collections) fit when the site is content-driven, when the internal team wants to author and edit without developer support, and when the integrations are within the platform’s plugin or native capabilities. Most marketing sites fit platforms; most product sites and portals need custom. The failure mode is picking custom when the team cannot maintain it, or picking a platform when the site needs behavior the platform cannot handle. Watson Creative scopes this decision honestly against what the client can maintain, not what is easier to sell.

Design intent survives when four things hold. First, the design system is delivered as more than screens — component behavior, states, responsive rules, accessibility requirements, and motion are documented so developers implement the system rather than approximate it. Second, design and development overlap during build — designers stay engaged reviewing implementations rather than handing off and moving on. Third, the design system exists in code (React components, design tokens, Figma-linked variables) rather than only in visual specs, so the front-end matches the design system by construction. Fourth, the QA process compares the built site against the design system rather than against static screens. Watson Creative operates this way when design and development are one engagement, and provides the specifications and QA process when they are handed off between vendors.

Accessibility compliance is enforced in the code rather than audited at the end. That means semantic HTML that reads correctly with screen readers, keyboard navigation as a first-class interaction, contrast tokens defined in the design system rather than picked per page, focus states designed and implemented, motion honoring prefers-reduced-motion, form patterns tested with assistive technology, and automated + manual accessibility testing embedded in the QA process. Watson Creative builds to WCAG 2.1 AA as the common baseline, with higher standards where the sector requires (WCAG 2.1 AAA for some healthcare, federal, and higher-education contexts). Compliance is verified before launch and the code is documented so future additions inherit the accessibility patterns rather than reintroducing regressions.

HIPAA-compliant analytics require configuration that keeps protected health information out of analytics platforms in the first place — no PHI in URL parameters, no user identifiers passed to third-party analytics, and where health data is captured, the storage and reporting environments have to be HIPAA-eligible. Watson Creative builds HIPAA-compliant analytics dashboards for healthcare clients with this constraint respected by construction — the tracking layer, the CMS configuration, and the data pipeline are designed to be HIPAA-safe rather than retrofitted. Broader privacy compliance (CCPA, GDPR, state-level laws) is handled similarly: cookie consent, opt-out mechanics, data retention rules, and data-subject-access-request handling built into the platform rather than added as a plugin at the end. Regulated builds cost more; the cost is much lower than the exposure of a non-compliant one.

Site migration is the process of moving content, users, redirects, integrations and analytics from an old site to a new one. Four things break most often. Content mapping — pages that existed on the old site do not have obvious homes on the new IA, and either get orphaned or redirected incorrectly. Redirects — patterns of URLs that need to redirect are missed, and search rankings collapse. Integrations — CRM connections, marketing automation, third-party scripts do not always fire in the new environment. Analytics — events and conversions get lost in the migration, and the team loses the ability to measure the new site’s performance against the old. Watson Creative handles migration with a documented content and redirect plan, integration parity checks, and analytics continuity built into launch QA. Migrations without this discipline usually recover their SEO position over six to twelve months — with this discipline, most keep their position through launch.

Post-launch, Watson Creative provides hosting through Pantheon (or equivalent managed platforms depending on stack) with maintenance packages that cover security updates, plugin/dependency updates, performance monitoring, backup and disaster recovery, and periodic content or template updates. Standard maintenance starts at $175/month; the scope scales with site complexity and update volume. Beyond baseline maintenance, clients can retain Watson for ongoing feature work, page additions, and periodic redesigns of specific sections without triggering a full new engagement. The alternative — no maintenance retainer — is common and usually costs more over time as unattended sites accumulate vulnerabilities, out-of-date plugins, performance regressions, and eventually require full rebuilds sooner than they would otherwise.

Secure API integration in a web build requires four things: authentication properly implemented (OAuth, API keys treated as secrets, token rotation), transport-layer security (TLS, no plaintext credentials), input validation and rate limiting to prevent abuse, and third-party risk assessment for external services being integrated. Watson Creative implements API integrations as part of custom builds and as standalone engagements through the API Integration & Systems service. For simple integrations inside a build (marketing automation, CRM, analytics), the work is included in the development engagement; for deeper cross-system integration work (multi-CRM sync, custom middleware, third-party data platforms), the API Integration & Systems engagement is the right home. The line is where the integration stops being ‘site connects to service’ and starts being ‘systems architecture.’

An RFP committee should ask five categories of question. Technical: what stacks the agency works in, how they choose between platforms, how they handle accessibility, security and compliance. Process: how design and development are integrated, how QA is run, how migrations are managed, how post-launch handoff works. Team: who the actual team will be, their tenure and specialization, and how the team’s knowledge is documented so the client is not locked in. References: two or three named projects at comparable scale, with the client’s actual metric outcomes. Ownership: what code, documentation and design assets the client will own outright at project end. Watson Creative structures RFP responses around these five categories with named team members, sample documentation, and clear ownership terms so committees can evaluate against a real comparison set rather than marketing copy. Agencies that resist any of the five deserve additional scrutiny.

The site does not become a black box when three things are delivered alongside the build. First, technical documentation covering the stack, deployment process, third-party dependencies, and any custom code — sufficient for a future developer (internal or external) to understand the site without archaeology. Second, editorial documentation covering how content is authored, where different content types live in the CMS, and what the workflow rules are — sufficient for the internal marketing team to run the site day to day. Third, live training sessions with the actual users of both documents. Watson Creative delivers this alongside every build and structures the training so the client can operate the site independently after handoff. Sites delivered without documentation and training almost always default back to the original agency for changes that the internal team could and should be making — which is usually not what the client actually wants.