Introduction

A few years ago, a client came to me with an idea for a web project: a platform to connect local craftsmen with nearby customers. He described the review system, the matching algorithm, the admin panel, the mobile app. He already had the name, the logo, and a twelve-page Word document.

When I asked how many craftsmen he'd actually contacted to find out whether they'd use the platform, he said: "None yet. I want to finish planning first."

He never finished. He'd planned everything except the one thing that mattered: verifying that anyone would actually use it.

I've seen this pattern too many times — in clients and in my own personal web projects. That's why I stopped optimizing the planning phase and started thinking differently.

Why Most Web Projects Fail

The standard narrative around "how to build a web project" focuses on phases: ideation, analysis, development, launch, growth. It's a sensible framework on paper. The problem is it assumes the idea has already been validated — that the remaining work is just translating it into code as efficiently as possible.

In practice, 90% of failed projects don't fail because the code was bad or the team was weak. They fail because the core assumption was wrong: that people had that problem, that they'd pay to solve it, that the proposed solution was the right one.

All the technical work — stack, architecture, CI/CD, optimization — is completely irrelevant if that assumption doesn't hold.

So the first thing I do when evaluating an idea, mine or a client's, is isolate the central assumption. Not "I want to build X" but "I'm betting that Y is true." Then I look for the fastest, cheapest way to find out whether Y actually is true.

90% of web projects don't fail because of technical problems. They fail because nobody tested the core assumption before starting to build.

Validate Before You Build

Validating doesn't mean doing a market analysis with Excel spreadsheets. It means finding a real person who tells you they have that problem, that they already spend money or time on it, and that they'd use your solution.

The most direct method I know: put up a landing page with a clear description of what the product does and a "Sign up / Join the waitlist" button. Spend a few euros on targeted ads. Measure how many people sign up.

You haven't built anything. You haven't written a single line of backend code. But you already have a real data point: there's interest, or there isn't.

If there's no interest, you've saved months of work. If there is, you also have a list of people to contact to understand what they expect — and those conversations are worth more than any spec document written at a desk.

Validation isn't a phase of the project. It's the condition that makes starting it worthwhile.

The Stack: Decide It in an Afternoon

One of the most classic time-wasters in web projects is choosing the tech stack. I've seen Reddit and Discord threads where developers spend weeks comparing frameworks, debating which ORM to use, deciding whether to go monolith or split into microservices from day one.

The almost always right answer: use what you know best.

That's not laziness. It's that the "wrong" stack you know perfectly gets you to a working MVP in a month. The theoretically superior stack you're learning on the fly gets you there in six months, with all the extra problems of hitting errors you don't yet know how to debug.

I work primarily with Laravel for the backend and Tailwind for the frontend. Not because they're objectively superior technologies — I don't know that and I'm not interested in settling the debate — but because with these I can go from idea to working product in the shortest time possible. And time, in a new project, is the scarcest resource.

The exception is when the project has specific technical requirements that demand a different choice: high concurrency, real-time, large-scale data processing. In that case it's worth slowing down. But most web projects don't have these requirements, at least not at the start.

The right stack isn't the most interesting one to learn. It's the one that gets you to a working product in the least time with the fewest unknown errors.

What MVP Actually Means

MVP has become one of those terms everyone uses and almost no one applies correctly. In practice, when people say "let's do an MVP" they mean "let's do a smaller version of everything we planned." That's not an MVP — it's just a smaller project.

A real MVP answers a specific question. Not "does the product work?" but "is this core assumption correct?"

If I'm building a platform for craftsmen, the MVP isn't the platform with fewer features. It's the cheapest way to test whether craftsmen will accept jobs through a digital channel. It could be a WhatsApp chat. It could be a Google Form. It could be me doing manually what the software is supposed to do automatically.

Only once I know that the behavior I want to generate already exists — that people buy, sign up, come back — does it make sense to invest in developing software that automates it.

An MVP isn't a scalable product. It's an experiment designed to falsify an assumption in the shortest time possible.

Developing a Web Project Incrementally

Once the MVP has validated the initial hypothesis, you can start building in earnest. The opposite risk here is building too much, too fast, accumulating complexity that becomes impossible to maintain.

The way I approach iterative development: every two weeks I ask myself one question. "What could I remove without any real user noticing?" If the answer is "a lot," that's a signal I've built features nobody uses. Better to know that now than after adding ten more features on top.

For project management I don't use anything complex. A Notion list with three columns: to do, in progress, done. An extra column for ideas I haven't decided whether to implement yet. Everything that doesn't translate into a specific assigned task stays in that column until it becomes clear whether it's worth doing.

For team projects or client work I use Linear, which has the advantage of being much faster than Jira without sacrificing the essential features.

The Launch

Launching a web product has a reputation as a major event: the day everything is revealed to the world. In practice, for most projects, the launch should be as quiet as possible.

The reason is simple: the product at launch is almost certainly wrong about something important. Not because the work was done badly, but because assumptions only get corrected through real use. The sooner real users arrive, the sooner these problems emerge, and the sooner you can correct course.

The strategy that works best: launch to a small group of users — the ones you gathered during the validation phase, or a specific niche of your target audience. Collect direct feedback. Fix things. Then expand.

The big public launch, if it makes sense at all, comes after the product has already proven it works at a small scale.

Measuring the Right Things

Once online, the risk is drowning in metrics. Google Analytics, Search Console, heatmaps, session recordings, surveys — it's easy to spend more time analyzing data than improving the product.

The metrics that matter in the early phase are few, and they depend on what the project is trying to do. For a SaaS: conversion rate from signup to first use, and 30-day retention. For a blog or editorial site: return visits and time on page. For an e-commerce: purchase completion rate.

Everything else is noise, at least until the project has reached a scale where optimizing those secondary metrics makes an appreciable difference.

Something I find useful: once a month, one hour with Google Search Console and Analytics to answer three questions. What's performing better than expected? What's worse? What's the single change that could have the biggest impact over the next four weeks? Just that.

The Most Common Mistake I Still See

After twenty years, the mistake I see most often — in others and in myself during moments of distraction — is waiting until the product is ready before showing it.

It's never ready. It never will be in the way you imagine it. And every week that passes without real users is a week you're building on unverified assumptions.

The right moment to show something is sooner than you think. Usually when you're still a little embarrassed to do it — Reid Hoffman made this famous with LinkedIn, and after all these years it keeps being true.

If you're not at least a little embarrassed by your MVP, you've probably waited too long.