Corporate Website Development from Scratch: Stages, Deliverables and Acceptance

1. Discovery: agree the purpose and boundaries

Define the audience, service or product groups, principal customer actions and operating constraints. Review the current website if one exists: valuable pages, known form problems, available analytics and content worth retaining. Decide what must be ready for the first launch and what can follow later.

Deliverable: an approved brief with scope, assumptions, dependencies and exclusions. Owner: the client's decision-maker and the project lead. The team should be able to explain what counts as an extra requirement before development begins.

A goal such as “improve enquiries” needs a practical definition. Does the business need quotation requests for one service, applications from partners or contact from existing customers? Different actions require different pages, fields and routing.

2. Plan the structure and prepare the content

Create a page map and a content model: homepage, service templates, product categories, case studies, team information, articles and contact pages where needed. Map each page type to a buyer question instead of adding pages solely to make the site seem large.

Prepare content with the people who understand the service. Collect accurate descriptions, approved photos, specifications and evidence. Decide who writes and approves each language version. If content preparation runs late, visual design and launch can also be delayed.

• Identify required fields for each page type, including titles and descriptions.
• Agree which fields editors can change and which relationships require validation.
• Assign responsibility for factual claims, image rights and commercial terms.
• For a replacement site, record current URLs and the planned destination of each important page.

Deliverable: page map, content responsibilities and sample material for the main templates. A multilingual manufacturer such as the Insortex project illustrates why information architecture needs to be settled before individual screens.

3. Prototype and design the actual customer journeys

Use a prototype to check navigation, information order and the route to an enquiry. Test it with realistic content, especially long service names, technical data and mobile forms. An empty layout can hide problems that appear only when real text and images are added.

Design includes states, not just ideal screens: invalid input, confirmation, loading, unavailable data, empty categories and expanded navigation. Define keyboard focus and readable contrast as part of usable interfaces. Agree mobile behaviour before treating the desktop view as final.

Deliverable: approved layouts and interaction states for the agreed templates. The separate website design guide explains the design stage in depth; here the project manager needs a clear approval boundary between structure, design and implementation.

4. Build the site, editing tools and integrations

Make routine editing a testable requirement

Develop page templates and CMS fields around the content model. Ask a non-developer to add a service, change a contact and publish a language version in a test environment. Permissions should distinguish content editing from access to settings or customer records where appropriate.

Specify what happens after a form is submitted

Write down the data fields, destination, duplicate rule, owner assignment and failure handling. If a CRM is unavailable, the request must remain recoverable. Payment and order flows need their own acceptance cases; a successful browser message is not evidence that the underlying record was created correctly.

Keep credentials on the server, validate input and restrict uploaded content. Review dependencies, access rights and backup procedures as part of implementation rather than leaving them as undefined work after launch.

Deliverable: a working staging site with the agreed editing and operational workflows.

5. Prepare technical SEO and measurement

• Give important pages distinct titles, descriptions and a clear heading structure matching the content.
• Check canonical URLs, indexability and HTTP responses; staging restrictions should not accidentally remain on production.
• For language versions, verify reciprocal language links and correct canonical destinations.
• Include intended canonical pages in the sitemap and keep internal links aligned with them.
• Where replacing URLs, implement and test the agreed redirect map rather than redirecting everything to the homepage.
• Use structured data that describes visible, accurate content rather than invented ratings or unsupported claims.
• Measure successfully accepted enquiries separately from button clicks, and test attribution with the relevant privacy and consent arrangements.

Technical readiness helps search engines understand and access the site. It does not guarantee indexation or top rankings. Ongoing editorial work, relevance and competition remain separate considerations.

6. Test against an acceptance matrix

Agree the supported devices and browsers and any performance targets in advance. Use realistic pages and data; a fast empty homepage does not demonstrate the behaviour of a large catalogue.

7. Handover, launch and controlled expansion

Before launch, confirm domain and hosting ownership, administrator access, content exports, the repository or other agreed delivery assets, and maintenance responsibilities. Document who responds to failures and which corrections fall within the warranty or support arrangement.

After release, check important URLs, real form delivery and operational integrations again. Keep a rollback plan for a failed deployment. Do not remove the previous site's recoverable copy merely because the first smoke test passed.

For a multi-service business, the Autobuscenter case shows how service pages, completed work and editorial content can form a connected structure. Future growth should follow additional buyer needs, not a requirement to publish pages of a particular length.

Request a quotation with the agreed page types, features and responsibilities. Our corporate website development page is the commercial next step; the website budget guide covers cost components separately.