DEV Community: аЛЕКС ЛИР

Why We Stopped Promising "Mobile-Friendly" and Started Testing on Actual Devices

аЛЕКС ЛИР — Tue, 01 Sep 2026 20:43:22 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Every page builder claims responsive design out of the box, and technically, they deliver it. "Technically responsive" and "actually works on the phone a real customer is holding" turned out to be two different promises.

Responsive templates handle layout, not intent. Elementor and similar tools will reflow columns and resize text automatically — that part's solved. What they don't solve is whether a click-to-call button is actually reachable with a thumb, or whether a form field triggers the right keyboard on iOS versus Android. Those gaps don't show up in a browser's device-emulation view. They show up when an actual person tries to book an appointment on a cracked phone screen with one hand.

We used to test in Chrome DevTools and call it done. Emulated mobile views are close enough for layout checks, not close enough for real UX issues — actual tap target sizing, real network speed on 4G instead of localhost, actual browser quirks on Safari iOS that Chrome's emulator doesn't reproduce. We now test every build on at least one real Android and one real iPhone before calling a project finished. It's added maybe twenty minutes per project and caught things emulation never would have.

Most of our client base's actual traffic is mobile, which raises the stakes on this specific gap. For local-business sites — the kind we mostly build — a large majority of visits come from someone searching on their phone, often with intent to call or visit within the hour. A subtle mobile UX bug isn't a minor polish issue for this audience; it's actively costing the client business, in a way a broken desktop layout wouldn't.

The failures we catch are almost always small and specific, not structural. A phone number that's styled like a link but isn't actually tappable. A sticky header that eats half the screen on smaller devices. An input field that doesn't trigger the numeric keypad for a phone number. None of these break the layout. All of them quietly cost a client a lead.

If your QA process stops at a responsive-view checkmark in dev tools, it's worth adding one real device to the checklist — the gap between "renders correctly" and "usable by a real hand on a real phone" is where most of the actual friction hides.

The Silent Failure Mode: Domain Renewal, and Why We Now Own That Conversation

аЛЕКС ЛИР — Mon, 31 Aug 2026 22:37:03 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. Of all the ways a client's site can go down, the most avoidable — and most common — has nothing to do with code, hosting, or plugins. It's a domain that lapsed because nobody was watching the renewal date.

A lapsed domain looks identical to a catastrophic technical failure, to the client. From their side, the site is just gone. They don't see an expired registration notice buried in an inbox they don't check — they see "the website I paid for doesn't exist anymore," and the panic that follows is the same as if the server had caught fire. The actual fix is usually a five-minute renewal, but only once someone diagnoses that it's a domain issue and not a code issue.

Domain ownership and site maintenance are two separate relationships, and clients don't distinguish between them. A client might hire us for the site but register the domain years earlier through some other registrar entirely, with a personal email that's since been abandoned. Nobody explicitly owns watching that renewal date — not us, because we didn't register it, and not them, because they've forgotten it exists as a recurring obligation.

We now ask for domain registrar access as a standard part of onboarding, even when we don't manage renewals. Not to take ownership away from the client — to know when the expiration date is, so we can flag it before it becomes an emergency. A single calendar reminder, set once at project start, has prevented more downtime for us than any technical safeguard we've built.

SSL certificates fail the same way, for the same underlying reason. Auto-renewal usually handles this quietly, until a hosting migration or a config change quietly breaks the auto-renewal without anyone noticing until the certificate expires and browsers start showing warnings to visitors. It's the same category of failure as a domain lapse — invisible until it isn't, and entirely preventable with one person responsible for checking.

The pattern across both: failures that are 100% preventable tend to happen exactly because they're boring. Nobody gets excited about tracking renewal dates, so it's the task most likely to fall through the cracks between developer and client. The fix isn't technical sophistication — it's just deciding, explicitly, who's responsible for noticing before the countdown hits zero.

If you've never asked a client who owns their domain renewal or SSL monitoring, it's worth a five-minute conversation — it's the least interesting question you'll ask all project, and one of the most consequential.

What We Do Differently Since Our First Hacked WordPress Site

аЛЕКС ЛИР — Sun, 30 Aug 2026 23:42:23 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. WordPress's popularity is also why it's the most targeted CMS on the internet. Our first hacked client site taught us more about actual security practice than any checklist ever had.

Most hacks weren't sophisticated — they were unpatched plugins. The incident that changed our process wasn't a targeted attack. It was a known vulnerability in an outdated plugin the client had been running for over a year, because nobody was responsible for updating it. Reviewing our own client base afterward, outdated plugins were the single largest exposure across nearly every site we hadn't put on a maintenance plan.

"We'll update when something breaks" is a security policy, and a bad one. Clients — and honestly, some of our own younger habits — treated updates as optional maintenance, deferred until there was a visible reason to do them. Security patches don't announce themselves. By the time an outdated plugin causes a visible problem, the exposure window has usually already been open for months.

Admin usernames and weak passwords did more damage than any zero-day. A shocking number of the incidents we've cleaned up traced back to "admin" as the username and a password reused from somewhere else, not a novel exploit. Forcing unique credentials and disabling the default "admin" username costs nothing and closes off the most common attack vector we actually see in practice.

Recovery speed depends entirely on decisions made before the incident, not during it. The clients who recovered in an hour were the ones with recent, tested backups and a maintenance plan. The clients who lost days were the ones without either — discovering, mid-crisis, that their "backup" was a stale hosting snapshot from months earlier. Nothing about incident response is fast if the preparation wasn't already done.

We now treat basic hardening as part of every build, not an upsell. Unique admin usernames, login attempt limits, and a security plugin baseline ship by default now, regardless of package tier. It's a small addition to build time that prevents the most common, least sophisticated attacks — the ones that don't need a determined attacker, just an unpatched, unmonitored site.

If your client sites don't have someone actively responsible for updates, that's usually where the real exposure sits — not in some hypothetical sophisticated attack, but in the plugin nobody updated for a year.

Why We Now Require a Staging Site for Every Project, No Exceptions

аЛЕКС ЛИР — Sun, 30 Aug 2026 01:35:11 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. For a long time we built directly on the live domain for smaller projects, to save setup time. One bad plugin update during business hours ended that habit permanently.

Editing a live site is a bet that nothing goes wrong at the worst possible moment. Most of the time, nothing does. The one time it does — a plugin conflict, a broken update, a bad deploy — it happens on the client's live site, in front of their actual customers, with no fallback. A staging environment moves that risk to a copy nobody's looking at.

Clients don't ask for staging, because they don't know to. It's not in most briefs, because non-technical clients don't think in terms of environments — they think "is the website working." Skipping it saves us setup time upfront and creates the exact conditions for the most stressful support call we get: something broke, in public, with no undo button.

It changed how confidently we ship changes, not just how safely. Knowing a change can be tested somewhere consequence-free means we make bolder, faster updates instead of being overly cautious about every small change on a live site. Paradoxically, staging made us move faster, not slower — the caution moved to the right place instead of being applied everywhere.

It's also where client approval actually belongs. Getting sign-off on a staging link before pushing to production means "approved" happens before the change is public, not after a client discovers it live and reacts in real time. That single sequencing change removed most of our post-launch "wait, I didn't approve this" conversations.

The setup cost is smaller than the incident it prevents. A staging environment on most modern hosts takes minutes to spin up. Weighed against even one instance of a broken live site during business hours, it's not a close call — it just took one bad incident before we treated it as non-negotiable instead of optional.

If you're still editing directly on production for smaller projects to save setup time, it's worth pricing in what one bad update during business hours actually costs — that's usually the number that changes the habit.

Why We Stopped Offering "SEO Included" as a Checkbox

аЛЕКС ЛИР — Fri, 28 Aug 2026 20:54:21 +0000

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. For years, every package included "basic SEO" as a bullet point. It sounded like a value-add. It was actually a promise we couldn't consistently keep, and clients eventually noticed.

"SEO included" meant different things depending on who built the site that week. Without a defined checklist, "basic SEO" became whatever the person building the site remembered to do — sometimes meta tags and alt text, sometimes a sitemap submission, sometimes nothing beyond what the page builder did automatically. The client heard one promise. We delivered an inconsistent one, and neither side knew it until a client asked why they weren't ranking.

Clients conflated "SEO included" with "will rank on Google." That gap between what we meant (structural on-page basics) and what they heard (guaranteed visibility) caused more disappointed clients than any other line item in the proposal. The fix wasn't better SEO — it was better naming. We renamed it "on-page SEO setup" and listed exactly what's in it: title tags, meta descriptions, image alt text, sitemap, basic schema. No promise about rankings, because we don't control that.

We separated "setup" from "ongoing" explicitly, because they're not the same service. On-page setup is a one-time technical task. Actual SEO performance requires ongoing content, backlinks, and time — none of which a $300 landing page package can reasonably include. Bundling them under one vague label let clients assume they'd bought the second thing when they'd only bought the first.

Being precise about what's not included did more for trust than the feature itself. Once we started explicitly stating "this does not include ongoing content strategy or link building," clients who wanted that could ask for it as a separate, honestly priced service — and clients who didn't stopped expecting rankings from a checkbox they never should have relied on in the first place.

If your service packages include vague, unscoped line items like "basic SEO" or "performance optimization," it's worth naming exactly what's in them — the ambiguity that feels generous at signing usually turns into disappointment at delivery.

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.