Forem: Max Mendes

MCP Is the USB Port for AI Tools

Max Mendes — Thu, 26 Mar 2026 19:01:22 +0000

Before USB, connecting a mouse to a computer was a lottery. PS/2 ports, serial ports, proprietary connectors from every vendor. Then USB showed up and the whole problem disappeared. One standard. Everything just worked.

That is exactly what Model Context Protocol is doing for AI right now.

What MCP Actually Is

MCP is an open protocol, originally created by Anthropic in November 2024, that defines a standard way for AI models to connect to external tools, data sources, and systems. Built on JSON-RPC 2.0 and inspired by the Language Server Protocol that powers every modern code editor, it gives you three core primitives: Tools, Resources, and Prompts.

Instead of every AI product needing a custom integration with every other tool, MCP gives you one interface that works everywhere. Think of it as the difference between writing a separate driver for every printer versus having a USB port that any printer can plug into.

The numbers back this up. The MCP ecosystem has grown to over 97 million monthly SDK downloads across Python and TypeScript, more than 10,000 active MCP servers, and 66,000 stars on the official GitHub repository. That is not a niche experiment. That is infrastructure.

Why It Won So Fast

A year after launch, MCP stopped being Anthropic's thing. OpenAI adopted it in March 2025, integrating it across their Agents SDK, Responses API, and ChatGPT desktop. Sam Altman said publicly that "people love MCP and we are excited to add support across our products." Then Google DeepMind followed in April 2025. Microsoft and AWS came next.

In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with OpenAI and Block, with AWS, Google, Microsoft, Cloudflare, and Bloomberg as supporting members. At that point it became industry infrastructure, not a feature.

Normally this kind of adoption takes years. OAuth 2.0 needed roughly four years to reach comparable penetration. OpenAPI took about five. MCP did it in twelve months. And it did it while being openly imperfect, which meant the controversy it generated actually accelerated the conversations that needed to happen.

I wrote about a similar pattern with vibe coding, where adoption outran the discourse about risks. MCP followed the same trajectory: the tool was too useful for people to wait for it to be perfect.

What the USB Analogy Gets Right

In my own setup running OpenClaw, I have a single AI agent that can read emails, update spreadsheets, trigger scrapers, post to GitHub, check the weather, and write to memory files. Not because I built custom code for each of those. Because each service exposes an MCP interface, and the agent just knows how to use it.

The same agent, different context, can talk to a PostgreSQL database in one session and a Notion workspace in the next. You do not retrain the model. You do not write new integration code. You just point it at a new MCP server. That is the USB promise, and it delivers.

When I built automation workflows to find businesses without websites, each step in the pipeline talked to a different service. Before MCP, that meant writing and maintaining separate API integrations for every connection. Now the agent handles the routing. I design the system. The protocol handles the plumbing.

That shift matters for projects like FlowMate, where the AI needs to interact with email providers, databases, and third-party APIs in a single workflow. MCP turns what used to be weeks of integration work into configuration.

What the USB Analogy Gets Wrong

The counterargument worth taking seriously is that USB was hardware and MCP is software. Hardware standardization has a physical forcing function: you literally cannot plug the device in if the port does not match. Software "standards" can live alongside ten competing standards for decades. SOAP and REST coexisted long after REST had clearly won.

That is a fair point. And there is real fragmentation happening. Some vendors are implementing MCP partially. Others are adding custom extensions that break interoperability. The spec itself has evolved enough that "MCP" in early 2025 and "MCP" after the November 2025 anniversary release with OAuth 2.1 and Streamable HTTP are not exactly the same thing.

There is also Google's A2A protocol to consider. A2A handles agent-to-agent communication, which MCP was not designed for. They are complementary, not competing, but the market does not always see it that way.

Still, I think MCP clears the bar. The big players are not just adopting it as a marketing checkbox. They are shipping agents that depend on it. Claude, ChatGPT, Copilot, Gemini. When the primary products of the dominant AI companies rely on a protocol, that protocol tends to survive.

The Part Nobody Talks About Enough: Security

The interesting moment is not the standard itself. It is what happens next.

The USB analogy is apt but limited. USB solved a physical connection problem. MCP is solving a semantic connection problem. How does an AI understand what a tool does, what arguments it takes, what it returns, what permissions it needs? The protocol answers that. What it does not answer is quality. MCP tells you how to talk to a tool, not whether that tool is reliable, secure, or honest about what it does.

Microsoft published a security analysis called "Plug, Play, and Prey" that lays out the risks clearly. Red Hat and Palo Alto Networks have published their own vulnerability guides. A world where every SaaS product exposes an MCP server is also a world where AI agents can accidentally, or deliberately, be pointed at malicious servers that claim to be something else.

I think about this constantly in my own work. When I build AI integration for local businesses in Poland, I am connecting AI to their booking systems, their CRMs, their social accounts. That is sensitive data. MCP makes the connection easy. It does not make it safe by default. That is still on the developer.

The dead internet problem taught us what happens when you cannot verify what is real online. The same trust problem is coming to AI tool connections. The next layer being built on top of MCP is tool registries, trust signals, and permission scoping. That is where the real complexity lives.

What This Means If You Build Things

So yes, MCP is the USB port for AI. USB was a massive upgrade for computing. It also made it trivially easy to plug in a keylogger. The standard winning is the start, not the end.

For developers, the practical takeaway is straightforward. Learn MCP. Build with it. But do not skip the security layer just because the protocol makes connections feel frictionless. Every MCP server you connect to is a trust boundary, and your users are counting on you to treat it that way.

For business owners, this means AI automation is getting cheaper and more capable every month. The tools that were enterprise-only two years ago are now accessible to any small business. But you need someone who understands the security implications, not just the happy path.

I will write more as this evolves, especially once the 2026 MCP roadmap features start shipping and I have more experience running MCP-connected agents in production against real client systems.

This article was originally published on maxmendes.dev.

Vibe Coding Is Eating Software Development - And Not Everyone Is Happy

Max Mendes — Thu, 19 Mar 2026 14:05:42 +0000

Andrej Karpathy coins a term on X in February 2025. The post gets 4.5 million views. By March, Merriam-Webster adds it as a slang entry. By November, Collins Dictionary names it Word of the Year. By January 2026, MIT Technology Review lists generative coding as a 2026 Breakthrough Technology. By February 2026, Karpathy himself says the term is already "passe" and introduces "agentic engineering" as the next evolution.

That is a fast arc for a concept that started as a casual post about accepting AI output without reading the diffs.

Here is my take: vibe coding is real, it is useful, and the people most upset about it are largely upset for the wrong reasons.

What Vibe Coding Actually Is

The original definition from Karpathy is blunt: you describe what you want, the AI generates code, and you "forget that the code even exists." You accept output without reviewing it, nudge it with follow-up prompts, and ship when it works.

Simon Willison drew a line that I think matters more than the hype. If you have reviewed, tested, and understood the code, that is not vibe coding. That is using an LLM as a typing assistant. The distinction is about accountability, not about whether AI touched the code.

That is exactly how I work. I review every important piece. I test it. I understand the architecture before anything goes near production. When I built FlowMate, a production SaaS handling email management with AI integrations, every line of AI-assisted code went through manual review. The AI accelerated the typing. The engineering decisions were still mine.

But plenty of people are using the Karpathy definition literally. Non-coders building apps. Founders shipping MVPs without a technical hire. Solo developers building internal tools faster than any team could. That is the part that is making senior engineers nervous.

The Numbers Tell a Complicated Story

The Stack Overflow 2025 Developer Survey found that 84% of developers now use or plan to use AI coding tools, up from 76% in 2024 and 70% in 2023. Over half use them daily. GitHub Copilot alone has crossed 20 million users and writes roughly 46% of the average user's code.

The big claims from tech leadership keep escalating. Satya Nadella said 30% of Microsoft's code is now AI-written. Dario Amodei at Anthropic claimed 70 to 90% of their code comes from Claude. At Y Combinator's Winter 2025 demo day, Garry Tan revealed that 25% of startups in the batch had codebases that were almost entirely AI-generated.

But here is the part that gets less attention: positive sentiment toward AI coding tools actually dropped. The same Stack Overflow survey showed satisfaction fell from over 70% in previous years to just 60% in 2025. And 66% of developers reported frustration with "AI solutions that are almost right, but not quite."

The adoption is real. The satisfaction is not keeping up.

The Criticism Is Partly Right

The concerns are not imaginary, and the data backs them up.

GitClear analyzed 211 million lines of code from 2020 to 2024 and found that code duplication grew 4x since AI tools became widely adopted. Refactoring collapsed from 25% of changed lines in 2021 to under 10% by 2024. For the first time in the history of their dataset, developers were pasting code more often than refactoring it.

CodeRabbit's research on 470 GitHub pull requests found that AI-generated code produces 1.7x more issues overall. Security vulnerabilities specifically were 2.74x higher. Readability problems were 3x more frequent.

Wiz scanned 5,600 vibe-coded applications and found over 2,000 vulnerabilities, 400 exposed secrets, and 175 instances of exposed personal data. One in five vibe-coded apps had serious security or configuration errors. The pattern was always the same: client-side authentication, hardcoded API keys, unprotected database access.

The DORA 2025 report added nuance. AI boosts individual developer output (21% more tasks completed, 98% more pull requests merged), but organizational delivery metrics stayed flat. The report concluded that AI acts as a "multiplier." It strengthens teams that already have good practices and exposes teams that do not.

Someone who vibe-coded a customer-facing app with no understanding of the security model has created a liability, not a product. And as more of these apps hit production, someone has to clean it up.

The Open Source Crisis

One consequence that caught the industry off guard is what happened to open source maintainers.

AI-generated pull requests started flooding popular repositories. Daniel Stenberg, the maintainer of curl, shut down his bug bounty program because fewer than 5% of AI-generated submissions were legitimate. Mitchell Hashimoto banned AI-generated code from the Ghostty project entirely. Steve Ruiz closed all external pull requests to tldraw.

GitHub started considering restrictions on pull requests to help maintainers manage the flood. The people who volunteer their time to maintain critical infrastructure were suddenly drowning in low-quality AI output from contributors who never read the codebase.

This is not a theoretical concern. It is an active crisis for the people who keep the open source ecosystem running. And it is a direct result of vibe coding culture applied where it does not belong: in existing, complex systems that require deep understanding before you touch them.

The Criticism Is Also Missing the Point

That said, the loudest complaints are often framed as "vibe coding is bad for software." But what I keep reading between the lines is something else: "people who don't know what I know are now building things."

That is not a technical argument. That is a guild protecting its territory.

I build websites and automation systems for local Polish businesses. Small restaurants, nail salons, barbers. None of them need a team of senior engineers. They need a working website with a contact form and decent SEO. I use AI-assisted coding to build those faster and cheaper than I could otherwise. That is not a crisis. That is the market working.

The crisis is real for companies that have vibe-coded their way into 50,000 lines of AI-generated spaghetti and now need to add a feature. The solution there is not "ban AI from development." It is "understand what you are building."

What Actually Matters in 2026

I will take a stance here: the developers who are scared of vibe coding are the ones whose value was in knowing syntax and APIs. That was always a fragile position. The developers who are fine are the ones whose value is in knowing what to build, why to build it, and whether what got built is correct.

Vibe coding raises the floor. Anyone can now produce working code for simple problems. That is genuinely good. The ceiling (understanding systems, making architectural decisions, spotting the security hole the AI missed) has not moved. If anything, it got more valuable, because someone has to supervise all these AI-generated applications.

The Stanford Digital Economy Lab found that employment among software developers aged 22 to 25 fell nearly 20% between 2022 and 2025. But developers over 26 saw stable or growing employment. The entry-level "write code from tutorials" job is disappearing. The "understand systems and make decisions" job is not.

I am using Claude on almost every project now. I prompt, I review, I modify. I do not fully give in to the vibes. But I also do not pretend I hand-write everything from scratch to preserve some purity that stopped mattering two years ago.

The Middle Position

The developers who will struggle are not the ones who adopt AI coding. They are the ones who refuse it, and the ones who adopt it without judgment. The middle position, where you use the tools and stay responsible for the output, is where the actual work happens.

Vibe coding is eating software development. Some of that is messy and some of it will cause problems. But the core shift, that describing what you want in plain language is now a valid way to build software, is here and it is not reversing.

The question was never "should developers use AI?" It was always "how do you use it without creating a mess?" The answer is the same as it has always been in engineering: understand what you are building, test it, and take responsibility for the result.

Originally published on maxmendes.dev. I write about web development, AI tools, and building for small businesses in Poland.

Dead Internet Theory Is Real. Why Human-Made Websites Win in 2026.

Max Mendes — Thu, 12 Mar 2026 10:48:39 +0000

51% of all internet traffic in 2024 was not human. That's not a prediction. That's the number from Thales' 2025 Imperva Bad Bot Report. For the first time in a decade, bots outnumber people online. Not by a small margin. They are the majority.

I noticed this before I ever read that report. I was scrolling through Google Maps reviews for a client in Częstochowa and something felt wrong. The language was too smooth. Three different profiles used the same phrasing. The accounts were two weeks old. No photos, no history, no other activity. Classic bot patterns. But then I looked at their competitors' websites and the content had that same hollow quality. Clean sentences that said nothing. Paragraphs that existed to fill space.

That's when it clicked. The internet is filling up with content that nobody wrote.

What the Dead Internet Theory Got Right

The dead internet theory started as a conspiracy theory around 2021. The original claim was extreme: governments and corporations had secretly replaced most online activity with bots to manufacture consensus. That part was never provable.

But the core observation turned out to be accurate in ways nobody expected.

Bots didn't just stay in the shadows. They became the majority. Automated traffic hit 51% of all web traffic. Bad bots alone account for 37%. Reddit co-founder Alexis Ohanian said it plainly: "so much of the internet is dead." The founder of one of the biggest human platforms on the internet is telling you it's over.

A recent academic survey on arXiv mapped out how artificial interactions are reshaping social media entirely. It's not fringe anymore. Researchers are studying this as a structural shift in how the internet functions.

And that's only half the story.

AI Slop Became the Word of the Year. Think About That.

In late 2025, "slop" was named Word of the Year by Macquarie Dictionary, Merriam Webster, and the American Dialect Society. All three. Independently. The word describes exactly what you think: low effort, AI generated content that floods every platform and adds nothing.

In March 2026, a game called Your AI Slop Bores Me went viral on Hacker News. The concept is brilliant. Instead of trying to detect AI, players pretend to be AI and generate the most generic, soulless content they can. The joke lands because everyone recognizes it instantly. We've all been on the receiving end. Blog posts answering questions nobody asked. About pages describing a company as "passionate about delivering innovative solutions." LinkedIn posts that exist only to exist.

The satire works because the reality is already mainstream. People have even started responding to suspected AI content with "ai;dr", a spin on "tl;dr" that means "I'm not reading this, it's obviously AI." That's not a niche joke. That's a cultural shift.

How big is the flood? Ahrefs analyzed 900,000 newly published web pages and found that 74.2% contained AI generated content. Not traffic. Content. Three out of four new pages on the internet were not written by a person.

A University of Florida study from March 2026 confirmed what creators already knew: AI slop hurts both consumers and the people making real content. TechCrunch covered the same question from the creator economy angle. And in January 2026, YouTube ran its largest mass termination of AI driven channels in the platform's history.

The signal is clear. The internet is drowning in generated noise. And people are starting to fight back.

The Myth That Google Doesn't Care

There's a popular misconception floating around: "Google doesn't penalize AI content." That's technically true. And completely misleading.

Google's official position is that they evaluate content quality, not how it was produced. Fair enough. But here's what actually happened in practice.

In February 2026, Google rolled out a core algorithm update that caused massive ranking volatility across industries. The pattern was consistent: content demonstrating real, first person experience moved up. Generic content moved down. The E-E-A-T framework (Experience, Expertise, Authoritativeness, Trustworthiness) is no longer a suggestion. It's a requirement for ranking.

The emphasis is on that first E. Experience. Google wants to know: did you actually do this thing you're writing about?

A study by Rankability found that 83% of top ranking results use human generated content. Meanwhile, Google traffic to publishers dropped 33% globally between November 2024 and November 2025. The sites that survived that drop? The ones with original, experience based content. Google doesn't want to serve summaries of summaries of summaries. It wants sources. It wants the person who actually did the work.

For local businesses, this is even more direct. When a nail salon in Częstochowa gets asked "how did you find us?" and the answer is "Google," that means Google trusted that website. It trusted it because it had real photos, real reviews, real language, real local signals. A bot can't write about what parking looks like on Śląska Street at 7pm on a Tuesday. That level of specificity is what wins.

What a Generated Website Sounds Like vs. a Real One

Let me show you the difference.

Generated About page:

"We are a passionate team dedicated to providing high quality services. With years of experience and a commitment to excellence, we deliver innovative solutions tailored to your needs."

A real About page, built from a 20 minute conversation:

"Ewa has been cutting hair on Aleja NMP since 2003. She started with one chair in a room above a flower shop. Twenty years later, her clients still call to book because they don't trust online forms. That's fine. She picks up every time."

The first one could describe any business in any country. The second one could only be Ewa's salon. That's the difference between content that fills a page and content that builds trust. Google knows the difference. Your customers definitely know the difference.

I build websites for Polish small businesses. When I write copy for a client, I don't generate it. I ask questions. What do your regulars say about you? What do you do differently from the place two streets over? What's the neighborhood like? Those answers don't exist in any training dataset. They exist in a conversation.

Why This Matters More in Poland Than Anywhere Else

I've spent months researching why Polish SMBs don't have websites. Most of them run their businesses through Booksy, Instagram, and Google Business profiles. They're not behind. They've optimized for the platforms available to them.

But here's the thing. When 90% of new business websites are built with AI tools, they all sound the same. Same structure, same vocabulary, same promises. Built fast and it shows. Meanwhile, a local business in Częstochowa has something inherently unique: the owner's name, the neighborhood, the services locals actually ask for, photos from inside the shop.

That specificity is a competitive moat right now. It can't be generated. It has to be gathered.

The businesses that don't have websites yet have an unexpected advantage. They haven't been poisoned by template language. When they finally get a site, it can be built from scratch with real content. No legacy AI slop to clean up. No generic copy to replace. Just their story, told for the first time, properly.

If you're wondering what that investment looks like, I wrote a detailed breakdown of real website costs in Poland.

The Window Is Open Right Now

The AI slop flood is a problem. But it's also a gap.

When the majority of new websites sound like they were assembled by a machine in 30 seconds, the ones clearly made by a real person for a real business stand out immediately. Customers notice. Search engines notice. Google's February 2026 update proved this with data.

I use AI in my workflow constantly. I built an entire automation system to find businesses that need websites. But there's a difference between using AI to help build something human and using AI to replace the human entirely. The first produces a great website. The second produces noise.

The businesses I work with don't need to win the internet. They need to win their city. A bakery in Gliwice doesn't need to rank globally. It needs the person two kilometers away searching for a birthday cake to find it, trust it, and call.

That's a solvable problem. But you need a real website to solve it. One that sounds like a person wrote it, because a person did. One that Google trusts because it has the SEO fundamentals done right. One that your customers recognize as yours the moment they land on it.

The internet got loud. The businesses that win now are the ones that sound like someone actually wrote their website. Because someone did.

Questions? Reach out. I reply within 24 hours.

Also available in Polish.

How Much Does a Website Cost for a Small Business in Poland?

Max Mendes — Thu, 05 Mar 2026 16:32:13 +0000

Every week I talk to a business owner in Częstochowa who got a quote for a website and has no idea if it's fair. One agency says 3,000 PLN. Another says 18,000 PLN. A friend says "just use Wix, it's free." Nobody explains what you're actually getting for those numbers.

I've been building websites for Polish small businesses for years. Here are straight answers.

The Three Options and What They Actually Cost

There are three realistic paths for a small business website in Poland: a web agency, a freelancer, or a DIY platform. Each has a real price and real trade-offs.

Web agencies in Poland typically charge between 5,000 PLN and 15,000 PLN for a standard small business website. Larger Warsaw-based agencies can push that figure to 20,000 PLN or more. You're paying for a team, project management, account managers, and overhead. The work quality varies wildly, and I've personally seen 12,000 PLN sites that looked like they were built in 2014.

Freelancers are generally cheaper, ranging from 1,500 PLN to 6,000 PLN for a comparable site. The risk is experience and availability after launch. Some freelancers are excellent. Others disappear the moment something breaks. The price difference is real, but so is the variance in quality, which is why referrals matter more than portfolio links.

DIY platforms like Wix or Squarespace start around 50–80 PLN per month for a business plan. That's under 1,000 PLN per year, which sounds reasonable at first. I'll come back to this.

What Cheap Actually Costs in the Long Run

Here's the honest truth most pricing guides skip: a cheap website can end up costing more than an expensive one over three years.

A Wix Business plan runs roughly 70 PLN per month. Over three years, that's 2,520 PLN, and at the end of it you still don't own anything. Wix keeps your site on their infrastructure. You can't export it cleanly and move it. Their SEO tools have improved, but a Wix site still consistently underperforms a well-built custom site on page speed scores, and in Poland, where most Google searches happen on mobile phones, every extra second of load time loses you visitors.

A cheap WordPress site built on shared hosting for 800 PLN is a different problem. WordPress needs regular updates, plugin licenses, security patches, and backups. Nobody mentions this at the time of the quote. A year later the site is outdated, possibly compromised (WordPress is the most targeted CMS on the internet), and the developer who built it charges for every small change. I've had clients come to me with sites that cost 2,000 PLN two years earlier. They'd since paid 400–600 PLN in scattered "maintenance fees" and the site still loaded in four seconds on a phone. That's not a working website, it's an expensive placeholder.

The hidden cost nobody advertises is the ongoing relationship. Who do you call when the contact form stops working? Who updates the plugin that's causing a security warning? If the answer is "I'll figure it out," that's time you're not spending on your actual business.

What a Local Polish SMB Actually Needs

Most small businesses — a restaurant, a nail salon, a plumber, a physiotherapist — don't need a complex website. They need:

A site that loads fast on mobile (under 2 seconds)
Clear contact information and location
Services or menu listed clearly
Enough on-page SEO for Google to understand what they do and where
Something that doesn't embarrass them when a customer searches their name

That's five pages maximum. No custom e-commerce. No backend dashboard to maintain. No animations that take 10 seconds to render on a mid-range Android.

I see small businesses in Poland spending 8,000–15,000 PLN on websites with features they will never use, built by agencies who didn't ask what they actually needed. On the other end, I see business owners fighting with Wix for hours trying to make a simple menu update, time that cost them far more than a proper site would have.

My Pricing, and Why I Publish It

Most agencies quote after a meeting. That quote varies depending on how big your office looks, whether you mentioned you have a budget, and how much they think you'll pay. I've heard of identical briefs getting quotes ranging from 3,000 PLN to 25,000 PLN at different agencies in Poland.

I build business websites for local Polish SMBs at a fixed price of 2,500 PLN. That covers a clean, fast, mobile-first site of up to 5 pages, domain and hosting included for the first year. After that, annual hosting runs 400–600 PLN, and I don't charge for small text or photo updates. The site is yours, built on technology you can hand to any developer if you ever want to switch.

Fixed pricing doesn't work for every project. Custom e-commerce, booking systems, or multilingual sites genuinely cost more, and I'll tell you upfront what that looks like before you commit to anything. But for a local business that needs a solid, fast website that shows up on Google, variable pricing mostly just creates confusion.

I also handle SEO basics as part of every build: proper page titles, structured data, Google Search Console setup, and a site structure that makes sense to search engines. That's not an upsell. It's part of making the site actually work.

The Bottom Line

A website for a small business in Poland costs between 1,500 PLN and 15,000 PLN depending on who builds it and what you need. Agencies charge more for the brand and team size. Freelancers charge less but require due diligence on your part. DIY platforms look cheap until you factor in three years of subscriptions, the time spent managing them, and the SEO ceiling you'll hit.

For most local businesses, a well-built 5-page site from a reliable freelancer is the right call. Fast, owned, ranks on Google, and no recurring monthly fees forever.

If you're in Częstochowa or anywhere in Poland and want a straight conversation about what your site should cost, reach out here or call +48 502 742 941. I'll tell you honestly whether what I offer fits what you need. And if it doesn't, I'll tell you that too.

If you're curious why so many Polish businesses skip websites entirely, I wrote about the psychology behind that decision. And if you want to see how I find businesses that need websites in the first place, here's the AI system I built for prospecting.

Questions? Reach out — I reply within 24 hours.

Why Polish Small Businesses Don't Need Websites (And Why I'm Building Them Anyway)

Max Mendes — Fri, 27 Feb 2026 10:20:16 +0000

I've spent the last month cold-prospecting nail salons and barbers in Częstochowa. 100+ businesses researched. Maybe 15 have proper websites. The rest? Booksy profiles and Instagram accounts. That's it.

When I started building an AI system to find these businesses, I thought the lack of websites was laziness or budget constraints. It's not. It's a deliberate choice rooted in a very specific psychology.

Polish small business owners genuinely believe websites are unnecessary. And I'm starting to understand why.

The Booksy Fortress

Booksy owns the Polish beauty and wellness market. Not "has a presence." Owns.

If you're a nail salon, barber, or massage therapist in Poland, you're on Booksy. It's not optional. Your clients book through Booksy. They discover you through Booksy. Your calendar lives in Booksy. Your payments run through Booksy.

Why would you need a website when Booksy already handles discovery, booking, payments, and reviews? The platform does everything a website would do, except you don't have to build it or maintain it.

From the business owner's perspective, a website is redundant infrastructure. I've read this exact sentiment in my research notes at least 20 times. "Already on Booksy."

The logic is sound. The conclusion is still wrong, but the logic is sound.

Instagram as the Second Pillar

The businesses that aren't beauty/wellness based, restaurants and bars, live on Instagram and Facebook.

They post daily. Photos of dishes, interior shots, weekend specials. Stories with live updates. DMs for reservations. The engagement is real. People comment, tag friends, share posts.

For these owners, Instagram is their website. Why pay for something static when you can post for free and reach customers where they already spend their time?

Again, the logic holds. A restaurant doesn't need online booking. They need people to show up. Instagram drives that better than a landing page buried on page 3 of Google.

The Trust Gap

There's a third layer that took me longer to notice. Websites carry a credibility problem in Poland's SMB market.

Older demographics, which dominate small business ownership here, associate websites with either big corporations or scams. A local barber with a sleek website feels suspicious. Too corporate. Not authentic.

Instagram feels personal. Booksy feels utilitarian. A website feels like someone is trying too hard or hiding something.

I didn't expect this. In Western markets, no website is the red flag. In Poland's local service economy, having one can raise questions. "Why do you need this? What are you selling me?"

Why They're Wrong (But Also Right)

Here's the thing. They're not entirely wrong.

If you're a nail salon with 200 regular clients who all book through Booksy, and your schedule is full most weeks, why burn money on a website? The return on investment is unclear. The effort to maintain it is real.

But here's what they're missing.

Booksy owns the customer relationship. Not them. If Booksy raises fees, they pay. If Booksy changes the algorithm, they adapt. If Booksy shuts down tomorrow, they lose their entire discovery channel overnight.

Instagram is even worse. You're building an audience on rented land. Algorithm changes, shadowbans, account suspensions. You have zero control.

A website is the only piece of digital infrastructure you actually own. It's insurance against platform dependency. It's leverage when Booksy tries to squeeze margins. It's the foundation for everything else, email lists, direct booking, content marketing, local SEO dominance.

Most importantly, it separates you from every other business stuck in the same Booksy/Instagram loop. When someone Googles "nail salon Częstochowa," the businesses with proper websites win. The rest don't even appear.

The Opportunity

This is why I'm building them anyway.

The fact that Polish SMBs don't see the value is exactly why there's value in showing them. The market is underserved because the market doesn't know it needs serving.

My approach isn't to argue. It's to show. I build the website first, using photos from their Instagram and services from their Booksy profile. Then I show them what they could own instead of rent.

Some will ignore it. Some will dismiss it. But some will see it and realize they've been thinking too small.

That's the opportunity. Not convincing skeptics. Finding the 10% who are ready to see what ownership looks like.

What I'm Learning

Prospecting these businesses taught me more about market psychology than any course or framework ever could.

People don't resist websites because they're uninformed. They resist because their current setup works well enough, and change introduces risk with unclear reward.

The businesses that will adopt websites aren't the ones doing poorly. They're the ones doing well and starting to feel the ceiling. The owner who wants to expand but realizes Booksy doesn't scale beyond one location. The restaurant that maxed out Instagram reach and needs another channel.

Understanding why they don't need websites is more valuable than explaining why they do. It changes how I pitch, what I build, and who I target.

Where This Goes

I'm still early in this process. The AI system I wrote about in my previous post finds the prospects. But converting them requires understanding the mindset first.

Polish SMBs aren't behind on digital marketing. They've optimized for the platforms available to them. Booksy and Instagram work. Websites don't obviously improve on that equation.

My job isn't to fight that logic. It's to show what becomes possible when you own your infrastructure instead of rent it.

I'll write more as this evolves.

This article is also available on maxmendes.dev.

Questions? Reach out — I reply within 24 hours.

How I Built an AI System to Find Polish Businesses Without Websites

Max Mendes — Thu, 19 Feb 2026 11:29:25 +0000

I'm a freelance web developer in Częstochowa. My biggest challenge isn't building websites — it's finding businesses that need them.

Most Polish SMBs don't know they need a website. They run successful operations entirely through Facebook, Instagram, Booksy, or Google Business profiles. They have reviews, customers, and revenue. What they don't have is ownership over their online presence.

I built an automation workflow to find these businesses, research them properly, and reach out with something they can't ignore: a live mockup of what their website could look like.

This is how it works.

The Problem I Was Trying to Solve

Cold outreach doesn't work when you say "Do you need a website?" Most business owners say no — because they're already visible on platforms.

But platform visibility isn't ownership. Facebook can change algorithms. Booksy takes commissions. Google Business profiles look identical to competitors. None of these build long-term SEO equity.

I needed a way to:

Find businesses with proven demand (good reviews, active profiles)
Identify which ones lack a real website
Show them — concretely — what they're missing
Do this at scale without losing personalization

Manual research takes hours per prospect. I automated it.

Where the Leads Come From

I don't buy lists. Every lead comes from public, business-relevant sources:

Google Business profiles — reviews, photos, services, hours
Booksy — dominant in Poland for salons, barbers, beauty services
Facebook/Instagram — activity, engagement, visual assets
Public directories — industry-specific listings

The goal isn't volume. It's accuracy. I gather everything: services, pricing signals, location, images, reviews, contact methods. This data feeds every later step.

Qualification: Who's Worth Contacting

Not every business makes sense to contact.

A prospect only qualifies if they pass strict criteria:

Active online presence (recent posts, reviews, engagement)
At least two valid contact methods
Clear services and pricing signals
Defined working hours
No existing ranked website

Company size doesn't matter. Proof of demand does.

If required data is missing, the workflow stops. No guessing, no generic outreach.

The Workflow (High Level)

I use OpenClaw as a 24/7 execution environment. The system runs while I sleep:

Research agent — gathers business data and assets
Evaluation agent — validates completeness
Orchestrator — approves or rejects the prospect
Mockup agent — generates a live website preview using real data
Proposal agent — creates a structured PDF in Polish
Outreach agent — drafts messages for email, Facebook, or Google

Each step depends on validated outputs from the previous one. Nothing proceeds on assumptions.

The Mockup: Why It Works

When a salon owner sees a website with their real photos, their actual services, their reviews — they pay attention.

This isn't a template. It's their business, visualized as a website they could own.

The mockup is generated automatically from the research data. Same images they use on Instagram. Same services listed on Booksy. Same location from Google Maps.

They recognize themselves immediately. That's the point.

The Proposal Structure

Every proposal is written in Polish with a fixed structure:

Dlaczego strona internetowa pomoże Twojemu biznesowi
Co dokładnie oferujemy
Szczegóły inwestycji i wsparcia
Następne kroki

No sales fluff. Educational, concrete, tailored to their specific situation.

What I Learned

What worked:

Time efficiency — research that took hours now takes minutes
Consistency — every outreach is properly researched
Immediate value demonstration — mockups start real conversations
Higher response quality — people reply when they see effort

What didn't work:

Some businesses still undervalue owned websites
Education is still necessary, even with strong visuals
Over-automation without strict quality gates kills credibility

The biggest lesson: fewer, better prospects beat volume every time.

Compliance and Trust

This isn't spam. Key principles:

Business-to-business only
Low-volume, high-relevance
Sent from my personal domain and accounts
No scraping private data
No misleading claims

When someone receives my message, they see a real person with a real website reaching out about their specific business. That's the difference.

What's Next

I'm still iterating on this system. Response rates are improving. The mockup quality keeps getting better. Some conversations have turned into real projects.

If you're a business owner in Poland wondering whether a website is worth it — it probably is. And if you're a developer thinking about outbound — automation works, but only with restraint.

I'll write more as this evolves.

Original post on my blog: maxmendes.dev

Questions? Reach out — I reply within 24 hours.