DEV Community: аЛЕКС ЛИР

How we redesigned our own studio's pricing page — and what it taught us about client psychology

аЛЕКС ЛИР — Thu, 06 Aug 2026 19:49:58 +0000

A few months back we rebuilt the pricing section on our own site, webmaster.co.ua, after years of running it as "contact us for a quote." Here's what changed and why.

We split price into named packages instead of a single custom quote. The old flow funneled every lead into a call before they saw a number. Now the site lists four tiers — a $200–400 landing page, a $400–800 business site, an $800–1,500 SEO-focused build, and a $1,500+ custom tier — each with what's actually included. Conversions from "just browsing" to "sent a message" went up, but more importantly, the messages themselves got more specific. People arrive already knowing which tier fits, so the first message is "I need the business tier, here's my situation" instead of "how much would a website cost."

We stopped hiding that the base tier uses AI-generated placeholder copy. This was the part we debated longest — does saying it upfront make the cheap tier look cheap? It didn't. It made expectations match reality, which meant fewer clients arriving at review stage disappointed that the copy wasn't hand-written. Naming the tradeoff at the pricing page did more for satisfaction than trying to overdeliver on copy quality would have.

We linked reviews out to a third-party platform instead of only showing curated quotes. Testimonials on your own site are testimonials you selected. Ours now link to verified reviews on an external freelance platform alongside the on-site quotes. Visitors don't have to trust our curation — they can check the source.

None of this required new tech. The whole rebuild happened inside our existing WordPress + Elementor setup — no framework migration, no rebuild from scratch. The lesson wasn't technical at all: the pricing page was doing less work than it could, and fixing the information architecture mattered more than fixing the stack.

If you run a services site and you're still hiding pricing behind a contact form, it's worth testing the alternative on a subset of traffic before assuming transparency will scare people off. For us, it filtered the leads instead of losing them.

Why "unlimited revisions" was the worst thing we ever put in a proposal

аЛЕКС ЛИР — Tue, 04 Aug 2026 21:12:04 +0000

Early on, we offered unlimited revisions on every project. It sounded like great customer service. It was actually the single biggest source of missed deadlines and eaten margin in the business's early years.

Unlimited revisions removes the client's incentive to decide. When feedback is free and infinite, there's no cost to sending "actually, can we try it in blue instead" for the fifth time. Not because clients are unreasonable — because nothing in the process signals that a round of feedback is meaningfully different from the last one. Capping rounds (we settled on three structured rounds) forces both sides to consolidate feedback instead of trickling it in one email at a time.

"Unlimited" quietly becomes "indefinite." A project scoped for two weeks with unlimited revisions has no natural end state. We had projects drag past three months not because the work was hard, but because there was never a moment where "done" was the obvious next step. A fixed revision count creates that moment by default.

Vague feedback gets worse, not better, with more rounds. You'd think more rounds means more chances to get it right. In practice, open-ended revision cycles train clients to give reactive feedback ("I don't love it") instead of specific feedback, because there's no pressure to be precise. Fewer, structured rounds — each requiring written, specific notes — produced better final results with less total back-and-forth.

It punishes your best clients to accommodate your worst ones. The client who gives clear, decisive feedback finishes in one round and effectively subsidizes, through the price they paid, the client who needs six. Once we saw it that way, unlimited stopped feeling generous and started feeling like bad pricing design.

We still handle real post-launch issues and small tweaks without nickel-and-diming anyone. What we don't do anymore is treat "revisions" as a bottomless resource — because it never actually was one, we were just absorbing the cost silently instead of pricing it.

The client red flags that predict a bad project better than any technical spec

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

After 235+ projects, the signals that predict a painful engagement almost never show up in the technical requirements. They show up in the first conversation, before a single line of scope is written.

"I'll know it when I see it" is a budget problem, not a taste problem. When a client can't articulate what they want beyond that phrase, it usually means they haven't actually decided what the site needs to do — which means "final" designs will get relitigated at every stage. We now require at least two reference sites and a one-sentence goal before scoping starts. If a client can't produce either, that's the signal, not the design brief.

Fast "yes" to every price is a warning, not a win. A client who agrees to the quote instantly, with zero questions, often hasn't budgeted for it properly and will start negotiating scope down mid-project instead of price up front. The clients who ask hard questions about what's included tend to be the easiest to work with later — they've actually thought about what they're buying.

"My last developer disappeared" is rarely about the developer. It happens, sure. But when I hear this phrase multiple times about multiple past developers from the same client, the pattern usually points somewhere else — unclear scope, constantly shifting requirements, or unpaid invoices that never got mentioned. One instance is someone else's problem. A pattern is information.

Urgency without a reason is a scope-creep predictor. "I need this live by Friday" with no explanation (no event, no launch, no deadline from their side) usually means the urgency is emotional, not operational — and emotional urgency doesn't go away once you hit the deadline. It just moves to the next request.

The best predictor of a good project is a client who can say no to their own ideas. Someone who floats a feature and then says "actually, skip that, it's not worth the cost" is a client who understands tradeoffs — which means they'll make good decisions under pressure later, not just at kickoff.

None of this is in any project management course. But if you do small-business web work long enough, you stop reading specs for red flags and start reading the client instead.

What breaks first when a small business site gets popular — and it's never the code

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

I've watched a lot of small-business sites go from "nobody visits this" to suddenly busy — a viral post, a local news mention, a seasonal spike. The pattern of what breaks is almost never what junior devs assume it'll be.

Shared hosting caps out embarrassingly fast. A site that ran fine at 50 visitors a day can fall over at 500 if it's on a $5/month shared plan, regardless of how clean the code is. The fix usually isn't a rewrite — it's a hosting tier upgrade and basic caching. I've seen developers spend a week optimizing queries on a site whose real bottleneck was a shared CPU allocation.

Forms fail silently before pages do. Under load, the contact form or checkout is often the first thing to quietly stop working — a timeout, a plugin conflict, an email service rate limit — while the rest of the site looks completely fine. Nobody notices because nobody's staring at form submission logs on a small business site. This is the single most common "why did we lose two weeks of leads" conversation I have with clients.

Nobody has a plan, because nobody expected to need one. Enterprise projects get load-tested. A local bakery's site does not. When traffic spikes, the client's instinct is to email you in a panic rather than check a dashboard, because there was never a dashboard to check. Even a bare-minimum uptime and form-delivery monitor, set up at launch, turns a fire drill into a five-minute fix.

The client's real question is never "is it down," it's "am I losing money right now." Technical postmortems don't land with this audience. What lands is: here's what broke, here's what it likely cost you, here's what changes so it doesn't happen again. Framing incident reports around business impact instead of root cause is what actually keeps the retainer.

If you build for small businesses instead of scaled products, "handling traffic" isn't a system design problem — it's a monitoring and expectations problem. The code is rarely what fails first.

What "18 years in web dev" actually means when your clients are small businesses, not startups

аЛЕКС ЛИР — Fri, 31 Jul 2026 21:15:33 +0000

Most dev-to content about longevity comes from people who scaled one product for a decade. My version of 18 years is different: 235+ separate small projects, each with a different client, budget, and expectation. That produces a completely different set of lessons.

Every project restarts the trust clock. In a startup, trust compounds — the team, the codebase, the client relationship all carry forward. In agency work for small businesses, you start from zero credibility on every single engagement. The client has no idea if you're competent until you prove it, usually within the first draft. That reality shaped how we scope: front-load a visible win early, even a small one, rather than saving the "impressive part" for the end.

Most client requests aren't really about the website. "Can we change the homepage headline" is often actually "I'm nervous this won't generate leads" or "my business partner didn't like it." Treating every request as a literal design brief instead of what it's actually about leads to a lot of pointless revision cycles. Asking one clarifying question — "what's this in response to?" — before touching the page has cut our revision count more than any process change.

Consistency beats innovation for this client base. A small business owner doesn't want a novel UX pattern. They want their site to look like the successful competitor's site, load fast, and not embarrass them. Chasing design trends for this audience is optimizing for the wrong judge — they're not evaluating craft, they're evaluating "does this look like it'll work."

The real skill is saying no to the wrong project, not saying yes to more of them. Early on I took every lead. Now the highest-leverage thing I do is a 10-minute pre-call that filters out projects where the client's expectations and budget don't match — before either of us spends real time on it. That single filter has done more for margin than any pricing change.

None of this shows up in a portfolio. But if you're a developer weighing long-term freelance or small-agency work over a single-product career, this is the part that actually determines whether year 18 looks different from year 2.

The real maintenance cost nobody tells you about when you sell a WordPress site

аЛЕКС ЛИР — Wed, 29 Jul 2026 21:37:34 +0000

I've built and maintained 235+ WordPress sites over 18 years. Everyone talks about the build phase — the stack, the design, the launch. Almost nobody talks about what happens in month 14, when the client calls because the contact form stopped working and they have no idea why.

Here's what that side of the business actually looks like.

Plugins are a slow-motion liability, not a one-time decision. Every plugin you install is a future maintenance ticket. A contact form plugin updates, a caching plugin conflicts with it, and suddenly a site that "just worked" for a year breaks with zero code changes on your end. I've learned to treat every plugin add as a recurring cost, not a checkbox — fewer plugins, chosen for longevity over features, has saved me more support hours than any performance optimization.

Clients don't report bugs, they report symptoms. "The site looks weird" can mean a broken layout, an SSL cert expiring, a hosting outage, or their browser cache. Non-technical clients can't triage, so they won't — which means your intake process has to do the triage for them. A simple "what page, what device, screenshot" request up front cuts diagnosis time in half.

Hosting is where most "your website is broken" tickets actually live. Cheap shared hosting is the single biggest source of recurring client complaints I see — not code, not design, hosting. A site that's technically well-built on bad hosting still generates support tickets that feel like your fault. Vetting hosting up front is part of the deliverable, even if nobody puts it in the contract.

Scope creep on maintenance is worse than scope creep on builds. A build has a defined end date, so scope creep gets negotiated. Maintenance doesn't — "can you just also update this text" turns into unpaid ongoing work if you don't draw a line early. We now bundle a fixed number of monthly edits into any retainer, explicitly, so both sides know where "included" ends.

None of this is technically interesting. But if you're a developer thinking about freelance or small-agency work, the unglamorous truth is that post-launch support is where most of the actual friction — and actual margin — lives, not the build itself.

Why I still build client sites on WordPress + Elementor in 2026

аЛЕКС ЛИР — Mon, 27 Jul 2026 22:23:21 +0000

I run a small web studio — 18 years, 235+ projects, mostly local businesses. No custom stack, no framework flexing. Just Elementor and WordPress.

Here's why that's still the right call for most of my clients:

Speed over elegance. A landing page ships in 2–3 days, not 2–3 weeks. Nobody's paying for a bespoke component library on a 5-page site.

Handoff matters more than code quality. Clients need to edit their own content later. A page builder means I'm not the bottleneck for a text change six months down the line.

Transparent pricing filters better than good code. We publish price ranges by package instead of "contact for quote." It kills mismatched leads before the first call — someone who needs a $5k custom build doesn't waste time booking a consult for a $250 landing page.

"AI-written base copy" isn't a red flag anymore. We say it upfront, at scoping, not at delivery. Nobody expects hand-crafted copy on a budget landing page, and pretending otherwise just creates friction later when the client reviews drafts.

Custom code earns its place when a project needs real logic, integrations, or scale. Most small-business sites don't — and defaulting to the impressive stack regardless of the requirement is a mistake I made early on too.

Curious if other small shops are seeing the same shift, or still selling custom builds by default.

18 Years, 235+ Sites: What Running a Small WordPress Studio Actually Taught Me

аЛЕКС ЛИР — Thu, 23 Jul 2026 21:49:57 +0000

I run a small web development studio in Ukraine. We've shipped 235+ projects over 18 years — mostly WordPress sites, landing pages, and small e-commerce stores for local businesses. No VC funding, no SaaS growth chart, no "we scaled to 10M users" story. Just a lot of repeat, unglamorous client work.

I want to share what that work actually taught me, because a lot of it cuts against what gets upvoted on dev-focused platforms.

The stack doesn't matter as much as you think

I know Elementor gets side-eye from "real developers." Page builders are heavier than hand-rolled markup, they come with plugin dependencies you have to actively manage, and they're not what you'd reach for on a resume project.

But here's what they buy me on client work:

Fast turnaround. A landing page ships in 2–3 days instead of 2–3 weeks.
Client-editable handoff. Someone with zero dev background can update their own copy and images later, without filing a ticket with me.
Predictable cost. No custom component library to maintain for a client who needs five pages, total.

Custom code earns its place when a project genuinely needs it — complex business logic, third-party integrations, real scale. The mistake I see junior devs make (and one I made early on) is defaulting to the "impressive" stack regardless of whether the project needs it. Most local-business sites don't. Matching the tool to the actual requirement, before you touch a single line of config, has saved me more time than any framework migration ever has.

Pricing transparency filters leads better than good code does

Most agencies in this space hide pricing behind "contact us for a custom quote." We do the opposite — published price ranges by package, with what's included and how long each takes:

Package Range What it covers
Landing page $200–400 Single page, AI-assisted base copy, standard sections
Business site $400–800 Multi-page, custom copy edits, basic SEO setup
SEO-optimized site $800–1,500 Full on-page SEO, content strategy, analytics setup
Individual scope $1,500+ Custom requirements, integrations, ongoing support

It felt risky the first time we published this — competitors could undercut us on paper alone. In practice, it does something more valuable: it filters out mismatched leads before the first call. Someone who needs a $5,000 custom build doesn't waste our time or theirs booking a consult for a $250 landing page. That's not a marketing trick, it's just fewer bad-fit conversations per week.

Being upfront about AI-generated copy isn't a red flag anymore

Two or three years ago, telling a client "the base copy in this tier is AI-generated, and you'll edit it yourself" might've read as cutting corners. Now it's just accurate. Nobody realistically expects hand-crafted copywriting bundled into a $250 landing page. Naming that upfront — instead of quietly doing it and hoping nobody notices — removes friction later, when the client is reviewing drafts and wondering why the tone feels generic. Set the expectation at scoping, not at delivery.

Trust signals you don't control beat the ones you do

Every site has a testimonials section. Most of them are quotes the business itself selected and typeset, which readers correctly discount. What's worked better for us is linking out to review verification on a third-party freelance platform — reviews we don't get to curate or edit. It's a small structural choice, but it changes how much weight a skeptical visitor gives the social proof.

Unglamorous work still rewards getting the fundamentals right

None of the above is a technical breakthrough. But there's a pattern I keep noticing: a lot of developer discourse treats "boring" tech stacks and "unsexy" niches (small-business sites, local service companies) as not worth optimizing for. In practice, this space rewards the same fundamentals as any other kind of software work — clear scoping, honest communication about tradeoffs, fast and predictable delivery — just without the framework debates.

If you're a dev considering freelance or small-agency work on the side, my honest take: the technical bar is lower than you'd expect, and the business-judgment bar is higher. Knowing when not to reach for the impressive solution is the actual skill.

Happy to go deeper on any of this — pricing structure, when a page builder is genuinely the wrong call, or how we handle client handoff and maintenance long-term. Drop a comment.

Why I still build client sites on WordPress + Elementor in 2026

аЛЕКС ЛИР — Mon, 20 Jul 2026 20:53:32 +0000

I run a small web studio — 18 years, 235+ projects, mostly local businesses. No custom stack, no framework flexing. Just Elementor and WordPress.
Here's why that's still the right call for most of my clients:

Speed over elegance. A landing page ships in 2–3 days, not 2–3 weeks.
Handoff matters more than code quality. Clients edit their own content later — a page builder means I'm not the bottleneck.
Transparent pricing filters better than good code. We publish price ranges by package instead of "contact for quote."
"AI-written base copy" isn't a red flag anymore. We say it upfront.

Custom code earns its place when a project needs real logic or scale. Most small-business sites don't.
Curious if other small shops are seeing the same shift.

Why I still build client sites on WordPress + Elementor in 2026

аЛЕКС ЛИР — Sun, 19 Jul 2026 23:29:33 +0000

I run a small web studio — 18 years, 235+ projects, mostly local businesses. No custom stack, no framework flexing. Just Elementor and WordPress.

Here's why that's still the right call for most of my clients:

Speed over elegance. A landing page needs to ship in 2–3 days, not 2–3 weeks. Nobody's paying for a bespoke component library for a 5-page site.
Handoff matters more than code quality. Clients need to edit their own content later. A page builder means I'm not the bottleneck for a text change.
Transparent pricing filters better than good code. We publish price ranges by package instead of "contact for quote." It kills mismatched leads before the first call.
"AI-written base copy" isn't a red flag anymore. We say it upfront. Nobody expects hand-crafted copy on a budget landing page.

Custom code earns its place when a project actually needs logic, integrations, or scale. Most small-business sites don't — and pretending otherwise just burns time on both sides.

Curious if other small shops are seeing the same shift, or still selling custom builds by default.

What I learned running a small web studio for 18 years (and why I still don't code custom themes)

аЛЕКС ЛИР — Fri, 17 Jul 2026 19:45:28 +0000

I run a small web development studio in Ukraine. Over the years we've shipped 235+ projects — mostly WordPress sites, landing pages, and small e-commerce stores for local businesses. Nothing glamorous, no VC funding, no SaaS unicorn story. Just steady client work.

I want to share a few things that surprised me, because they go against a lot of what you read on dev-focused platforms.

Clients don't care about your stack

I know Elementor gets side-eye from "real developers." Fair enough — it's not the leanest way to ship a page, and it comes with plugin bloat you have to actively manage. But for a huge chunk of small-business clients, a page builder means:

I can hand off basic content edits without teaching them Git
Turnaround on a landing page is 2–3 days, not 2–3 weeks
I'm not maintaining a bespoke component library for a client who needs five pages, total

Custom code is the right call when the project actually needs it — complex logic, integrations, scale. Most local business sites don't. Knowing which bucket a project falls into, before you pick the stack, has saved me more time than any framework ever has.

Pricing transparency is a bigger differentiator than tech choices

Most agencies in this space hide pricing behind "contact us for a quote." We just... put price ranges on the site, by package, with what's included and how long it takes. It felt risky at first — competitors could undercut us on paper. In practice it filters out mismatched leads before the first call, which saves everyone time.

"AI-written base copy" is now a checkbox, not a red flag

We're upfront that our cheapest tier uses AI-generated placeholder copy that clients edit themselves. Two years ago that might've sounded lazy. Now it's just accurate — nobody expects hand-crafted copywriting for a $250 landing page, and pretending otherwise just creates friction later.

Verified reviews beat testimonials on your own site

We link out to a third-party freelance platform for review verification instead of only showing quotes we control. It's a small thing, but trust signals you don't own are worth more than the ones you do.

None of this is groundbreaking. But I think there's a quiet lesson in it for devs who assume "boring" tech and "unsexy" niches aren't worth optimizing for. There's a lot of unglamorous, repeatable value in getting the fundamentals — speed, honesty about scope, and a clean handoff — right, over and over.

Happy to answer questions about running a small dev shop long-term, or about when it actually makes sense to reach for a page builder vs. custom code.

AI in 2026: The Game Has Changed

аЛЕКС ЛИР — Thu, 16 Jul 2026 20:14:18 +0000

If 2023 was about hype, 2024 about experimentation, and 2025 about discovery, then 2026 is the year AI stopped being a novelty and became infrastructure.

The conversation has shifted. We're no longer asking "what can AI do?" — we're asking "how do we deploy it at scale?" The numbers tell the story: automated traffic now accounts for more than 50% of all Internet traffic globally, and global AI spending is forecast to exceed $2 trillion in 2026. This isn't experimentation anymore. This is the new reality.

Here's what's actually changing the game right now.

Agentic AI: From Tools to Teammates 2025 was the year we learned about agentic AI. 2026 is the year we put it to work.

Instead of one-shot prompts and isolated tools, we now have agentic workflows — systems that plan, execute, reflect, and adapt. They handle multi-step tasks, maintain persistent memory, and self-check their own work. The share of organizations using AI agents rose to 21% in 2025 from 10% in 2024, and in 2026, that number is climbing fast.

For developers, this means moving from "AI as a copilot" to "AI as a teammate that actually gets things done". The focus is no longer on isolated agents but on orchestration — making multiple agents work together seamlessly.

Physical AI: Stepping Out of the Screen AI is no longer confined to text and code. It's entering the physical world.

Physical AI — robots, drones, and intelligent infrastructure — is reshaping industries from manufacturing to logistics. NVIDIA's Cosmos platform, trained on 20 million hours of robotics data, now enables robots to generalize to new situations without specific reprogramming for each use case. Gartner predicts that by 2028, physical AI will automate up to 50% of manual tasks in industrial environments.

This isn't sci-fi. This is happening now. And the developer skillset is expanding accordingly — understanding not just software, but how AI interacts with hardware and the real world.

Domain-Specific Models: Smaller, Smarter, Cheaper The era of "one giant model fits all" is ending. In 2026, the focus has shifted to domain-specific models — smaller, fine-tuned systems that outperform generalist LLMs in their specific domains.

Why? Because they're:

Faster and cheaper to run

Easier to deploy at the edge

More accurate for specialized tasks

Gartner predicts that by 2030, 90% of GenAI-enabled solutions will use domain-specific models. For developers, this means building with SLMs (Small Language Models) that run on-device, reducing API costs and latency.

The Global Divide: Winners and Losers AI is reshaping not just industries, but global power itself. The countries and companies that control compute, chips, cloud infrastructure, and talent will increasingly shape who gets heard and who gets to build the future.

But here's the catch: just 32 countries have AI-specialized data centres. Developing countries are home to half the world's internet users but less than 10% of global data centre capacity. The ILO and World Bank warn that many developing economies risk experiencing disruption from GenAI before seeing any benefits.

The game is changing for everyone — but not everyone is playing on the same field.

What This Means for Developers The message for 2026 is clear: pragmatic progress over hype.

Master context engineering — what the model sees matters more than the model itself. Build with agents in mind — design for multi-step workflows and feedback loops. Optimize for cost and speed — fine-tuned small models often outperform large ones in production.

And most importantly: treat AI as a capable teammate, not a magic wand.

The Bottom Line
AI in 2026 isn't about chasing the next breakthrough. It's about integration, scale, and real-world impact. The technology is mature enough to be infrastructure — and the developers who understand how to build with it, not just on it, will define the next decade.

The game has changed. Are you ready?