I have been building widgets, macros, and software tools since 1984, when I set up a Zenith Z-100 computer that had been shipped to my department while I was in the Marine Corps. I cannot count how many problems I have tried to solve with automation. I was never really doing it for profit, but to reduce friction and make the job easier.
Hreflang Builder was my third true commercial-for-profit attempt. It was created to solve a quantifiable, high-impact business problem: website traffic cannibalization across markets caused by Google’s content selection process and the inability of many enterprise CMSs to natively implement hreflang elements.
The product-market fit was undeniable, the technical solution was proven, and the potential business impact was substantial. Every iteration of Hreflang Builder tackled a real-world technical constraint, from handling phantom URLs to managing multi-CMS environments.
The product worked. The business case was clear. The opportunity was massive.
What I didn’t anticipate was how much resistance could stand in the way of solving such an obvious and critical problem. The roadblocks weren’t technological—they were human. Organizational politics, agency dynamics, stubborn technical leaders, and my own reluctance to bypass the chain of command often stopped us cold. Even when millions were on the line, companies stalled, debated, or avoided making a decision entirely.
Running Hreflang Builder taught me that in enterprise SaaS, the value of the solution isn’t enough—you must also navigate the messy reality of people and priorities.
Frustration 1: Solving a Problem Nobody Can Prioritize (Even When It’s Costing Them Millions)
“Help Me, Help You!” Jerry Maguire
Many companies approached us with staggering revenue impacts, losing between $3 million and $25 million per month in lost opportunity due to cannibalization caused by incorrect or missing hreflang. I was offering a solution to a rounding error in the loss that could be implemented within a few days. And yet… they wouldn’t move forward.
I could never reconcile that.
It felt like offering a starving person a meal, only to hear them say it was too spicy. The solution was right there, cost-effective, fast, and proven. But action was stalled by politics, internal debates, or the sheer inertia of enterprise decision-making. In many cases, the hreflang issue was just the visible symptom of much deeper organizational problems: fractured ownership, conflicting incentives, or systems too broken to support even basic fixes.
What I Tried:
- I’d build business cases, educate managers, and create real demos.
- I hoped urgency would translate into action. Often, it didn’t.
What I Learned:
- Some teams don’t care about business impact.
- The pain of the status quo has to outweigh the friction of change, or nothing happens.
- I cared more than they did, and that’s a hard pill to swallow as a founder.
Frustration 2: Being the Referee in Internal Power Struggles
“I was stuck in the middle, trying to referee these debates.”
In many demo meetings, I felt like a marriage counselor. Hreflang touched e-com, dev, SEO, and global marketing. The business impact and the implementation of a solution became everyone’s concern, but nobody’s clear responsibility. I’d often get dragged into internal fights about who should build what, whose process was right, and who would be blamed if it failed.
What I Tried:
- Proposed phased rollouts: quick fixes now, internal builds later.
- Held alignment calls with all stakeholders—sometimes three or four teams at once.
- Advocated for shared KPIs and clarified roles.
What I Learned:
- Without clear ownership and an executive sponsor, progress stalls.
- Most in-house technical builds are overpromised and underdelivered.
You can’t sell alignment—it has to be internal.
Frustration 3: The Oversimplification of Hreflang by Technical Leaders
“They thought it was just matching URLs and outputting XML.”
Most IT teams believed hreflang was a simple fix. One CTO told me, “How hard can it be to take a list of URLs, map them to each other, assign a language and country, and output it in XML format? I could code that this afternoon.”
Maybe so. But if it were really that simple, their CMS would have already done it.
This particular CTO, trying to prove its simplicity, spent six months with his team building a custom hreflang tool, only to have their site structure change halfway through, rendering his hardcoded mapping logic completely useless. He called me the day he realized it and said, “Send the contract.” He had learned his lesson.
Unfortunately, most are too stubborn or too proud to admit that lesson until it’s too late.
What I Tried:
- Visualize the complexity of their implementation and why it is harder than they expect.
- Created build vs. buy models to help facilitate decision-making.
- Offer a bridge solution while their internal or agency bespoke solution is being implemented.
What I Learned:
- When someone underestimates the problem, they’ll always undervalue the solution.
- Be careful not to embarrass key stakeholders with their lack of knowledge or arrogance.
- Education works—but only when people want to be educated.
- Technical egos can kill progress faster than technical debt.
Frustration 4: The SEO Checkbox Mentality—Especially from Agencies
“Hreflang is often viewed as simple and audit checkbox of yes or no.”
For many agencies, hreflang is an audit checkbox. Do you have hreflang tags? Do you have hreflang tag errors? All of these are easy for most diagnostic crawlers to check.
For those who did not, or who had any complexity, we became fair game for audit-checklist SEOs. Initially, we offered a free trial so people could test our solution. But some agencies abused it, using demo accounts to tick an SEO checklist item. They’d build an hreflang XML sitemap, deliver it to the client, and then move on. The client, seeing our name in the file, called us demanding that it be updated.
The bigger problem was the agency deliverable challenge. Implementing hreflang would be a checklist item, but they would identify it as overly complex. Fixing the challenges or implementing them correctly would exceed the time allocated to this activity. This would result in either a partial implementation or the removal of hreflang from the project, as it could not be completed within the allocated deliverable window.
What I Tried:
- Built-in limits and feature gating on free accounts.
- Created education materials for agencies to properly size projects.
- Automating complex processes makes it easier to stay within budget and meet the timeline.
What I Learned:
- Some agencies will always chase margin over mastery.
- Any function treated as a checklist item rather than an ongoing process will be challenging for many agencies.
- Tools like ours can become commoditized quickly unless we actively protect their value.
Frustration 5: Misaligned Expectations Around Reporting and Value
“We even lost a major project because there were ‘no metrics.”
People expected our tool to do things it was never designed for, like reporting on traffic outcomes, offering rank reports, or magically making their content rank in local markets. We focused on mapping alternates and XML creation. Some prospects wanted dashboards, traffic deltas, and ROI proof—even if that was already in their analytics platforms.
In the constructive criticism from a Global Search Award, despite an explicit statement that this was a niche specialty tool, multiple judges commented that we would have done better had the system offered more detailed reporting and integrated other SEO tool features.
What I Tried:
- Detailed guides on how to use existing tools for reports.
- Built usage reports, errors, and breakage logs relevant to the system.
- Explained what we were and what we weren’t.
What I Learned:
- Users want “easy button” solutions that spoon-feed them pretty charts to make it look like they have charts.
- Users don’t read product documentation or even log in to tools.
- If they wish for or need features, have them justify their need.
- Users want Swiss Army knives and multitools, and then complain when they are not robust enough for a singular functionality.
Frustration 6: Bigger Issues Than Hreflang
“Sometimes, solving hreflang wasn’t the real blocker, it was uncovering all the broken plumbing behind it.”
One of the more stressful and sensitive patterns we saw was that implementing Hreflang Builder often revealed far more significant and fundamental issues. In some cases, these discoveries completely derailed projects. Teams would panic—not about fixing the problems, but about who would find out the issues existed.
One project involved setting up hreflang for 12 site variations, each with country and language folders buried at the fifth and sixth levels, some with region-specific structures and language-specific parameters. When we asked why it was built this way, the answers ranged from organizational hierarchy to CMS limitations, licensing structures, and local market requests.
At a deeper level, the URL structure chaos was often driven by:
- Keyword-rich folder names (SEO “best practices”)
- Varying localization approaches
- Fragmented site merchandising models
- Different CMSs across markets—sometimes 3, sometimes 17
One time, after presenting a visual URL structure matrix, I jokingly told the SEO Team, “Your URLs look like monkeys threw spaghetti at the wall.” That line earned me a summons from the CTO, who insisted their structure was crafted with precision and called it “pure elegance.”
I replied: “It’s elegant like a Pollock painting.” Then I showed her the real-world matrix. To her credit, the CTO laughed and said, “Actually… the monkeys may have done better.”
In fairness, not all structural chaos is dysfunction. Some companies use different CMS or pods within a build due to legal, tax, or regional compliance needs. But these pods can’t share schema or IDs—so even the best-intentioned structures fall apart.
The result? Hreflang is the least of their problems—but they don’t know it until we show them.
What I Tried:
- Built a diagnostic process to identify roadblocks and dysfunction early in the sales process to address these challenges and propose a phased approach to implementation.
- Both detail the issues and withhold the problems during the sales process to minimize the potential for challenge paralysis that delays projects.
- Understand the limitations of the agency’s scope of work or the dev team’s resources to soften the implementation-challenge message.
What I Learned:
- Hreflang Builder implementations were often the flashlight, not the fire.
- Some organizations are more afraid of accountability than failure.
- Most global Dev teams are unaware of the challenges within their tech stack.
- We needed to set the stage for a phased approach in every case, allowing time for the client to address identified issues.
💥 The Realization – I was part of the problem
I completely Ignored My Prior Experiences
I’d seen these patterns before in enterprise SEO consulting and past software development projects, but didn’t let that experience steer me differently. The clarity of the problem blinded me; I thought it would be easier to sell. It wasn’t.
I Cared More than a SaaS Founder should
Knowing the potential business value to the client made inaction harder to swallow. I felt a personal responsibility when smaller companies couldn’t fix obvious problems because of stubborn gatekeepers. I knew I could help them, and I felt as if I had failed when we did not even have the opportunity to do it.
Not Jumping the Chain of Command
My biggest regret: not escalating when mid-level managers blocked progress. Many times when we were spinning our wheels with mid-level management, I would think that if the CEO or CMO only knew they were losing this much money every month, they would mandate a fix.
I knew how I felt when people jumped me, leveraging their B-school buddy to sell a tool or solution. Learned as a Marine, you don’t jump the chain of command, and agencies guard their clients fiercely—but sometimes the only path to resolution is higher up.
Function Over Aesthetics
During the presentation of Hreflang Builder to potential buyers, the first thing everyone said was I would change the interface, color scheme, and one even wanted to rename it the 30-second hreflang creator.
We prioritized functionality over polish because most of our clients are set up by us and are semi-automated, with the average client never logging into the system. If they or their agency isn’t using the solution, do we need to make it look good? It is not a tool you use every day for reporting.
💥 The Realization
If I did it again, I would be smarter:
To me, Hreflang Builder wasn’t just about maintaining software and building the brand; it was about solving real-world problems. That client empathy was a strength and a burden. I’d get emotionally involved. I took rejection personally. I got frustrated when people didn’t care about solving their million-dollar problems.
I still believe in what we built, and hreflang is one of the most underappreciated levers in international SEO. It is even more unfortunate that, despite the hype surrounding AI search, hreflang has received little to no mention, and I have seen many global websites leaking value due to poor implementation.
Most SaaS founders wouldn’t lose sleep over failing to solve someone’s problems and would instead find a way to turn their dysfunction to their advantage.
But if I were to do it again?
- I’d build in guardrails from day one to counter the cross-department pettiness.
- I’d vet partners more carefully and mandate client access.
- I’d set firmer boundaries around support and reduce the number of features and customizations implemented.
- I’d accept that not every problem is mine to fix – have a reminder that you can lead a horse to water…
- I would hire that pitbull salesperson and let them break all of the rules
Because in the end, you can only solve the problem if they let you.
Originally Published on my Substack Signal and Friction
