A website project that goes wrong usually goes wrong early. Not in the design phase, not in development — in the brief. The decisions made before a single design file is opened determine the quality of everything that follows. Here is exactly how we run every project at Meyhora, and why we designed the process the way we did.
1. Discovery Call: What We Are Really Listening For
The discovery call is not a sales call. We are not selling ourselves — we are finding out whether we can actually help you. We ask about your business goals, your current website's performance, your target customer, and your previous experience with web projects. We are specifically listening for three things: clarity about who you are trying to reach, a realistic understanding of what a website can and cannot do, and a specific problem we can solve.
If the fit is not there — wrong budget, wrong expectations, wrong project type — we will tell you. We would rather refer you elsewhere than take on a project that will not succeed.
2. Strategy Document: Defining Success Before Designing Anything
Before any design work begins, we write a strategy document. It covers: the primary conversion goal, the target audience in specific detail, the three to five key messages the site needs to communicate, the success metrics we will measure the project against, and a content outline showing how the site architecture supports the conversion goal.
This document is reviewed and approved by the client before design begins. It eliminates the most common source of mid-project conflict: misaligned expectations about what the site is supposed to do. When feedback comes in later, we evaluate it against the strategy document. If a proposed change supports the conversion goal, we make it. If it does not, we explain why and offer an alternative.
3. Design Phase: How We Present Work and Handle Feedback
We design in Figma and present work in one cohesive round — not piecemeal. Rather than showing a homepage on day 3 and a services page on day 7, we present a complete set of pages together so the client can see the system, not just isolated parts. This makes feedback more focused and decisions more informed.
Feedback is structured around the strategy document. "Can you make the logo bigger?" is a personal preference. "The CTA is not prominent enough to drive the booking goal we defined" is a strategic note. We distinguish between the two and explain the distinction clearly. One round of revisions is included in every project. Additional rounds are scoped separately if needed.
4. Development: How We Build for Performance
We build in Next.js, deployed to Vercel. Not because it is the most popular framework — because it produces the fastest, most reliable websites we know how to build. Every site is server-side rendered for optimal SEO. Images are optimised automatically. Our build pipeline catches performance regressions before they reach production.
We do not use page builders, drag-and-drop platforms, or WordPress. Because they consistently underperform on the Core Web Vitals metrics that directly affect search ranking and user experience. Our sites regularly score 95+ on Google PageSpeed. That is a business outcome, not a vanity metric.
5. QA and Launch: Our Checklist Before Going Live
Nothing goes live without clearing our pre-launch checklist. It covers: mobile and tablet layout review across multiple devices and browsers, form submission testing, PageSpeed score verification on both mobile and desktop, SEO fundamentals (meta titles, descriptions, canonical tags, sitemap, robots.txt), redirect mapping from old URLs, analytics installation and goal tracking, and a final walkthrough with the client.
We also set up Google Search Console and submit the sitemap on launch day. We think this is basic professional practice.
6. Post-Launch: What the First 30 Days Look Like
Launch day is not the end of the project. The first 30 days are a monitoring period. We watch for crawl errors in Search Console, review early analytics data to confirm goal tracking is working, and address any issues that surface in the real-world environment. Most projects require one or two small adjustments post-launch — a form field, a mobile spacing issue, a redirect that was not on the original list.
At the 30-day mark, we do a short review call to go over the data, confirm everything is working as intended, and — if the client is interested — discuss what comes next: ongoing content, SEO work, or a conversion optimisation retainer. The website is a living thing. The best results come to clients who treat it that way.