Skip to Content

Stephen Quick

20 posts

Posts by Stephen Quick

Stop Putting QR Codes in Emails. Seriously.

A QR code is a bridge. That's it. It connects the physical world to the digital one.

You're holding a door hanger. You see a QR code. You pull out your phone, scan it, and now you're on a website. That's the magic. You went from a piece of paper in your hand to a landing page in seconds. No typing a URL. No searching. Just scan and go.

That's what QR codes were designed to do. And somehow, we've managed to completely overthink them.

You're Already on the Internet

Here's where it falls apart. I see QR codes in emails. I see them in Facebook posts. I see them on websites.

Think about that for a second.

You're looking at a screen. You're already on the internet. You're already on a device that can click a link. Why would you pull out a second device to scan a code that takes you to a place you could reach with one tap?

You wouldn't. Nobody does.

A QR code in an email is like putting a stamp on a text message. It doesn't make sense because you're already in the medium it's trying to connect you to.

Where QR Codes Actually Work

QR codes shine when there's no link to click. When someone is holding something in their hands or looking at something in the real world.

Door hangers. A contractor leaves one on a doorknob after finishing a job in the neighborhood. The homeowner picks it up, scans the code, and they're looking at a page with reviews, a scheduling form, or a seasonal offer. That's a real use case.

Direct mail. A postcard hits the mailbox with a clear call to action and a QR code. One scan and they're on your site. No remembering a URL. No Googling your company name and hoping they find the right one.

Business cards. You meet someone, hand them a card, and the QR code takes them straight to your portfolio or contact page. Simple.

Yard signs. You just finished a roof install. The sign in the yard has a QR code. A curious neighbor walks by, scans it, and now they're looking at your work and your number.

Trade show booths. Someone's walking the floor. They don't want to carry a stack of brochures. A quick scan saves your info to their phone. Done.

Vehicle wraps. Your truck is parked at a job site. Someone sees it, scans the code on the tailgate, and now they're on your site. That's physical to digital working exactly the way it should.

The pattern is the same every time. Someone is in the physical world. They don't have a clickable link. The QR code gives them one.

The Exception: Large Public Displays

There's one digital use case that actually makes sense. Big screens.

If you're presenting at a conference and you want the audience to hit a URL, a QR code on your slide works. The screen is across the room. Nobody is going to type out a link from their seat. Same idea with a TV display in a waiting room or a digital billboard.

The key is distance. If the screen is far enough away that people can't interact with it directly, a QR code bridges that gap. It's still solving the same problem: getting someone from where they are to where you want them to go.

But that Facebook post someone is scrolling on their phone? They're already there. Just give them a link.

Keep It Simple

I've been building websites and digital marketing for contractors for over 25 years. The best tools are the ones that solve a real problem in the simplest way possible.

QR codes solve a real problem. They turn a physical moment into a digital connection. But only when there's actually a gap to bridge.

If your audience is already online, give them a link. If they're holding a piece of paper, standing in front of a sign, or sitting in a room looking at a screen they can't touch, give them a QR code.

That's it. Don't overthink it. Use the right tool for the right job.

Stop Creating Edge Cases. Start Solving Them.

I've been building software for over 25 years. In that time, I've seen the same mistake play out hundreds of different ways. It always starts the same. Someone looks at a pattern that works and says, "Yeah, but what if we just..."

That's where it breaks.

Patterns Exist for a Reason

Software patterns aren't suggestions. They're agreements. When your team follows them, everyone knows where things live, how data flows, and what to expect when they open a file they didn't write. When someone breaks the pattern, they're not just writing bad code. They're breaking that agreement with every person who touches the system after them.

I don't care if you're writing PHP, JavaScript, Python, or anything else. The stack doesn't matter. What matters is discipline. The language you chose has conventions. The framework you picked has opinions. Your team built patterns on top of those for a reason. Respect them.

The moment you start deviating from the rules, you lose sight of the software as a whole. You stop seeing the system and start seeing your little corner of it. That's a problem.

We Run Multi-Tenant. The Rules Aren't Optional.

At Red Barn, we run multi-tenant databases. That means multiple clients share infrastructure. Their data is isolated, but the logic that serves them is shared. This only works when every piece of the application follows the same patterns.

One shortcut in a multi-tenant system doesn't just affect one client. It affects all of them. A query that skips the tenant scope? That's not a bug. That's a data breach waiting to happen. A controller that handles one client differently because someone thought they were "solving a problem"? That's technical debt that compounds every single day.

When you operate at this level, the patterns are the product. Break them and it doesn't matter how clever your solution is. You've introduced risk into a system that was designed to eliminate it.

Solve for Edge Cases. Don't Create Them.

Here's the thing most developers get wrong. They encounter a situation that doesn't fit neatly into the existing pattern, and instead of finding a way to handle it within the system, they build around it. They create a one-off. A special case. A hack with a comment that says "TODO: fix this later."

Later never comes. And now you have an edge case that didn't exist before you wrote that code.

Good software engineering means solving for edge cases, not creating them. When you find something that doesn't fit, the answer isn't to abandon the pattern. The answer is to extend the pattern so it handles the new scenario. That's how systems get stronger over time instead of more fragile.

Think of it this way. If your pattern can't handle the edge case, either the edge case is telling you something about your pattern that needs to improve, or the edge case isn't as special as you think it is.

Nine times out of ten, it's the second one.

The Stack Doesn't Save You

I've watched teams argue for weeks about which framework to use, which database to pick, which deployment pipeline to build. Then they get into the work and throw every convention out the window by month two.

It doesn't matter if you're running the most modern stack on the planet. If your team doesn't follow patterns, you're building a mess. A mess in React is still a mess. A mess in Laravel is still a mess. A mess in whatever the new hotness is this week? Still a mess.

The technology is a tool. The discipline is the craft.

What Consistency Actually Looks Like

Consistency means when a new developer joins your team, they can open any part of the codebase and know what they're looking at. It means when a bug shows up at 2 AM, you know where to look because the system is predictable. It means your multi-tenant architecture actually works because every query, every controller, every service follows the same rules.

It's not glamorous. Nobody gives conference talks about following conventions. But the teams that ship reliable software? They're the ones that decided the pattern matters more than the individual developer's preference.

Keep It Simple

I've said it a thousand times and I'll say it again. Keep it simple, make it look beautiful, and have it work.

Patterns are simplicity at scale. They're how a team of people builds one thing instead of ten different things duct-taped together. They're how you look at a codebase after five years and still understand what's going on.

Every time you deviate from the pattern, you're adding complexity. Not the useful kind. The kind that makes your system harder to understand, harder to maintain, and harder to trust.

So before you write that one-off, before you "just this once" your way around the convention, ask yourself one question.

Am I solving an edge case, or am I creating one?

The answer matters more than you think.

Red Barn Media Group Named #29 on the 2026 Inc. Regionals Northeast List

Red Barn Media Group has been ranked #29 on Inc. Magazine's 2026 Regionals Northeast list, a ranking of the 151 fastest-growing private companies across nine northeastern states.

We're one of only two Vermont-based companies on the entire list.

The Inc. Regionals list measures percentage revenue growth over a two-year period, from 2022 to 2024. Companies on this year's Northeast list had a median growth rate of 73 percent and collectively added 6,779 jobs and $2.3 billion to the regional economy. To qualify, companies had to be privately held, for-profit, U.S.-based, and independent, with at least $1 million in 2024 revenue.

What This Means

Rankings are great. We're not going to pretend otherwise. But what matters more is what the ranking represents.

Red Barn Media Group has been doing this work since 1998. We started building websites for the HVAC and mechanical trades out of a carriage barn in Vermont. Over the past 25+ years we've grown into a full-service digital marketing agency serving home service contractors across the United States and Canada.

We build websites. We run SEO campaigns. We manage paid advertising, Google Business Profiles, and Local Services Ads. We coach contractors on how to grow their businesses. That's what we do. Every day. For over 500 clients.

The growth that earned us a spot on this list didn't come from a pivot or a rebrand or a new funding round. It came from doing the same thing we've always done, doing it better each year, and earning the trust of more contractors who need real results from their marketing.

Why Home Services

We've been asked plenty of times why we only work with contractors. The answer is simple: we understand the business.

When an HVAC contractor tells us they need more calls in July for AC installs, we know exactly what that means operationally. When a plumber needs to rank in three adjacent markets, we know the SEO strategy that gets them there. When a roofer wants to scale from $2 million to $5 million, we've helped others do exactly that.

Specialization isn't a limitation. It's what makes us effective. Our clients don't have to explain their industry to us. They tell us their goals and we build a plan that works.

The Numbers

Here's what 25+ years of focused work looks like:

  • 500+ contractors served across the US and Canada
  • 1,650,000+ leads generated for our clients
  • 98% client retention rate
  • 7 OEM manufacturer partnerships
  • 25+ years in the home services industry

Those numbers are built one relationship at a time. One website at a time. One campaign at a time.

The Team Behind the Growth

This recognition belongs to the entire Red Barn Media Group team. The developers, designers, account managers, and marketing specialists who show up every day and do the work. Growth like this doesn't happen because of one person or one decision. It happens because a group of people care about what they're building and who they're building it for.

It also belongs to our clients. Contractors who trusted a Vermont-based agency to help them grow their businesses. That trust is something we take seriously.

What's Next

The same thing we've been doing. Building great websites. Running effective campaigns. Helping contractors grow. We're not changing the formula. We're just getting better at it.

If you're a home service contractor looking for a marketing partner that actually understands your business, let's talk.

View the full Inc. Regionals Northeast list: inc.com/regionals/northeast

Learn more about Red Barn Media Group: redbarnmg.com

Google's TurboQuant: Why AI Compression Matters for You

I read a lot of AI research. Most of it is interesting to the people writing it and nobody else. But every once in a while, something comes along that has real implications for the rest of us.

Google Research just published a paper on a set of compression algorithms called TurboQuant. The short version: they figured out how to shrink the memory that AI models need by 6x or more, without losing accuracy, and without retraining the model. On the right hardware, it runs up to 8x faster too.

If you run a home services company or any small business using AI tools, you probably don't care about the math. You shouldn't have to. But the outcome of this research will affect what you pay for AI and how well it works. So let me break it down.

The Problem: AI Is Expensive Because It Has a Memory Problem

When a large language model (like ChatGPT, Gemini, or Claude) processes your request, it keeps a running memory of everything it's working with. This is called the key-value cache. Think of it like a contractor keeping every single note, measurement, and material spec on their clipboard while they're on a job site. It works, but the clipboard gets heavy fast.

That memory lives on expensive GPU hardware. The more memory required, the more hardware required, the higher the cost. That cost gets passed down to you, whether you're paying per API call or using a subscription product.

What TurboQuant Actually Does

TurboQuant compresses that memory. Instead of storing each number at full precision (32 bits), it gets them down to 3 or 4 bits. That's a massive reduction.

The clever part is how they do it. Most compression methods need to store extra information (overhead) to keep things accurate. TurboQuant eliminates that overhead by converting the data into polar coordinates and using a 1-bit error correction technique. The result is a compression method that takes up almost no extra space and introduces almost no error.

In their benchmarks, TurboQuant matched or beat every other method across question answering, code generation, and summarization tasks. At 3 bits per number, it performed the same as the uncompressed model. Zero accuracy loss.

Why This Matters Outside the Lab

I've spent years in web development and digital marketing for home service contractors. I've watched the gap between enterprise technology and small business technology shrink over and over again. First it was websites. Then mobile. Then marketing automation. Now it's AI.

Every time the underlying technology gets cheaper to run, small businesses gain access to tools that were previously out of reach. That's what compression breakthroughs like TurboQuant enable.

Right now, if you want an AI-powered chatbot on your HVAC company's website, you're paying for every API call. If you want AI to help generate service descriptions, ad copy, or customer communications, there's a cost per interaction. When models run on less memory and process faster, that cost drops.

This also matters for search. TurboQuant dramatically speeds up vector search, which is the technology behind semantic search engines. When Google can run these lookups faster and cheaper, that improves the search infrastructure that every business depends on for customer acquisition.

My Take

I've always believed the best technology is simple, beautiful, and works. TurboQuant is a good example of that principle applied to hard math. They didn't add complexity. They found a more elegant representation of the same data. They used a known mathematical transform (polar coordinates) and a lightweight error correction technique to eliminate the overhead that every other method carries.

That's not over-engineering. That's good engineering.

We're at a point where AI research is advancing fast enough that the practical benefits are reaching real businesses within months, not years. For anyone in home services, trades, or small business, the takeaway is straightforward: the AI tools you use today are going to get better, faster, and cheaper. Not because of hype. Because of work like this.

Keep building. Keep paying attention. The fundamentals haven't changed. But the tools keep getting sharper.

Read the full Google Research post here: https://research.google/blog/turboquant-redefining-ai-efficiency-with-extreme-compression/

Stop Hiding Behind the Acronyms

Every industry has its own language. That’s fine. Specialized work needs specialized words sometimes.

But there’s a difference between using shorthand because it’s efficient and using it because it’s become a habit nobody questions anymore. A habit that ends up putting distance between people who should be on the same page.

Marketing does this. Tech does this. And if you’ve been on the receiving end of either, you’ve felt it. That moment where someone rattles off a string of letters and you nod along because you don’t want to be the one who asks what it means. We’ve all been there.

I’ve spent over 25 years building websites and digital marketing for home service contractors. HVAC companies, plumbers, electricians, roofers. People who do real work with their hands. And one of the most consistent problems I’ve seen across this entire industry is the gap between what people say they’re doing and what’s actually happening. Abbreviations make that gap wider than it needs to be.

The Marketing Version

You’re a contractor. You’ve been running your business for fifteen years. You’re great at what you do. But you need more leads, so you hire a marketing agency.

First month goes by. They send you a report. It’s a PDF, maybe a dashboard link. It’s full of KPIs and CTRs and CPAs and ROAS and MQLs. There are colored charts. Trend lines. A section about “organic impressions” and another about “engagement metrics.” Everything looks very professional.

You read it twice. You still don’t know if it’s working.

That’s a communication problem. And it happens all the time.

Here’s what’s going on. When someone tells you your CPC is down 12% but your CPA is up, what are they really saying? They’re saying people are clicking your ads for less money, but it’s costing you more to actually get a customer. That’s a problem. That should be a conversation. But wrapped in abbreviations, it sounds like a mixed bag instead of a red flag. It sounds like progress with a caveat, not a strategy that needs fixing.

I’ve been in digital marketing my entire career. I’ve seen reports that lean on acronyms so heavily that the actual performance gets lost in the noise. Not because anyone is trying to be misleading. But because the language we use in this industry has drifted so far from plain English that even the people writing the reports don’t always stop to think about whether the person reading it can follow along.

An agency might describe their work as running PPC campaigns optimized for ROAS with A/B testing across multiple CTA variants to improve CVR. That sounds like a lot of work. It sounds expensive. But what they actually said is: “We’re running ads and testing which button gets more clicks.” That’s it. That’s the whole thing. The work isn’t any less valuable in plain language. It’s just easier to understand.

Here’s what a contractor actually needs to know: Did the phone ring? Did those calls turn into jobs? Did we make money? Are we doing better this month than last month? What are you changing to improve it?

You don’t need a glossary for that. You need a partner who respects you enough to talk straight.

Tech Does the Exact Same Thing

Developers are just as deep in it. Maybe deeper.

You sit in a meeting and someone says they’re building a microservices architecture with a CI/CD pipeline, containerized with K8s, running a LAMP stack but migrating to MEAN with SSR and ISR.

You nod. You leave the meeting. You have no idea what just happened.

And here’s the thing. Half the time, the people saying it couldn’t always tell you why they chose that stack over something simpler. They know the acronyms. They can define them if you put them on the spot. But the decision wasn’t always driven by the project’s needs. It was driven by what’s trending. What the last conference talk recommended. What everyone else is talking about.

I’ve been writing code since 1999. PHP, HTML, JavaScript. The fundamentals. The stuff that actually renders the page in someone’s browser. And I can tell you that a lot of the complexity people bolt onto projects isn’t solving a problem. It’s just complexity for the sake of it.

A website that loads fast, looks clean, and converts visitors into customers doesn’t need twelve layers of abstraction. It needs someone who understands the basics and builds with intention. A solid LAMP stack, clean code, and smart architecture will outperform an over-engineered mess every single time. Not because it’s fancier. Because it works. Because someone can maintain it. Because when something breaks at 2 AM, you don’t need a team of six specialists to figure out which container went down.

Just Be Honest

I know that sounds like something you’d read on a motivational poster. But I mean it in a very specific way.

When you’re working with a client, you have two choices. You can talk to them in a way that makes you sound smart. Or you can talk to them in a way that makes them feel smart. One of those builds trust. The other one builds dependency.

I’ve been in this business long enough to know which one works. The agencies that last, the developers that keep clients for a decade, the companies that grow through referrals instead of ad spend, they all have one thing in common. They talk straight. They communicate in plain language when things are going well, and they do the same when things aren’t.

Honesty is harder than jargon. It takes more effort. If an SEO campaign isn’t producing results yet, it’s easier to send a report full of acronyms that show movement than it is to pick up the phone and say, “Here’s where we are, here’s why it’s taking longer than we expected, and here’s what we’re doing about it.” But that phone call is worth more than a hundred dashboards. Because after that conversation, the client trusts you. They know you’re paying attention. They know what’s going on.

The same goes for tech. If a build is behind schedule, don’t bury it in a status update full of technical shorthand. Say it plain. “We hit a problem. Here’s what it is. Here’s how we’re fixing it. Here’s the new timeline.” That’s it. No acronyms needed.

People can handle the truth. What they can’t handle is the feeling that they’re not really in the loop. And abbreviations, even when nobody means for them to, can create exactly that feeling.

Start With the Goal, Not the Method

Here’s where I think a lot of agencies and developers go wrong. They lead with how they do things instead of why.

A contractor doesn’t call a marketing agency because they want a LAMP stack. They call because they want the phone to ring. They want more jobs on the schedule. They want to grow their business. That’s the goal. Everything else is in service of that goal.

But somewhere along the way, our industry started leading with the method. Proposals are full of technology descriptions and process breakdowns and platform names. The goal gets buried under the approach. And the client ends up evaluating things they don’t understand instead of measuring things they care about.

I think about this a lot. The best first conversations I’ve had with clients aren’t about what’s going to be built. They’re about what the client is trying to accomplish. How many jobs do you want on the books each month? What kind of jobs? What’s your service area? Where are you losing customers right now? What does growth look like for you in two years?

Those are goal conversations. And once you’ve had them, the technology part gets a lot simpler. Because now every decision has a reason behind it. You’re building it this way because it gets the client closer to that number. You’re running this campaign because it targets the customers they actually want. No abbreviations necessary. Just a clear line from the work to why it matters for the business.

When you flip it around and lead with the method, you lose people. You lose them in the first meeting. And then you spend the rest of the engagement trying to justify the work with metrics they don’t understand instead of results they can feel.

How to Actually Communicate

I’ve been managing projects and leading teams for a long time. And the single biggest lesson I’ve learned about communication is this: the person listening gets to decide if you were clear. Not you.

You can explain something perfectly in your own head. You can use all the right terms. You can be technically accurate. And the person on the other end can still walk away confused. If that happens, you didn’t communicate. You just talked.

Good communication in this industry means meeting people where they are. If you’re talking to an HVAC contractor, talk about calls and jobs and revenue. If you’re talking to a developer, sure, use the shorthand. Context matters. But when in doubt, go simpler. Nobody ever lost a client because they were too easy to understand.

Here’s what I’ve found works. Start with the outcome. “Here’s what we’re trying to do.” Then explain the approach in plain language. “Here’s how we’re going to get there.” Then set expectations. “Here’s what you’ll see along the way, and here’s how long it should take.” Then check in. “Does that make sense? Do you have questions?”

That’s a conversation. That’s a partnership. There are zero acronyms in that framework and it works for every single client interaction I’ve ever had.

The other piece of this is listening. A lot of people in marketing and tech are so focused on sounding knowledgeable that they forget to listen. Your client is telling you what they need. Usually in plain language. Usually in very clear terms. “I need more calls.” “My website looks outdated.” “I’m losing customers to the company down the road.” Those are the goals. Your job is to hear them, confirm them, and then go solve them. Not to translate them into acronyms and sell them back.

If a client has to ask what something means, that’s a signal. It means the communication needs to be better. The work might be great. But if the client can’t tell, it doesn’t matter.

Why This Happens

It’s the same reason in both industries. Abbreviations create distance between the person doing the work and the person paying for it.

Most of the time, it’s not intentional. It’s just what happens when people spend all day talking to others in their field. You forget that the rest of the world doesn’t speak the same language. Acronyms become automatic. You stop thinking about whether the person across the table knows what REST API means because everyone you talked to this week knew what it meant.

Over time, it becomes the default. People use shorthand without asking whether their audience follows. The language itself becomes a barrier. And nobody stops to question it because it’s just how the industry communicates.

But the result is the same whether it’s intentional or not. The person writing the check doesn’t fully understand what they’re getting. And that’s a problem worth solving.

It’s Worse Now With AI

I have to say it. AI has added a whole new layer to this.

Now you’ve got marketers throwing around acronyms like LLM, NLP, RAG, and GPT in their pitches. “We’re using AI-powered NLP to optimize your content strategy with RAG-based insights.” That sounds incredible. It sounds like the future just showed up to your marketing meeting.

But what does it actually mean? Sometimes it means they’re using ChatGPT to write your blog posts. That’s it. They’re typing a prompt into a chatbot and copying the output onto your website. Which is fine if that’s what you agreed to and what you’re paying for. But it’s not what “AI-powered NLP content optimization” sounds like. It sounds like a million-dollar operation. It’s a ten-dollar-a-month subscription.

On the tech side, it’s the same story. AI can generate code faster than ever. But someone still has to understand what got built. And the abbreviations around AI tools and frameworks are multiplying faster than anyone can keep up. The terminology is outpacing the understanding, and that gap creates confusion for everyone involved.

Writing code was never the bottleneck. The real skill has always been comprehension. Building mental models. Understanding how systems connect. Knowing what breaks when something changes. AI didn’t make that skill less important. It made it essential. And abbreviations don’t help anyone develop that understanding. They just paper over the gap.

They Don’t Know the Terms. They Know the Work.

Here’s something I think a lot of people in marketing and tech forget. Your clients aren’t stupid. They’re just in a different field.

A contractor who’s been running an HVAC business for twenty years understands more about customer acquisition than most marketers will ever learn. They know what makes a homeowner pick up the phone. They know what builds trust in a service call. They know how word of mouth works, how reputation works, how showing up on time and doing clean work turns one job into ten. They understand the technique. They live it every day.

And let’s be real about something. I don’t know their business the way they do. Not even close. I’ve worked with HVAC contractors for over two decades and I still couldn’t walk into a mechanical room and tell you which blower goes with which system. I couldn’t look at a compressor and diagnose what’s wrong with it. I couldn’t tell you the difference between a two-stage furnace and a modulating furnace off the top of my head the way a tech who’s been in the field for ten years can. I don’t know the refrigerant pressures. I don’t know the ductwork calculations. I don’t know which manufacturer’s parts are reliable and which ones fail after two seasons.

They do. That’s their world. They’ve spent years, sometimes decades, mastering it. They went through training, earned certifications, worked under guys who taught them the craft. They can walk into a house and listen to an air handler for five seconds and know what’s wrong. That’s expertise. Real expertise.

So when someone from marketing or tech walks into a room and starts rattling off acronyms to a contractor, think about what that looks like from the other side. Here’s a person who couldn’t change a capacitor talking about AI-driven programmatic SEM. The contractor lives in a world where you either know what you’re doing or you don’t. Where the work speaks for itself. Where a system either heats the house or it doesn’t. There’s no jargon that can cover up a bad install.

That’s the standard we should hold ourselves to. The same clarity. The same accountability. Results you can point to and explain in plain language.

What they don’t know is the terminology. They don’t know that what they’ve been doing with their Google Business Profile is called “local SEO.” They don’t know that the reason their competitor shows up first in search results has to do with backlinks and domain authority. They don’t know that the email they send after every job is technically an “automated post-service nurture sequence.”

But they know it works. They’ve been doing it. They just didn’t have the vocabulary.

And that’s where we come in. Not to talk over their heads. Our job is to meet them where they are and teach them. Let them learn. Give them the understanding, not just the acronyms.

When you sit down with a contractor and explain what’s happening with their website, you don’t need to start with the technology. Start with what they already know. “You know how when someone searches for ‘AC repair near me,’ you want your company to show up first? Here’s what determines that. Here’s what’s being done to make it happen. Here’s how you’ll know it’s working.” That’s teaching. That’s bringing someone in instead of leaving them on the outside.

And you know what happens when you teach a client instead of talking past them? They become better partners. They start asking sharper questions. They notice things on their own. They send you ideas. They understand the reports because someone took the time to walk them through what the numbers actually mean.

I’ve had contractors come back months into a project and say things like, “I think our bounce rate is high on the service page. Can we look at that?” That’s a client who learned something. That’s a client who’s engaged. That didn’t happen because someone threw jargon at them. It happened because someone took the time to explain what bounce rate means and why it matters for their business.

The opposite approach, the one where the client stays in the dark and the abbreviations do the talking, that creates dependence. Not partnership. The client doesn’t learn anything. They just write checks and hope it’s working. And when they eventually move on, they’re no better off than when they started. They still don’t understand what was done for them. They can’t evaluate the next agency any better than they evaluated the last one.

The trades have always been about learning by doing. An apprentice works alongside a journeyman. They watch. They ask questions. They try things. They make mistakes. Eventually they understand the craft. That’s how knowledge gets passed down.

We should be doing the same thing with our clients. Sharing the knowledge. Teaching the technique. Letting people learn. That’s how you build relationships that last. That’s how you build a business that means something.

What Contractors Should Ask

Since most of the people I work with are contractors and home service professionals, let me be specific.

If your marketing agency sends you a report full of abbreviations, ask them to walk you through it. Every line. Not because you’re not smart enough to figure it out. Because clear communication is part of the job. And if they can’t explain what they’re doing in plain language, that’s worth paying attention to.

Here are some questions that cut right through the acronyms:

How many calls did we get this month? How many of those turned into booked jobs? How much did we spend to get each of those jobs? Is that number going up or down? What are you changing next month and why?

That’s it. Those five questions will tell you more about your marketing than any dashboard full of three-letter metrics ever will.

On the tech side, if someone is building you a website or an app, ask the same kinds of questions. What does it do? Why did you build it this way instead of a simpler way? What happens when something breaks? Can I update it myself, or do I need to call you every time? How long will this last before it needs to be rebuilt?

If the answers come back in plain English, you found a good partner. If the answers come back in more abbreviations, keep asking questions until they do.

What I Think We Should Do Instead

Talk to people like people.

If you’re a marketer, tell your client: “More people saw your ad this month, but fewer of them called. Here’s what we’re changing and why we think it’ll work.” That’s a conversation. That’s useful. That builds trust.

If you’re a developer, tell your team lead: “We’re going to build the site so it loads faster and is easier to update without breaking things.” You don’t need to say “headless CMS with static site generation and edge caching.” Not unless they ask. And if they do ask, explain what those things mean. Don’t just define them. Explain why they matter for this project.

If you’re writing a proposal, read it out loud. If you wouldn’t say it to someone at a barbecue, rewrite it. Your proposals should sound like a person talking, not a textbook.

If you’re setting goals with a client, put them in writing. In plain language. “We want to increase your monthly calls by 20% over the next six months.” That’s a goal everyone can measure. Everyone can understand it. And when you check in next month, there’s no confusion. Either the number went up or it didn’t.

The best work I’ve done in 25 years has always been the simplest to explain. If I can’t tell a contractor what I built and why it matters in plain English, I didn’t do my job. That’s the standard. That should be everyone’s standard.

The Real Test

Here’s how you know if someone’s using abbreviations to be efficient or if the language is getting in the way.

Ask them to explain it without the acronym.

If they can, and it still makes sense, and the work still sounds valuable once you strip away the jargon, you’re in good hands. That person knows what they’re doing and they’re using shorthand because it saves time, not because it fills space.

If they stumble, or if the explanation sounds a lot less impressive in plain language, pay attention to that. That gap between the jargon and the reality is where confusion lives. It’s where projects go sideways. It’s where trust starts to erode.

I’ve been doing this for over 25 years. I’ve watched the acronyms multiply. Every year there are more of them. And the lesson is always the same.

Keep it simple. Make it look beautiful. Have it work. And if someone can’t explain what they’re doing for you without a decoder ring, keep asking until they can.

I Found My First Website on a Zip Disk. It Made Me Think About Everything That's Changed.

I Found My First Website on a Zip Disk. It Made Me Think About Everything That's Changed.

Today I found my first website on a Zip disk.

Well, probably. I can't actually open it.

We're in the middle of a move right now. Boxes everywhere. That phase where you're pulling things out of closets and drawers that haven't been touched in years. And buried in one of those boxes was a Zip disk from my Champlain College days. Labeled in my handwriting.

This thing almost certainly has my final project on it. My first real website. Built in Dreamweaver with image maps and tables, because that's how we did it in 1999.

And I have no way to see it.

No drive. No adapter. Just a plastic square holding a snapshot of who I was twenty-six years ago when I was just figuring all of this out.

I stood there holding it for a while. Longer than I should have. Moving makes you do that. Every box is a decision about what still matters. But this one hit different. Because the thing on that disk? I'm still doing it. I never stopped.

Twenty-six years. Same craft. Completely different world.

That disk got me thinking about all of it. Everything that changed. Everything that didn't. And whether we've actually been moving in the right direction this whole time.

1999 Was a Different Planet

Let me set the scene for anyone who wasn't there.

In 1999, most people were still on dial-up. 56k if you were lucky. You designed websites for 800x600 screens. Maybe 1024x768 if you were feeling ambitious. You tested in Netscape Navigator and Internet Explorer 4 and hoped for the best.

There was no CSS layout. Not really. If you wanted to control where things went on a page, you used tables. Not data tables. Layout tables. You'd take your design, slice it up in Photoshop or Fireworks, export the pieces as images, and reassemble them inside a grid of table cells. That was the job.

Image maps were a big deal. You could take one graphic and define clickable regions on it using coordinates. It was like building a puzzle that people could interact with. You'd map out rectangles and polygons by hand. If someone resized their browser, the whole thing broke. But it felt cutting edge.

Dreamweaver was how a lot of us built things. WYSIWYG editing. You could see what you were making while you were making it. Drag and drop. Visual layout. It generated the code for you. And that code was absolutely terrible. But it worked. And more importantly, it let people start building without needing to understand every tag and attribute first.

The Tools That Shaped Us

But HTML and Dreamweaver were only part of the picture. If you really want to understand 1999, you have to talk about Flash and Director.

Macromedia Director was a powerhouse. Before the web as we know it existed, Director was how people built interactive multimedia. CD-ROMs. Kiosks. Presentations. It had its own scripting language called Lingo, and it could export to Shockwave for the web. Director was doing interactive content before most people even had a browser installed. It was heavy, it was complex, and it was incredible for its time.

Then there was Flash. And Flash changed everything.

HTML in 1999 couldn't animate. It couldn't do smooth transitions. It couldn't play audio or video without a prayer and a plugin. Flash could do all of that. Splash pages with animated intros. Interactive navigation. Games. Entire websites built as a single .swf file. It was the closest thing we had to a rich application experience on the web.

Flash had its own language too. ActionScript. And this is where things get interesting. ActionScript was one of the first times a lot of web designers encountered real programming. Variables. Functions. Conditionals. Event handlers. It was based on ECMAScript, which means it was a cousin of JavaScript. A lot of people who eventually became serious developers cut their teeth on ActionScript inside Flash. It was a gateway into thinking programmatically.

JavaScript existed in 1999, but it was a different animal. You used it to validate forms. Maybe swap an image on hover. Write a little status bar message that scrolled across the bottom of the browser. Nobody was building applications with it. Nobody was even thinking about that. It was a scripting language. A utility. Something you sprinkled on top of HTML when you needed a little interactivity.

The idea that JavaScript would eventually replace Flash, power entire application frameworks, and become the most widely used programming language in the world? Nobody saw that coming. Not even close.

And then there was PHP.

PHP in 1999 was barely PHP. It was a template engine. That's literally what it stood for at first. Personal Home Page. You had an HTML file and you could drop in little blocks of dynamic content. Pull a date. Show a visitor counter. Maybe connect to a MySQL database and display some records. It wasn't a programming language the way we think about programming languages today. It was glue. It was a way to make static pages slightly less static.

But here's what made PHP matter. You could learn it in a weekend. You could write it right inside your HTML. You didn't need a compiler. You didn't need a framework. You uploaded a .php file to a shared hosting account and it just worked. The barrier to entry was almost nothing.

Sound familiar? That's the same thing that made Dreamweaver matter. And Flash. And Director. The tools that shaped that era all had one thing in common. They let people start building without requiring a computer science degree first.

That's the part I think we've lost sight of.

The Barrier to Entry Used to Be Low

Back then, you could go from zero to a published website in an afternoon. You didn't need to install Node. You didn't need a package manager. There was no build step. No webpack. No transpiling. You opened a program, you made something, you uploaded it to a server with FTP, and it was live.

Was the code good? No. It was terrible. Table layouts are a hack. Inline styles are a maintenance nightmare. Font tags should have been a crime. But people were making things. Regular people. People who didn't call themselves developers. People who just had an idea and wanted to put it on the internet.

The web was supposed to be for everyone. That was the whole point. Anyone could view source, see how something was made, and learn from it. You could right-click, look at the HTML, and understand the building blocks of what you were seeing.

Try doing that on a modern website. View source on most pages today and you'll see minified JavaScript that no human can read. The building blocks are buried under layers of abstraction. We didn't just raise the barrier to entry. We built a wall around it.

What Actually Changed (And What Didn't)

Here's the thing. The web itself hasn't changed that much. At its core, it's still the same technology. A browser requests a document. The server sends back HTML. The browser renders it. That's it. That's the web.

CSS came along and gave us real layout tools. That was a genuine improvement. We stopped using tables for structure and started using them for actual tabular data. Floats were painful. Flexbox was a revelation. Grid was even better. These were real steps forward.

JavaScript grew up. And I mean really grew up. That little scripting language we used to swap images on hover? It ate everything. It absorbed what Flash and ActionScript did. Animations. Rich interactivity. Audio. Video. Full application logic. All the things we needed plugins for in 1999, JavaScript eventually handled natively. When Steve Jobs killed Flash on the iPhone in 2010, it wasn't because Flash was bad at what it did. It was because the open web had finally caught up.

Director disappeared even earlier. Shockwave faded out. The plugin era ended. And honestly, that was the right call. The open web should be built on open standards. But we lost something in that transition too. Flash and Director had visual timelines. Drag-and-drop animation. You could see what you were building. The tools that replaced them are more powerful, but they're also more abstract. The creative accessibility those tools offered never fully came back.

PHP grew from a template engine into one of the most widely deployed server-side languages in history. WordPress runs on it. Which means a massive chunk of the internet runs on it. It's easy to look down on PHP today. Developers love to joke about it. But PHP powered the dynamic web before most of today's languages even existed. And it did it by staying approachable. You didn't need to understand object-oriented programming or design patterns to get started. You just wrote some code inside your HTML and it worked.

Responsive design changed everything too. The idea that one website could adapt to any screen size solved a real problem. We went from building separate mobile sites to building fluid layouts that worked everywhere. That mattered.

But somewhere in the mid-2010s, something shifted. The tools started serving the tools instead of serving the people using them. We began optimizing for developer experience at the expense of simplicity. And the complexity just kept compounding.

The jQuery Era and the CSS Framework Treadmill

Before we talk about complexity, let me talk about jQuery. Because jQuery might be the most important JavaScript library ever written. And most people under thirty have no idea why.

In the mid-2000s, writing JavaScript for the web was a nightmare. Every browser handled things differently. Code that worked in Firefox broke in Internet Explorer. Code that worked in IE6 broke in IE7. You spent more time writing browser workarounds than actual functionality. It was exhausting.

jQuery fixed that. One library. Write your code once. It works everywhere. Dollar sign, selector, do something. It was clean. It was readable. It made JavaScript accessible to designers and backend developers who had been avoiding it. jQuery didn't just simplify JavaScript. It democratized it. Suddenly everyone could add interactivity to their sites without losing a week to browser debugging.

And jQuery was everywhere. At its peak, it was on something like 70% of all websites. It was the default. For a lot of developers, jQuery was JavaScript. They learned the library before they learned the language.

CSS went through its own evolution. After we finally killed table layouts, we had floats. And floats were a pain. Clearing floats. Float drops. The holy grail layout that required three different hacks to work. We needed help.

Blueprint CSS showed up around 2007 and gave us something we'd never had before. A grid system. Predefined columns. Consistent typography defaults. It was one of the first CSS frameworks, and it felt like someone had finally brought order to the chaos. You included the stylesheet, added some class names, and your layout just worked. No more fighting with floats from scratch on every project.

Blueprint paved the way for what came next. 960 Grid System. YAML. Foundation. And then in 2011, Bootstrap came along and changed the game entirely.

Bootstrap gave you everything. Grid system. Typography. Buttons. Forms. Navigation. Modals. Dropdowns. Responsive breakpoints. All of it, out of the box. You could build a professional-looking website in a day without writing a single line of custom CSS. It was Dreamweaver logic applied to the modern era. Lower the barrier. Let people build.

The tradeoff? Every Bootstrap site looked like a Bootstrap site. The internet developed a sameness. The same buttons. The same navbar. The same card layouts. You could spot Bootstrap from a mile away. But it worked. And for a lot of businesses, looking polished and consistent mattered more than looking unique.

Now we've got Tailwind. And Tailwind is a completely different philosophy. Instead of pre-built components, you get utility classes. Tiny, single-purpose class names that you compose directly in your HTML. It's polarizing. Some developers love it because it's fast and flexible. Others look at a div with twenty class names on it and feel like they're reading a different language.

Here's the pattern I want you to see. Blueprint. Bootstrap. Tailwind. Three different eras. Three different approaches. All solving the same fundamental problem: how do you make CSS manageable at scale?

The answer keeps changing. The problem doesn't.

The CMS Graveyard

You want to see the churn in this industry? Look at content management systems. The CMS landscape is a graveyard of tools that were going to change everything.

I've watched so many come and go.

Mambo was one of the early open-source CMS platforms that people actually used. It was popular. It had momentum. Then the community fractured and Joomla forked off from it in 2005. Mambo faded. Joomla carried on. That's how fast things moved.

Joomla had its moment. For a while it was a real contender. It sat right between WordPress and Drupal in terms of complexity. Not as simple as WordPress, not as developer-heavy as Drupal. But it never found a clear identity, and over time its community thinned out. It's still around, technically. But the energy is gone.

Drupal was the enterprise choice. The serious CMS. If you needed complex content types, custom workflows, granular permissions, Drupal could do it. I built a lot of projects on Drupal over the years. But it demanded a lot from you. The learning curve was steep. Updates could be brutal. Drupal 7 to Drupal 8 was essentially a full rewrite that left a lot of agencies scrambling. It pushed people away who didn't have the resources to keep up.

WordPress won. That's the simple version of the story. It started as a blogging platform and just kept expanding. Themes. Plugins. Page builders. Gutenberg. WooCommerce. It went from "I want to write blog posts" to "I want to run my entire business" and it pulled it off through sheer ecosystem size. Is WordPress the best CMS from a technical standpoint? No. But it's the one that made content management accessible to regular people. There's that word again. Accessible.

Along the way there were others. Expression Engine had its loyalists. Textpattern had its niche. Concrete5 tried something different with in-page editing. Squarespace and Wix showed up and said forget the CMS entirely, we'll just host everything for you. Craft CMS earned respect from developers who wanted something cleaner than WordPress but more approachable than Drupal.

And now we're in the headless era. Contentful. Sanity. Strapi. The CMS doesn't even render your website anymore. It just holds your content and serves it through an API. Your frontend could be React, Next.js, Astro, whatever you want. The CMS became a database with a nice editing interface.

Every generation of CMS solved real problems. And every generation eventually got replaced by something that solved those problems differently. The content never changed. People still need to publish words and images on the internet. The machinery underneath just keeps getting rebuilt.

That's the thing about this industry. We keep rebuilding the machinery.

The Complexity Trap

Let me be clear about something. I'm not against new tools. I'm not against frameworks. Some of them solve real problems. But the industry has a habit of reaching for complexity when simplicity would work just fine.

I've watched this cycle repeat for twenty-six years.

A new framework shows up. It solves a specific problem really well. People start using it for everything, even problems it wasn't designed for. The ecosystem around it explodes. Now you need twelve dependencies just to get a project started. Then a newer framework comes along, and the whole thing starts over.

Meanwhile, the fundamentals haven't changed. HTML still works. CSS still works. Vanilla JavaScript is more powerful than it's ever been. You can build impressive, fast, functional websites without a single framework. But try telling that to someone who learned to code in the era of create-react-app. They'll look at you like you suggested they write assembly.

We've created a culture where you feel behind if you're not using the latest thing. Where job postings list fifteen technologies for what amounts to a CRUD app. Where junior developers feel overwhelmed before they even start because the landscape looks impossibly vast.

It doesn't have to be this way.

AI Didn't Simplify Things. It Added a New Layer.

Now we've got AI in the mix. And I'll be honest. It's a powerful tool. It's changing how we work. I use it. My team uses it. We'd be foolish not to.

But it didn't simplify web development. It added another layer on top of everything else.

AI can generate code faster than any human. That's a fact. It can scaffold an entire application in minutes. But someone still has to understand what it built. Someone has to debug it when it breaks. Someone has to know whether the code it generated is good, secure, and maintainable, or if it's just code that happens to run.

Writing code was never the hard part. I know that's a spicy take, but I've believed it for twenty-five years. The hard part is comprehension. It's building a mental model of how a system works. It's understanding what happens when you change one thing and something else breaks three layers down. It's knowing the right approach before you write a single line.

AI doesn't give you that. Not yet. Maybe not ever. It gives you output. Understanding is still a human job.

And here's the irony. AI has actually made it more important to understand the fundamentals, not less. If you can't read and evaluate the code that AI generates, you're not using a tool. You're trusting a black box. That's a different thing entirely.

What the Trades Can Teach Us

I work with contractors every day. HVAC techs. Plumbers. Electricians. Roofers. These are people who build and fix real things with real consequences.

You know what they don't do? They don't chase the latest trend for the sake of it. They learn their trade. They master their tools. When a better tool comes along, they evaluate it based on whether it actually helps them do the job better. Not whether it's new. Not whether it's trendy. Whether it works.

A good HVAC technician doesn't need the fanciest equipment on the market. They need to understand refrigerant cycles, airflow, electrical systems, and how buildings work. The fundamentals. Give a great tech basic tools and they'll diagnose a problem faster than a mediocre tech with every gadget available.

Web development could learn something from that.

Know your fundamentals. Understand how the web works at a basic level. Then choose your tools based on what the project actually needs, not what the industry is hyping this quarter.

What I'd Tell the Kid on That Zip Disk

If I could somehow reach back through time to that kid sitting in a computer lab at Champlain College, building his first website with image maps and table layouts, here's what I'd tell him.

You're on the right track. The things you're learning right now, how HTML structures a page, how elements relate to each other, how a browser turns code into something visual, those things are going to matter for your entire career. The tools will change a hundred times. The fundamentals won't.

Don't let anyone make you feel like what you're building isn't real because you used Dreamweaver instead of writing code from scratch. You're learning how to think about building for the web. That's the skill. The syntax is just the language you use to express it.

Stay curious. Stay building. Don't over-complicate things.

Keep it simple. Make it look beautiful. Have it work.

The Disk Is Making the Move

I still can't open that Zip disk. I still don't have a drive. But it's packed in a box with my name on it. It's coming with us to the new place.

Not because I think what's on it is good. I'm sure it's terrible. Tables nested inside tables. Image maps with hardcoded coordinates. Dreamweaver-generated markup that would make modern linters crash.

But it's the start. It's proof that twenty-six years ago, a kid sat down at a computer and decided to build something for the web. And he never stopped.

The tools changed. The industry changed. The complexity grew in ways none of us could have predicted.

The curiosity didn't change. The fundamentals didn't either.

If anyone has a working Zip drive collecting dust somewhere in Vermont, let me know. This disk and I have some catching up to do.