How I Build Digital Products: From Problem to Deploy

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. The decisions that matter happen before — and the ones that go 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 client never used.

What follows is what I apply 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 B2B 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 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 it's "we're losing deals because the competition looks more professional", it's an entirely different project.

The 6-stage process

Stage 1 · Discovery (days 0-3)

One single 30-minute call

No slides. No methodology. Just questions. The ones that work best 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 consciously.

Quick audit of the current state

While we talk, I open their site 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.

Silent research after the call

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.

Fixed structure:

1. What I heard. Bullets from the meeting, in their words.
2. Strategic understanding. What I learned from sector research.
3. Scope. Concrete modules with phase tags (F1, F2). No generalities.
4. Timeline. Weeks with specific milestones.
5. Investment. Clear numbers in USD. No "depends".
6. What's not included. Total transparency: if it doesn't include professional photography or translation, it says so here.
7. What I need to start. Checklist of client inputs.
8. Why Huevsite. 4 concrete differentiators.

Sent with a short message + invitation to a 15-minute review call 24-48 hours later. That call closes 70% of deals.

Stage 3 · Kickoff (week 1)

Kickoff = 50% deposit collected, access to a direct channel (1-on-1, no PMs), delivery of 3 things in week one:

1. Visual moodboard. 8-12 specific references. Not generic Pinterest — real references the client can compare.
2. Palette + typography. 2-3 colors, 1-2 fonts, applied to a real home mock. Not "typography exploration" — decisions made.
3. Information architecture. Which pages, what sections per page, what CTA per section. 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)

• Design and dev in parallel, not in series. I design the home in high fidelity while building the base system (components, layout). Once the home is approved, the rest of the site ships 5x faster.
• Weekly reviews with real progress. Mondays, 30 minutes, Vercel preview deploy. No endless mockups — the client clicks, navigates, tests.
• Fast decisions. When something pops up that wasn't in scope ("should we add a FAQ?"), we discuss it on the spot. 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 in production — get done:

• Performance. Lighthouse 95+ on mobile, LCP < 1.5s, CLS < 0.05.
• 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.
• Analytics. GA4 with specific conversion events, Search Console verified, form events firing.
• Cross-browser tests. Safari iOS, Chrome Android, Edge desktop, Firefox.
• Backup + rollback plan. If anything fails in production, 1-click rollback ready.

Stage 6 · Deploy + Handoff (week 5)

1. Deploy. One coordinated hour: DNS, SSL, smoke tests, first client review.
2. Admin training. 30-45 min on video — how to edit content, add products, swap images. Recorded for revisits.
3. Operational documentation. Short doc: how to access the admin, common changes, what NOT to touch, contacts.
4. Credentials. Vercel, domain, GA4, Search Console, CMS — everything transferred.
5. Final 50% billed. Once the client confirms everything is OK.
6. 30 days of post-launch support. For typos, micro-adjustments and bugs that surface with real usage.

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: "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 each 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.

Frequently asked questions — B2B web development process

How long does a B2B web development project take?

Simple landing: 2-3 weeks. Mid-size institutional site: 4-6 weeks. Complex site with internal tools or AI: 6-10 weeks. I work on one project at a time — the timelines are real.

Why is the proposal a web page and not a PDF?

The medium communicates seriousness. A web proposal loads fast, shares via link, survives in the client's inbox, and demonstrates technical capability. PDF closes at 25%; dedicated web page closes at 60%.

What if I need changes after delivery?

I include 30 days of post-deploy support for fine-tuning at no extra cost (typos, micro copy adjustments, bugs). After 30 days: optional monthly maintenance or per-project work.

Do you work with agile or waterfall methodologies?

Hybrid: scope locked at kickoff (waterfall), weekly reviews with preview deploys (agile), decisions made in the moment (no accumulating for sprint review). What I don't do: daily standups — they're noise for small projects.

How much do you charge per hour?

I don't charge per hour. Fixed-scope projects. The client knows what it costs and what I deliver before we start. No overbilling, no hidden scope creep.

Thinking about building a digital product or renovating your B2B site? In 30 minutes I'll help you separate the real problem from the stated problem. Book a diagnostic — free, no pitch.