What Nobody Tells You Before You Build a Website

A few years into running a development company, you start noticing the same conversation happening over and over. A business owner calls, a bit frustrated, sometimes a bit embarrassed, and says some version of: "I wish I'd known this before I signed with the last guy."

It's rarely one big mistake. It's usually a handful of small things nobody bothered to explain, because explaining them slows down the sale. So here's an attempt to just say them plainly, without trying to sell you anything in the first half of this piece.

Your website is never really "done"

The idea of a website being finished — launched, checked off, complete — is mostly a fiction that makes the sales conversation easier. What actually happens is a business changes, the industry shifts, competitors do something new, and the site needs to keep up. Treating a website like a one-time purchase, the way you'd buy a printer, sets you up to be surprised later when it needs attention again.

This isn't a complaint about ongoing costs. It's just honest framing. A website is closer to a living part of the business than a finished product sitting on a shelf.

The demo is not the product

Every agency shows you a polished demo before you sign. What you're seeing is the best two minutes of a much longer story — the parts they chose to show you, in the order they chose to show them. It tells you almost nothing about what the code looks like underneath, how it'll behave under real traffic, or whether it can survive a feature request six months from now.

I don't say this to make anyone paranoid. I say it because the demo is genuinely the wrong thing to base a decision on, and most people don't realize that until they're three months into a project that doesn't match what the demo implied.

Cheap and expensive fail in different ways

There's a version of this advice that just says "you get what you pay for," which isn't quite right either. What's actually true is that cheap projects and expensive projects tend to fail for different reasons.

A very cheap project usually fails because there wasn't enough time or skill to do it properly — corners get cut somewhere, and you find out later which corners. A very expensive project usually doesn't fail on quality, but on speed and directness — you're paying for layers of process that slow down the small things you actually need fixed quickly.

Neither extreme is automatically wrong for every situation. But knowing which failure mode you're more likely to run into helps you actually prepare for it, instead of being blindsided.

Ask who's actually going to write the code

This sounds obvious once you say it out loud, and yet it's the question almost nobody asks. You'll talk to someone confident, knowledgeable, easy to trust — and that person may never touch your project again after the contract is signed.

It's not a trick question, and a good answer doesn't have to mean "the person you're talking to right now." It just needs to be a real answer. If you get vagueness here, that's worth noticing.

The first month tells you more than the pitch did

However good or bad the sales process felt, the first few weeks of actually working together reveal something the pitch can't. How quickly do they respond to a real question. Do they push back when something you're asking for doesn't quite make sense, or do they just agree with everything. Does the work you're seeing match what was described, or is there already a quiet gap opening up.

If you notice that gap early, it rarely closes on its own later. It tends to widen.

We've been on both sides of this

We've built things fast when the client needed speed, and slow and careful when the project genuinely called for it. We've had projects where the client's original idea needed to change, and we said so directly, even though it would have been easier to just build what was asked and let them find out later. We've also turned away work that wasn't a fit — not often, but often enough that it's part of how we actually operate, not just something we say.

None of that makes us the right fit for every project. Nobody is. But it's the honest version of what we do, without dressing it up.

Nobody mentions the boring stuff, and the boring stuff matters

Backups. Who owns the domain. Whether you actually have admin access to your own hosting account, or whether it's sitting in someone else's login. These questions feel almost insulting to ask upfront — of course you'll have access, of course there are backups — until the day you need one of them and find out the answer was never actually yes.

We've had more than one client come to us after a falling out with a previous developer, only to discover they didn't have the login to their own website. That's not a rare horror story anymore. It's common enough that it's worth asking about on day one, even if it feels a little awkward to bring up before any work has started.

Slow isn't always bad, and fast isn't always good

There's a reflex to treat a quick turnaround as a sign of a great team and a slow one as a red flag. Sometimes that's true. Sometimes it's the opposite. A project that gets built in two weeks when it genuinely needed six is usually a project where something got skipped — testing, a second look at the logic, a conversation about an edge case that would've mattered later.

We've had clients get anxious when we told them a realistic timeline instead of an appealing one. It's an uncomfortable conversation to have, and it would be easier to just say yes to whatever date sounds good in the moment. We'd rather have the uncomfortable conversation early than the more uncomfortable one later, when the corners that got cut start showing.

What we've actually learned from getting it wrong

We haven't gotten everything right every time. Early on, we said yes to a couple of projects we probably should have pushed back on harder — not because the client was unreasonable, but because we hadn't yet built the habit of being upfront about what wasn't going to work. Those projects taught us more about how to run this business than the ones that went smoothly.

That's not a confession dressed up as marketing. It's just true, and it's part of why the advice above isn't theoretical for us. We learned most of it by getting it wrong first.

If you're about to start this process

A few things worth carrying into your first conversation with anyone, us included: ask who does the actual work, not just who's pitching you. Ask what happens in month two, not just at launch. And pay attention to how a prospective partner responds when you push back a little — that reaction tells you more than almost anything in the proposal itself.

If any of this resonates because you're mid-project with someone else right now and something feels off, that instinct is usually worth trusting.