Building a digital product isn't writing code. Code is the last stage, the most visible, and almost never the one that decides whether the product ships well or poorly. The decisions that matter happen before — and the ones that get made wrong afterward are the ones that kill projects.
I've spent 5 years building sites and digital products for companies, and the process I use today is the result of getting it wrong expensively a few times: underestimating scope, discovering the real problem too late, delivering something technically perfect that the customer never used. What follows is what I end up applying on every project, regardless of whether it's a 1-week landing or a 3-month internal tool.
The principle that orders everything
Before code comes the problem. Before the problem comes the question.
When a client says "I need a new website", the first question isn't "what stack do you want" or "how many pages". It's "what happens if you don't build it?". The answer to that question defines scope, budget, and what gets delivered first. If the answer is "nothing urgent, we want it to look more modern", the project is one thing. If the answer is "we're losing deals because the competition looks more professional", it's an entirely different project.
This is what separates "build what they asked for" from "solve the problem". The first fills calendars and empties clients. The second creates long relationships.
Stage 1 · Discovery (days 0-3)
Discovery is the most underestimated stage and the only one you can't compress without breaking everything that follows. I run it like this:
One single 30-minute call
No slide deck. No "methodology". Just questions. The ones that work best are the ones that sound dumb: "how do customers find out about you today?", "what makes someone say yes or no?", "what would happen if you didn't do this project?". Most clients haven't asked themselves those questions consciously, and the conversation surfaces them.
Quick audit of the current state
While we talk, I open their site (or product, or workflow) on shared screen. I jot down 5-10 things I'd change. Not to look smart — to have concrete observations that go into the proposal. The client sees that I understand the context before promising anything.
Silent research
After the call, I spend 1-2 hours looking at 3-5 real competitors. Not to copy — to map the terrain. Who's doing SEO well? Who shows pricing? Who has a clear process? This translates directly into the "Strategic understanding" section of my proposal.
Stage 2 · Proposal (days 3-5)
The proposal is the first real deliverable of the project. Not a generic PDF — a dedicated web page with 8 sections, built specifically for that client, that they can review offline and share internally.
The structure I use every time:
- What I heard. Points from the meeting, in bullets, in their words.
- Strategic understanding. What I learned from sector research.
- Scope. Concrete modules with phase tags (F1, F2). No generalities.
- Timeline. Weeks with specific milestones.
- Investment. Clear numbers in USD. No "depends".
- What's not included. Total transparency: if it doesn't include professional photography or translation, it says so here.
- What I need to start. Checklist of client inputs.
- Why Huevsite. 4 concrete differentiators.
The proposal goes out with a short message and an invitation to a 15-minute review call 24-48 hours later. That call closes 70% of deals — the proposal does the heavy lifting, the call only unblocks doubts.
Stage 3 · Kickoff (week 1)
Kickoff = 50% deposit collected, access to a direct channel (1-on-1 email or Slack, no intermediaries), and delivery of 3 things in week one:
- Visual moodboard. 8-12 specific references for how the product will feel. Not generic Pinterest moodboards — real references the client can compare against.
- Palette + typography. 2-3 main colors, 1-2 fonts, applied to a real home mock. Not "typography exploration" — decisions made.
- Information architecture. Which pages, what sections per page, what CTA per section. In plain text, no design yet. This is the scope contract.
At the end of week 1, the client signs (literally or via written approval) the moodboard, palette and architecture. If they don't sign, I don't move to visual design. This avoids the classic "I see it finished and I don't like it" in week 5.
Stage 4 · Design + Dev (weeks 2-5)
Here's where most people expect "magic code" to enter. It doesn't work like that. What I do:
- Design and dev in parallel, not in series. I design the home in high fidelity while building the base system (components, layout, dark mode if applicable). When the home is approved, the rest of the site ships 5x faster because the technical foundation is already there.
- Weekly reviews with real progress. Every Monday a 30-minute call with a Vercel preview deploy of the current state. No endless mockups — the client clicks, navigates, tests.
- Fast decisions. When a decision pops up that wasn't in the original scope ("should we add a FAQ?"), we discuss it on the spot, we don't defer it. If it adds scope, we add it as an extra. If it replaces something, we adjust. No ambiguity, no "we'll see at the end".
Stage 5 · Pre-deploy (week 4-5)
The week before deploy is the most important technically. This is when the things the client doesn't see — but which decide whether the site works — get done:
- Performance. Lighthouse 95+ on mobile, LCP < 1.5s, CLS < 0.05. If it doesn't hit, I tune before deploy.
- Technical SEO. Sitemap.xml, robots.txt, canonical URLs, hreflang if applicable, schema.org on every relevant page.
- AEO. llms.txt, llms-full.txt, structured data validated in Rich Results Test, content with clear semantic hierarchy.
- Analytics. GA4 with specific conversion events (not just pageviews), Search Console verified, form submission events firing.
- Cross-browser and cross-device tests. Safari iOS, Chrome Android, Edge desktop, Firefox. If anything breaks, fix before deploy.
- Backup and rollback plan. If something fails in production, I have a 1-click rollback ready.
Stage 6 · Deploy + Handoff (week 5)
Deploy is an event, not a long process. One hour of coordinated work: DNS cutover, SSL verification, smoke tests, first client review. After confirming everything's good, the handoff:
- Admin training. A 30-45 minute call where I show the client how to edit content, add products, swap images. Recorded so they can revisit later.
- Operational documentation. A short doc with: how to access the admin, how to make common changes, what NOT to touch, who to contact for what.
- Credentials and access. Vercel, domain, GA4, Search Console, CMS admin. Everything transferred to the client.
- Final 50% billed. Once the client confirms everything is OK.
What comes after
I include 30 days of post-deploy support for fine-tuning: typos, micro copy adjustments, bugs that surface with real usage. After 30 days, I move to an optional monthly maintenance arrangement or we work on a per-project basis.
What I don't do: mandatory maintenance contracts. The client should be able to not need me. If they call me 6 months later, it's because the site worked so well they're ready for the next phase.
The most expensive mistake that taught me this
In 2022 I delivered a technically perfect internal dashboard. Performant, scalable, with tests and docs. The client used it for two weeks and went back to Excel. When I asked why, they said: "It's too well built, my team is afraid to touch it".
That's when I understood: the technical output isn't the product. The product is what the client can use every day, without fear, without opening tickets. Since then, the last question before closing every project is: "Is this going to be used Monday at 9 AM, or not?". If the answer isn't a clear yes, work isn't done.
Are you thinking about building a digital product? In 30 minutes I'll help you separate the real problem from the stated problem. Book a diagnostic.