Most agencies have a process. Few of them actually follow it. Ours exists because we got burned enough times by not having one.

Why process matters more than most clients expect

When a client comes to us, they are usually thinking about the outcome: a new website, a better one, something that works harder for their business. Process feels like a means to an end, the administrative part before the real work begins.

We used to think the same way. We were wrong.

The projects that went sideways in our early years had one thing in common. Not difficult clients, not unclear briefs, not technical problems. They went sideways because there was no shared structure for how decisions got made, who owned what, and what happened when something changed mid-project. Process is not the boring part. It is the part that determines whether the outcome is any good.

Here is how we actually work, from the first conversation to the moment a site goes live.

Discovery: understanding before proposing

Every project starts with a discovery phase. Not a sales call, not a proposal. A conversation where we ask more questions than we answer.

We want to understand what the client is trying to achieve, who their audience is, what currently gets in the way, and what success looks like twelve months after launch. We also want to understand constraints: budget, timeline, internal resources, existing tech stack, any decisions that have already been made that we need to work around.

This phase typically takes one or two sessions. By the end of it, we have enough to know whether we are the right fit for the project and what the project actually is, which is often different from what was described in the initial brief.

We do not skip this phase even for smaller projects. A two-week build that starts without clarity is slower and messier than a two-week build that started with a focused discovery session.

Strategy: deciding what the site needs to do

Before any design work begins, we align on strategy. This means defining the site architecture, the content structure, the primary user journeys, and the key performance indicators we are building toward.

This is also where we make technology recommendations. For most of our clients, Webflow is the right platform. It gives us the design control we need and gives them the editorial independence they want after launch. When e-commerce is involved, we bring Shopify into the picture and connect the two through Smootify. When the client has specific requirements that change the equation, we say so.

Strategy is delivered as a written document, not a slide deck. Decks are easy to skim and hard to refer back to. A clear written brief is a decision record. Everyone knows what was agreed and why.

Design: from structure to visuals

Design at Eclipse starts in Figma. We begin with wireframes, low-fidelity layouts that focus on structure and hierarchy before any visual decisions are made. This is a step that clients sometimes want to skip, especially when they have strong visual references. We push back on this, because visual references are not the same as structural clarity.

Once the structure is approved, we move into high-fidelity design. This is where the visual language of the site takes shape: typography, color, spacing, interaction patterns, the feel of the thing. We design in components from the start, which means every decision made at this stage translates directly into how Webflow will be built.

Client feedback happens in Figma, with comments attached to specific elements. We do not accept feedback by email. This is not bureaucracy. It is the only way to keep feedback traceable and to avoid the situation where conflicting notes from different stakeholders create a version of the project nobody actually agreed to.

Build: Webflow as the single source of truth

Once design is signed off, we move into Webflow. The build phase is where the design system becomes a live site. Variables, components, interactions, CMS structure, responsive behavior across breakpoints: everything is built to production standard from day one.

We do not build a rough version and then refine. We build once, correctly. This takes longer upfront and saves significant time later, both during the project and during the ongoing relationship with the client after launch.

QA happens internally before anything is shown to the client. We test across devices, browsers, and connection speeds. We check all SEO fundamentals: page titles, meta descriptions, heading hierarchy, schema markup, image optimization, sitemap. We run a Lighthouse audit and address anything critical before handoff.

Launch and beyond

Launch is not the end of the relationship. For most of our clients, it is the beginning of a more structured one.

We handle the technical side of launch: domain connection, SSL, redirects from any previous URL structure, Search Console setup and sitemap submission. We do not hand over a site and disappear.

After launch, we offer ongoing subscription plans for clients who want Eclipse to remain an active partner rather than a vendor they call when something breaks. That model works better for everyone involved, and we will write more about it separately.

The process we have described here is not unusual in its components. Discovery, strategy, design, build, launch: every agency has some version of this. What makes the difference is the discipline to actually follow it, especially when a client is in a hurry or when the temptation to shortcut a phase is strong.

We have learned, more than once, that the shortcut always costs more time than it saves.