Development Phase

Implementation of the approved, content-populated design in Webflow with a structured review round.

​

General Principle

All feedback during the development phase is captured exclusively via HuddleKit. Feedback submitted via email, chat, or other channels cannot be considered. This is the only way to ensure a clear reference to the exact page, location, screen size, and browser. Deviations from the approved Figma design and technical bugs are fixed at no charge. Change requests beyond that are billed at the agreed hourly rate or quoted separately.

​

Development Process

We build the site within our internal Webflow workspace. This ensures technical integrity and prevents accidental edits during the build. We implement the exact content provided in Figma, delivering a fully populated site that is ready for launch.

​

Review Round

Once development is complete, the client receives a staging link and, for transparency, read-only access to the Webflow backend. The basis for the review is exclusively the approved and populated Figma file. The client submits all collected feedback in HuddleKit and actively signals when the review is complete. At that point, we pause the comment function and sort all feedback into two categories: bugs and change requests. We communicate clearly which items will be implemented within the project price and which fall outside the agreed scope, each with a brief explanation. We address all identified bugs first to reach full design and content parity. Once this is verified and the client provides final sign-off, the original project scope is complete.

​

Post-Approval: Change Requests

Change requests identified during the review are addressed after the original scope is signed off. They can be implemented before launch or after the site goes live, depending on the client’s preference. Each change request is quoted separately and billed at the agreed hourly rate. This separation prevents open-ended feedback loops and ensures the project is delivered and settled on schedule, while still allowing for late-stage enhancements.

​

Pre-Launch Content Support

Because content is delivered and audited in Figma before the build, the need for reactive content support during or after development is significantly reduced. Where it does arise, it is typically related to secondary language content in multilingual projects or questions that come up after the team onboarding when the client begins managing content independently. We are available for reactive support in these cases. This is billed at the agreed hourly rate and is not included in the project price. Scope and cost depend on the client and cannot be estimated as a flat fee.

​

Definition: Bug vs. Content Error vs. Change Request

​

Bug

A technical issue where the website does not match the approved Figma design. Examples include a CMS field that cannot be edited, a button that is not clickable, or an animation that does not behave as designed. Bugs are fixed at no charge.

​

Content Error

An issue caused by content that was not correctly prepared or entered. Common examples include formatting artifacts from copy-pasting out of Word or other external tools, text that breaks the layout due to incorrect length, inconsistent image sizes, or unsupported file formats. Content errors are not part of our development scope and are not covered under bug fixes, regardless of how they appear visually.

​

Change Request

Any deviation from the content or layout finalized in Figma prior to development. This includes structural changes, new features, updated copy, or image swaps that were not part of the locked Figma file. Change requests are processed as a separate work package after the main project scope is approved and billed at the agreed hourly rate. These distinctions are communicated to the client before the project begins.

​

Refactoring- and Extensions-Projects

For refactoring projects and website extensions without a complete design reference, the following applies: inconsistencies, minor oversights, and UI/UX issues we encounter during our work will be cleaned up. This is part of our quality standards, not a separate coordination item for every individual case. For more significant changes, such as structural interventions in existing components, we give a brief heads-up in advance. Clients who want an exact copy of the current state will get that. In this case, we explicitly document which issues we have intentionally left untouched.