My Process from Discovery Call to Website Deployment

My website development process starts with the business problem and the person trying to solve it. I need to know who uses the site, which action matters, what information already exists, and what the owner can maintain after launch. The discovery call gives me inputs; written requirements create the project.

I do not promise a schedule or platform before identifying content, integrations, approvals, and ownership constraints.

Turn discovery into requirements

I write the audiences, important journeys, content sources, integrations, accessibility needs, search requirements, analytics boundaries, and operational constraints. Open questions receive owners and dates.

The client reviews this summary because a polished proposal built on a misunderstood requirement wastes more time than another discovery question.

Define scope and acceptance

Each deliverable states what it includes, what it excludes, who supplies content, and how we will verify it. A contact form, for example, includes validation, delivery behavior, error states, and a monitored recipient.

I separate launch requirements from later ideas. The backlog preserves good ideas without letting them expand the active project.

Choose architecture from the work

I select the CMS, frontend, hosting, data, and integration approach after the workflows are clear. Editing frequency, custom functionality, security ownership, budget, and maintenance skill all affect the choice.

I record tradeoffs. A managed platform may reduce operations while limiting customization; a custom stack creates more control and more ownership.

Build in reviewable increments

I deliver a working path early: one real page, one content type, or one integration in a review environment. The client can evaluate structure and behavior before the same pattern spreads across the site.

Review notes become tracked decisions. I avoid collecting conflicting feedback across email, chat, and unrecorded calls.

Prepare and run launch

The preflight covers content approval, redirects, metadata, accessibility checks, forms, analytics consent, backups, security headers, performance, and ownership. I record the release commit and rollback path.

After deployment I check important routes, forms, structured data, monitoring, and the deployed commit. Search tools and analytics may need later verification because their data does not update at launch time.

Hand off support

The owner receives account inventory, deployment notes, backup and recovery steps, content guidance, and maintenance scope. Temporary access is removed or converted into an ongoing support role.

• Requirements are approved in writing.
• Scope has acceptance checks.
• Architecture records tradeoffs.
• Review happens in increments.
• Launch and ownership are verified.

Need help putting this into practice?

Terry Hunt Dev provides website and application development services for teams that need clear technical ownership. Share the business problem and current systems through the contact page.