Website Development Planning Process

1. Research and goal setting

Before anything else, get clear on what the site is for. Set goals, identify your audience, and study the competitive landscape. Plan for 1-2 weeks on this stage; longer for larger projects. Three questions to answer in writing:

• What is this site supposed to accomplish? Lead generation, ecommerce, content publishing, brand presence, member portal — different goals demand different architectures.
• Who is the primary audience? Their device mix, technical comfort, accessibility needs, and content expectations all flow downstream from this answer.
• What does success look like 90 days after launch? Specific, measurable: organic traffic, qualified leads, transactions, signups.

The research half of this stage covers the competitive and SEO landscape. Look at five direct competitors and five aspirational sites; capture screenshots and notes on patterns to emulate and patterns to avoid. Run keyword research with a tool like Ahrefs, Semrush, or free options (Google Keyword Planner, AnswerThePublic) to identify the search demand your content needs to address. If the project is a redesign, run a content audit on the existing site at this stage so you know what to keep, fix, or retire.

2. IA and sitemap planning

This is where the information architecture takes shape: which pages exist, how they nest, how users navigate between them, and which templates render which content types. Plan for 2-4 weeks, often running in parallel with late-stage research. Output: a sitemap and a set of wireframes at low fidelity.

The sitemap is the skeleton — the hierarchical map of every page on the site. Tools like DYNO Mapper, Slickplan, FlowMapp, and Octopus.do all let you build, share, and iterate sitemaps with stakeholders before any design work happens. Wireframes (Figma, Whimsical, Balsamiq) sketch the structural intent of each template — header, navigation, hero, content blocks, calls-to-action — without committing to colors, type, or imagery yet.

Don’t skip stakeholder review at this stage. A sitemap revision in week 4 is cheap; the same restructuring after development has started can cost weeks of rework.

3. Designing the layout

Now the visual design comes in: color, typography, imagery, motion, brand voice translated into a design system. Plan for 4-8 weeks for a small-to-mid-size site, longer for a custom design system from scratch. Modern design happens in Figma almost universally, with auto-layout and component libraries that hand off cleanly to development.

Three things this stage needs to deliver alongside pretty mockups:

• Accessibility-aware design. Color contrast meeting WCAG 2.2 SC 1.4.3 (4.5:1 for normal text, 3:1 for large text and UI components). Touch targets meeting WCAG 2.5.8 (24×24 CSS pixels minimum, 44×44 recommended). Focus indicators that meet WCAG 2.4.11 (Focus Not Obscured). Run designs through Stark, Able, or Adee plugins before handoff.
• Responsive intent baked in. Auto-layout in Figma plus explicit mobile, tablet, and desktop frames so the engineering team isn’t guessing what should reflow.
• A real component library. Buttons, inputs, headers, cards, navigation patterns. Reusable components shorten development time and produce a more consistent finished site.

4. Writing the content

Content writing usually happens in parallel with design — an honest sequencing because the two inform each other. Plan for 5-12 weeks depending on volume. Writing well for the web means:

• Plain language. Most successful business sites target a U.S. grade 8-9 reading level. Use Hemingway Editor or Readable to spot-check.
• Audience-tuned voice. The same product page reads differently for a developer audience versus an executive buyer.
• Strong page titles, headings, and link text. Write headings that work as a table of contents; write link text that describes the destination on its own (skip “click here”).
• Calls to action that match the page’s job. Don’t bury the action; don’t bait-and-switch with a CTA that doesn’t match the page’s promise.
• Accessible content. Alt text for every meaningful image, captions and transcripts for video, descriptive form labels — content-side accessibility is often overlooked but accounts for a substantial share of WCAG failures in practice.

AI writing tools (ChatGPT, Claude, Notion AI, Jasper, Writesonic) are now standard for first drafts and brainstorming. Edit hard — Google’s 2024-2025 Helpful Content updates rewarded substantive, edited AI-assisted content and penalized lightly-edited bulk output.

5. Building the site

Build approaches in 2026 fall into three buckets, each with different time profiles:

• No-code / low-code platforms — Webflow, Framer, Wix Studio, Squarespace, WordPress with Elementor or Bricks. Faster, cheaper, plenty capable for content sites. Build time: 3-8 weeks.
• Headless CMS plus modern frontend — Contentful, Sanity, Strapi, Prismic, or Storyblok paired with Next.js, Astro, or SvelteKit. More flexible, higher engineering investment, better for complex content models or multi-channel publishing. Build time: 8-16 weeks.
• Custom development — fully bespoke front- and back-end engineering for sites with unique requirements (custom workflows, integrations, payment, authentication, complex search). Build time: 12-30+ weeks.

Ship to a staging environment behind authentication while building. Use a Git workflow for source control even on small no-code projects (Webflow, Framer, and Wix Studio all integrate with version control). Plan for 5-12 weeks on average.

Bake non-functional requirements in from the start: SEO (semantic HTML, meta tags, structured data), analytics (GA4, Plausible, Fathom, or Mixpanel), performance (lazy-loaded images, optimized fonts, code splitting), and accessibility (semantic landmarks, keyboard navigation, ARIA only where needed).

6. Testing and launching

Plan for 2-3 weeks of dedicated testing. Three streams should run in parallel:

• Functional QA. Every link, form, navigation pattern, and interactive element on every template. Test in real browsers (Chrome, Safari, Firefox, Edge) and on real mobile devices, not just emulators.
• Accessibility QA. Automated scans with axe DevTools, WAVE, or Microsoft Accessibility Insights; manual checks for keyboard navigation, focus order, screen-reader announcements, and alt text quality. Automated tools catch about 30-40% of WCAG issues — plan for the manual layer too. DYNO Mapper’s accessibility testing can run site-wide WCAG 2.1/2.2 AA scans across all pages.
• Performance and SEO. Run Lighthouse and PageSpeed Insights against a Core Web Vitals budget: LCP < 2.5s, CLS < 0.1, INP < 200ms. Map old URLs to new with 301 redirects, generate and submit a sitemap.xml, set up Google Search Console and Bing Webmaster Tools.

For sites subject to public-sector or accessibility regulations: the U.S. DOJ’s April 2024 Title II final rule (with the April 2026 Interim Final Rule extending compliance to April 26, 2027 for jurisdictions of 50,000+ and April 26, 2028 for smaller ones) makes WCAG 2.1 AA the explicit standard for state and local government services. The European Accessibility Act entered enforcement on June 28, 2025. Build accessibility into the project from stage 1, not at QA — retrofitting is much more expensive.

Launch is a sequence: cut over DNS, verify redirects, confirm analytics is firing, monitor for the first 24-48 hours, fix anything urgent. Modern deploy platforms (Netlify, Vercel, Cloudflare Pages, AWS Amplify, GitHub Pages) make rollback trivial if something goes wrong — far less stressful than the FTP-uploads era.

7. Maintenance

The site isn’t done at launch — it’s now live and accumulating maintenance debt. Make a recurring schedule for:

• Security and dependency updates. WordPress plugins, npm packages, framework versions. Most breaches are unpatched dependencies, not novel exploits.
• Broken-link and accessibility scans. Run monthly via DYNO Mapper, Sitebulb, Screaming Frog, or platform-native scanners. Broken external links and accessibility regressions are the most common silent decay.
• Content freshness. Review evergreen pages quarterly, dated content (statistics, prices, regulations, tool lists) every 6-12 months. The same kind of refresh work this article is part of.
• Performance monitoring. Real-user monitoring (RUM) via Vercel Analytics, Cloudflare Analytics, Google Analytics 4, or Sentry. Set alerts when Core Web Vitals slip below the budget.
• Analytics review. Monthly check-in on traffic, conversion, top pages, and search-query trends. Patterns drive what content needs updating, what needs adding, and what should be retired.

Plan for ongoing maintenance budget — usually 10-20% of the original build cost annually for an actively maintained site. Sites that get zero ongoing investment decay measurably within a year.

Should I hire a professional?

The decision usually comes down to three factors:

• Time. Building a website yourself takes 3-6 months part-time even with no-code platforms. If your business needs to ship faster than that, hiring is the obvious choice.
• Skill mix. Modern site-builders have collapsed the gap between “DIY” and “professionally built” for small content sites. For ecommerce, integrations, or anything custom, the gap reopens.
• Budget. A solid small-business site from a freelancer or small agency runs $5K-25K. Mid-market builds run $25K-100K+. Custom enterprise work runs higher. A no-code DIY build can be done for under $1K plus your time.

A common middle path: pair a paid strategist or designer for stages 1-3 with a no-code build (or a freelance developer) for stages 4-6. This concentrates spending where expertise pays off most and keeps execution costs lower.

Frequently asked questions

How long does the entire planning process take?

Typical small-to-mid-size business site: 14-24 weeks from kickoff to launch. Brochure sites with template-driven design land at the lower end (8-12 weeks); content-heavy or custom sites at the higher end. Ecommerce, integrations, and bespoke functionality push timelines into 24-36+ weeks.

What’s the most-skipped stage?

IA and sitemap planning (stage 2). Teams under deadline pressure tend to dive into design or content writing without a finished sitemap, which produces late-stage rework when the structure has to change. The sitemap is the cheapest deliverable to revise; rebuild costs are exponential at every later stage.

How much should accessibility add to the budget?

Built in from stage 1: roughly 5-10% on top of normal development cost — mostly QA time. Retrofitted after launch: typically 30-50% of the original build cost as a remediation project. The math strongly favors building accessibility in from the start, especially with WCAG 2.2 and the DOJ Title II 2027/2028 deadlines on the horizon.

Do I need a CMS?

For most business sites, yes — non-developers need to update content without engineering involvement. WordPress (with Elementor or Bricks), Webflow, Wix Studio, Framer, Squarespace, and headless options like Contentful, Sanity, Strapi, Prismic, and Storyblok cover the spectrum from simple to highly custom. Static sites without a CMS work for very small projects but become bottlenecks quickly.

How often should I redesign?

A full redesign every 3-5 years is a common cadence — long enough to amortize the build cost, short enough to keep up with evolving standards (WCAG, Core Web Vitals, design conventions). In between, lean on continuous content refresh and incremental UX improvements rather than waiting for the next big-bang redesign.

The bottom line

Strong websites come from strong planning. The teams that hit their dates and budgets are the ones that invested time in research, IA, and content decisions before opening the design tool — not the ones that rushed through stages 1-3 to start “real work” in stage 5. Treat each of the seven stages as having its own deliverables and acceptance criteria, build accessibility and performance in from the start, plan ongoing maintenance into the budget, and the site that ships will be one you can defend a year later.