DEV Community: аЛЕКС ЛИР

The Question We Ask Before Quoting Any Redesign Project

аЛЕКС ЛИР — Thu, 27 Aug 2026 22:35:30 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. A large share of our work isn't new builds — it's redesigns of existing sites. For years we scoped those the same way we scoped new builds. That was the mistake.

"Redesign" hides two completely different projects under one word. Sometimes a client wants a visual refresh on a site that fundamentally works. Sometimes they want a visual refresh because the real problem is that the site doesn't convert, and they've concluded — often wrongly — that a new look will fix it. Quoting both the same way means underpricing the second one and over-delivering design work the client didn't actually need.

We now ask what's changed since the current site launched, not what they want it to look like. A business that's rebranded, added new services, or shifted its customer base has a real reason for a redesign that a style refresh will genuinely serve. A business whose situation hasn't changed but whose site "feels dated" usually has a narrower problem than they think — often just a couple of outdated design choices, not a full rebuild.

Analytics before opinions, every time. Before agreeing on scope, we pull whatever traffic and conversion data exists on the current site. It's changed the conversation more than once — a client convinced their homepage was the problem, when the data showed nobody was making it past a broken step three pages later. Redesigning the part that was actually fine would have wasted the whole budget.

Old content and structure carry more value than clients assume. A full rebuild throws away SEO equity, existing backlinks, and page structures that were quietly working, along with the parts that weren't. We now default to auditing what to keep before scoping what to replace — a full rebuild is sometimes right, but it should be a decision, not a default.

If your redesign quotes look identical to your new-build quotes, it's worth splitting them — the two projects solve different problems, even when the deliverable looks the same on paper.

Why We Started Charging for the Discovery Call

аЛЕКС ЛИР — Wed, 26 Aug 2026 22:57:43 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Discovery calls were always free, like they are for most agencies. A few years ago we started charging a small fee for the first real scoping call, and it changed who showed up to it.

Free calls select for the wrong signal. When something costs nothing, the people who book it aren't necessarily the ones closest to hiring — they're the ones curious enough to click a button. A small fee, credited toward the project if they hire us, filters for people who've already decided this is worth their time and money, not just their curiosity.

It changed the quality of the questions we got asked. Free-call clients often used the time to shop — comparing us against two or three other quotes with no real intent to decide that day. Paid-call clients came in with specifics: their budget, their actual constraints, their real timeline. The call stopped being a sales pitch and started being real scoping, because both sides had already signaled seriousness.

It cut our no-show rate close to zero. Free calendar slots get no-showed constantly, because there's no cost to skipping something you didn't pay for. A paid booking gets kept.

The fee isn't really about the money. It's small enough that it's not a meaningful revenue line — it's a filter. The actual value is fewer wasted hours on calls that were never going to convert, which freed up time for the calls that were.

It's not right for every business model. If you're optimizing purely for lead volume, or your average project size is small enough that a paid call feels disproportionate, this probably doesn't make sense. It worked for us because our calls are genuinely consultative, not a scripted pitch — the fee reflects real time being spent, not gatekeeping for its own sake.

If your free discovery calls are eating hours with little conversion, it's worth testing a small paid filter on a subset of leads before assuming free access is what's driving volume.

Why We Started Charging for the Discovery Call

аЛЕКС ЛИР — Tue, 25 Aug 2026 21:47:46 +0000

It cut our no-show rate close to zero. Free calendar slots get no-showed constantly, because there's no cost to skipping something you didn't pay for. A paid booking gets kept.

If your free discovery calls are eating hours with little conversion, it's worth testing a small paid filter on a subset of leads before assuming free access is what's driving volume.

The One Paragraph in Every Contract That Prevents Most Disputes

аЛЕКС ЛИР — Mon, 24 Aug 2026 23:24:39 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Contracts in this industry tend to focus on price and timeline. The paragraph that's actually saved us the most trouble isn't either of those — it's the one defining what "revision" means.

Most disputes aren't about money, they're about definitions. "Unlimited revisions until you're happy" and "three structured rounds of feedback" can describe the same actual work, but only one of them has an end state both sides agree on. Most of the ugly conversations we used to have weren't about the client being unreasonable — they were about a word ("revision," "included," "final") that meant something different to each side, discovered only once it mattered.

We now define "in scope" by example, not by category. Early contracts said things like "reasonable design changes included." Reasonable to whom? Now we list actual examples — "changing text, swapping images, adjusting colors: included. Restructuring page layout after approval: new scope." Concrete examples resolve arguments before they start; abstract categories just move the argument to interpretation time.

The scariest sentence to put in a contract turned out to be the most useful one. We now explicitly state what happens if the client goes silent for 30+ days mid-project — the project pauses, and resuming requires a new scope check. It felt aggressive to write down. In practice, it's protected clients as much as us: nobody's quietly on the hook for a project that stalled on their end, and nobody's surprised by a new invoice for work that restarts after a long gap.

None of this replaces trust — it just removes the need to test it. A good client relationship survives an ambiguous contract most of the time. The paragraph earns its place in the rare cases where it doesn't — where the ambiguity itself becomes the argument, regardless of how reasonable either side is being.

If your contracts define price and deadline but leave "revision" and "included" as unstated assumptions, that's usually where the actual disputes live — not in the numbers, in the words everyone assumed meant the same thing.

Who Actually Owns the Website — and Why Clients Never Ask Until They Want to Leave

аЛЕКС ЛИР — Sun, 23 Aug 2026 21:02:17 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Ownership never comes up during a happy project. It only comes up when a client wants to switch developers, and suddenly discovers the domain, hosting account, or a key plugin license isn't actually theirs.

Registering the domain under your own account feels efficient, and it's the single worst thing you can do to a client. Early on, we'd register domains for clients because it was faster than walking them through it. Years later, some of those clients wanted to move to another developer and couldn't, because the domain lived in our account, under our payment method. Nothing malicious — just an ownership gap nobody noticed until it mattered. We now register everything directly under the client's own account, even when it's slower for us upfront.

Premium plugin licenses are often tied to the developer, not the site. A lot of premium WordPress plugins license per-account, not per-domain. If a developer built a site using their own plugin license, the client's site can silently lose functionality the moment that developer stops renewing it — sometimes years after the relationship ended, with no warning. We now document every paid plugin and whose license it's under, as a deliverable, not an afterthought.

Hosting accounts create the same trap in reverse. A client who never sees their own hosting login has no real ownership, even if their name is on the invoice. If the developer disappears, so does access to the actual site. We hand over hosting credentials at project completion by default now, not on request — because "on request" assumes the client knows to ask, and most don't.

None of this shows up as a problem until someone tries to leave. A functioning relationship never surfaces an ownership gap. It only surfaces during a transition — which is exactly the worst time to discover it, because it's also the moment of least trust and least patience for a technical explanation.

If you build client sites, it's worth auditing what's actually in the client's name versus yours — not because anyone's acting in bad faith, but because ownership gaps are invisible right up until someone needs the exit door.

Why We Started Saying No to "Just Make It Look Like [Competitor]"

аЛЕКС ЛИР — Sat, 22 Aug 2026 23:42:37 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. "Can you just make our site look like [competitor]'s" is one of the most common briefs we get. For years we said yes without pushing back. Now we treat it as a request that needs a follow-up question before any work starts.

"Looks like" almost never means "looks like." Dig one layer deeper and the actual request is usually about an outcome, not an aesthetic — the competitor ranks higher, gets more calls, seems more established. Copying the visual style doesn't touch any of that. We've shipped visually similar sites that solved nothing, because the client's real problem was never on the surface.

Competitor sites are optimized for a business you can't see. A competitor's homepage might be built around a sales team that handles all real conversion by phone, or a brand budget the client doesn't have, or a completely different customer acquisition channel. Copying the layout without knowing what it's actually built to support means importing someone else's strategy without any of the context that makes it work.

Asking "what specifically about it do you want" filters signal from noise fast. Sometimes the honest answer is "the color scheme feels more professional." That's a real, small, actionable note. Sometimes it's "they seem more trustworthy" — which is a positioning and content problem no layout change will fix. Same brief, completely different scope, and you only find out which one you're dealing with by asking.

Benchmarking is useful. Copying is a shortcut to someone else's mistakes, too. We still pull competitor sites for reference constantly — it's a legitimate, fast way to calibrate expectations. The difference is treating them as one data point among several, not as the brief itself.

If "make it look like theirs" is a request you take at face value, it's worth pausing on — it's rarely actually about the look, and building for the wrong problem is slower than asking one more question up front.

The Backup Strategy Nobody Asks About Until They Need It

аЛЕКС ЛИР — Fri, 21 Aug 2026 22:41:06 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Backups are the least glamorous line item in any proposal, and for years we treated them that way too — mentioned once, rarely explained, easy to skip. Then we had one bad incident, and it became the thing we now explain most carefully.

Clients assume backups exist by default, until the moment they don't. Nobody asks "do you back up my site" during scoping — it's assumed, the way people assume a car has brakes. That assumption is fine right up until a plugin update corrupts the database or a hosting migration goes wrong, and suddenly a missing backup isn't a technical oversight, it's the worst conversation you'll have with a client all year.

Hosting-provided backups are not the same as an actual backup strategy. A lot of budget hosting plans advertise "daily backups" that turn out to be a single rolling snapshot, overwritten daily, stored on the same infrastructure as the live site. If that infrastructure fails, the backup fails with it. We now treat off-site, versioned backups as a separate line item from hosting — because they solve a different failure mode.

The real test of a backup isn't whether it exists, it's whether you've restored from it. We didn't actually know our backup process worked until we were forced to use it under pressure. Now we test a full restore periodically, on a non-live environment, specifically so the first time we ever restore something isn't during an actual emergency.

Explaining this upfront changes how clients perceive incidents later. A client who knows backups exist and how recent they are reacts to a bad update very differently than one who's never thought about it — the first asks "how old is the last backup," the second panics. That difference in reaction is entirely a function of one five-minute conversation at project start.

If backups are a line you gloss over in your own proposals, it's worth making them explicit — not because clients will pay more for it, but because it's the cheapest trust you'll ever build, redeemed only once, at exactly the moment you need it most.

The Feedback Format That Cut Our Revision Rounds in Half

аЛЕКС ЛИР — Wed, 19 Aug 2026 23:48:52 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. For years, feedback came in however clients wanted to send it — long emails, voice notes, a paragraph in a messenger app. Standardizing the format did more for our timelines than any process software we tried.

Open-ended feedback trains vague responses. "Can you send thoughts on the draft" reliably produces "I don't love it, something feels off." Not because clients are bad at feedback — because nothing in the request asks for specifics. Once we switched to a simple structured form — what page, what element, what should change, why — the same clients gave precise, actionable notes without any change in how engaged they were.

Voice notes and long emails hide the actual decision. A five-minute voice note often contains one real piece of feedback buried in a lot of thinking-out-loud. Transcribing and extracting it cost us real time per round. A structured field forces the client to arrive at the decision themselves before sending it, instead of outsourcing that synthesis to us.

Consolidating feedback into one submission, instead of a trickle, changed the pace of projects more than anything else. Open channels invite one-line follow-ups sent as they occur to the client — "oh also, can we change the button color" arriving separately, hours after the main note. A single structured submission per round meant we could batch changes instead of context-switching all week on the same page.

It also made scope disputes rarer, not just faster. When feedback specifies "change X to Y," there's no ambiguity about whether a request was in scope. When it's "this doesn't feel right yet," almost anything could satisfy it — which is exactly the kind of open-ended request that turns into unpaid extra rounds.

The format didn't need to be sophisticated. A shared doc with four fields did more than any feedback tool we evaluated, because the constraint was the point — it made vague feedback structurally harder to give.

The Client Question That Predicts a Six-Month Project Better Than Any Spec

аЛЕКС ЛИР — Tue, 18 Aug 2026 22:25:15 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. There's one question I now ask on every discovery call that I used to skip, and skipping it cost me more time than almost anything else in the business: "What happens if this project runs a month over?"

The answer tells you who actually controls the timeline. Some clients say "no problem, take the time you need." Others visibly flinch — there's an event, an investor update, a seasonal deadline they hadn't mentioned. Learning that in week one changes how you sequence the work. Learning it in week six, when the deadline suddenly becomes urgent, means you're renegotiating scope under pressure instead of planning around it from the start.

Silence on this question is its own answer. A client who can't articulate any consequence to slipping usually hasn't thought about the timeline at all — which means the deadline they gave you was arbitrary, not load-bearing. That's useful too: it tells you there's room to push back on scope without real cost to them, versus a client where every week genuinely matters.

It surfaces hidden dependencies you'd otherwise find out about late. More than once, the honest answer revealed that the site launch was gated on something else entirely — a rebrand not yet finalized, a product not yet ready, an investor deck that needed the URL before anything else did. Building against a deadline without knowing what's actually driving it means you can hit your date and still fail the client's real goal.

It's a five-second question that most intake processes skip entirely. Most discovery calls are structured around what the client wants built. Almost none ask what breaks if it's late. That single gap is why so many "urgent" projects turn out not to be urgent at all, and so many quiet ones turn out to have a hard, unstated deadline underneath.

If your intake process covers scope and budget but not consequence, it's worth adding — it costs one question and tells you more about how to sequence a project than the brief itself usually does.

The Hosting Decision That Determines Whether a Client Ever Calls You Angry

аЛЕКС ЛИР — Mon, 17 Aug 2026 21:09:33 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. If I had to isolate the single decision that predicts how many angry calls I get post-launch, it's not the code, the design, or the CMS. It's which hosting plan the client picked.

Cheap shared hosting generates support tickets that look like your fault. A site that's technically well-built on a $3/month shared plan still goes down during traffic spikes, still runs slow on shared CPU, still gets flagged when a neighboring site on the same server gets blacklisted. None of that is your code failing. All of it reads to the client as "the website you built is broken."

Clients choose hosting on price, because nobody explains what the price is trading away. Left alone, most small-business clients pick the cheapest hosting option, because from their side, hosting is an undifferentiated commodity line item. It isn't — it's the difference between a site that survives a local news mention and one that falls over from it. Explaining this once at project start costs five minutes and prevents most of the "your website is down" calls that come six months later.

We stopped treating hosting recommendation as optional. It's not in most contracts, and it's easy to let clients self-select their host to keep the sales conversation simple. But vetting hosting has quietly become part of the actual deliverable for us, even when it's not billed as one — because an outage on bad hosting damages the same trust that a bug in our own code would.

The client's mental model is "is the website working," not "whose responsibility is this." When something breaks, they don't parse out hosting versus code versus DNS versus their own domain renewal lapsing. They just know something they paid for stopped working. Being the person who explains and fixes it — regardless of whose layer it's actually in — is what keeps the retainer, technically at fault or not.

If you build sites and hand off hosting decisions entirely to clients, it's worth revisiting — the support burden that follows is often a hosting problem wearing a "the website is broken" costume.

SEO Advice I Stopped Giving Small-Business Clients (Because It Never Mattered)

аЛЕКС ЛИР — Sat, 15 Aug 2026 21:30:05 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. A lot of what passes for SEO best practice online is written for content sites and SaaS products chasing organic traffic at scale. Almost none of it applies to a local plumber's five-page site, and it took me years to stop pretending otherwise.

Keyword density and meta-tag perfection barely move the needle for local clients. I used to spend real time polishing title tags and meta descriptions to some ideal template. For a business competing on "plumber in [small city]," a correct, accurate Google Business Profile did more for visibility than any on-page tweak I made. The channel mattered more than the technique.

Page speed matters, but not for the reason people think. It's not really about search ranking for these clients — it's about the visitor leaving before the page loads, on a spotty mobile connection, before they ever see the phone number. Optimizing speed as a conversion fix, not an SEO fix, changed how I prioritized it.

Blog content almost never pays off at this scale. I've pitched "let's add a blog for SEO" to clients who had neither the traffic volume nor the topical authority for it to compound into anything. For most small local businesses, a blog is a maintenance burden with no realistic payoff horizon — the honest answer is often "don't."

Reviews outperform almost every technical SEO lever combined. A steady stream of real Google reviews did more for local visibility than any structured data markup I've implemented. It's not a dev task, which is exactly why devs underrate it — but it's the highest-leverage thing in the whole stack for this client type.

The actual skill is knowing which advice doesn't apply to your client's scale. Most SEO content online is right — for the audience it was written for. Applying it uncritically to a five-page local business site isn't wrong, it's just solving a problem the client doesn't have, while the problem they do have goes unaddressed.

If you do small-business web work, it's worth auditing your own checklist for advice you're following out of habit rather than because it moves outcomes for clients this size.

Why We Bill by Package, Not by Hour — and What It Forces Us to Get Right

аЛЕКС ЛИР — Fri, 14 Aug 2026 21:26:09 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Early on we billed hourly, like most freelancers default to. We switched to fixed packages years ago, and it changed more than just invoicing.

Hourly billing rewards ambiguity — packages punish it. When you bill hourly, a vague brief just means more billable hours, so there's no real pressure to nail scope down early. Fixed pricing flips that: if the brief is vague, we eat the cost of the back-and-forth, not the client. That single incentive change forced us to get much better at scoping before work starts, not during it.

It kills the awkward mid-project money conversation. Nobody enjoys telling a client "this is taking longer than expected, here's an updated invoice." Fixed packages move that conversation to before the project starts, where it belongs — you negotiate scope, not surprise fees.

It makes "no" easier to say. With hourly billing, extra requests are just more hours, so there's a mild incentive to say yes to everything. With fixed pricing, every extra request is a direct hit to margin, which means we actually have to decide — is this in scope, or is this a paid add-on — instead of quietly absorbing it and resenting it later.

It's a worse deal for us on hard projects, and a better deal on easy ones — and that's fine. Some projects come in under the time we estimated, some run over. Over 235+ projects, it evens out, and the predictability is worth more to both sides than optimizing each individual project's margin.

The tradeoff: it only works if you're honest about what's actually included. Fixed pricing without clear scope just becomes hourly billing with extra steps, dressed up as transparency. The package has to name exactly what's in it — which is most of the actual work of switching models in the first place.

If you're freelancing hourly and hitting the same scope-creep conversations over and over, the fix probably isn't a stricter contract — it's removing the incentive that makes ambiguity profitable for you in the first place.