I used to think my breadth was my strength. I was wrong. Here’s the story of my pivot to E-com.
One of the biggest lies we’re told when starting a business—whether you’re a freelancer, a solopreneur, or building an empire—is that “Reach is King.” We’re taught to cast the widest net possible, hoping to catch anything that swims.
But here’s the truth I’m learning the hard way: A net catches everything, including the debris. A filter only lets in what belongs.
I’m not writing this as a “guru” with a polished exit strategy. I’m an entrepreneur in the middle of the mess, sharing the bruises I’m getting in real-time. This week, the bruise came from a “Yes” that should have been a “No.”
The Story: The “Digital Handyman” Trap
I’ve always tried to live by a simple philosophy: Accept a grain less, but always deliver a grain more. I believe in over-delivering. But recently, I took on a client where that philosophy backfired spectacularly.
This client wasn’t very tech-savvy. I was brought in for Web Development and Data Analysis—my core expertise. However, because they saw me as “the tech guy,” the boundaries started to dissolve.
Suddenly, I wasn’t just building a site or analyzing data; I was neck-deep in the “IT” side of software. I found myself migrating legacy emails between CRMs, troubleshooting third-party platform quirks, and fixing software configurations that had nothing to do with my actual project. At a glance, it was “tech work,” but it wasn’t my tech work.
I was spending hours researching CRM backend bugs just to keep the project moving. Instead of delivering that “one grain more,” I was delivering 10x more—solving problems that weren’t in my domain, my contract, or my long-term interest. I had become a digital handyman, and I was drowning.
The Hard Conversation (and the Fallout)
I reached a breaking point. I realized that if I kept playing the handyman, the quality of my actual web dev and data work would suffer. I had to have the “Hard Conversation.”
It was brutal at first. When I sat the client down to explain that I needed to step back from the general software troubleshooting, their response was harsh. They didn’t see the difference. To them, “tech is tech,” and they felt I was being difficult or pulling back on my commitment. There was a real moment of tension where I thought the whole relationship would implode.
It actually took a third party—a mutual business contact—to step in as a “translator.” They had to explain the difference between a Technical Architect and a Support Technician. Once the client realized that by forcing me into the “technician” role, they were actually sabotaging the high-level data strategy they were paying for, the air cleared. They finally understood that I wasn’t doing less; I was fighting to provide more of what actually moved the needle.
The Insight: The Bitter Pill of Specialization
This experience forced me to look at my own positioning. We’re conditioned to think “repel” is a bad word, but if you don’t repel the wrong tasks, you’ll never have the space for the right work.
I learned this the hard way when I first integrated Business Intelligence into my web dev stack. I struggled because my portfolio had plenty of breadth but zero depth. I had the tools, but I was constantly overlooked for freelancers with more domain knowledge.
I had to swallow a bitter pill: Having the knowledge to analyze data is pointless if you don’t understand the domain well enough to provide meaningful business insight. You can’t just be a “data guy.” You have to be the guy who understands the business of the person you’re helping.
After weeks of research and some soul-searching, I landed on E-commerce. Having built several e-commerce sites, I knew the domain inside and out. My years as a developer taught me how to optimize for traffic and performance; pairing that with data analysis felt like the decision that had been sitting in front of me the whole time.
By narrowing my focus to E-commerce, I finally built a filter. I wasn’t just “the tech guy” anymore; I was a specialist. And specialists don’t get asked to fix email migrations.
The Strategy: The “Fit Framework”
I’m now using this “Yes/No” framework in my outreach to avoid the handyman trap. It feels risky to be this blunt, but it’s the only way to protect the work.
| Best Fit if… | Not a Fit if… |
|---|---|
| You need high-level Web Dev or E-com Data Analysis. | You need a generalist for CRM migrations and email troubleshooting. |
| You respect the distinction between development and general software support. | You expect 10x output on tasks outside the agreed-upon domain. |
| You value strategy and a long-term partnership. | You’re looking for a “tech-fixer” for administrative software chores. |
Your Turn: Build Your Filter
If you feel drained by your current “catch,” it’s time to change your net into a filter. Don’t wait for a client to get angry or for a 2 AM email migration to realize you’ve over-promised.
Action Prompts:
- The “Domain” Audit: What’s the last task you did that made you think, “This isn’t why they hired me”?
- The 3/3 Rule: Draft 3 “Best Fit” and 3 “Not a Fit” statements. Be brutally honest about your scope.
- The Placement: Put these on your website or mention them in the first 10 minutes of an intro call.
I’m still figuring this out. I’m still learning how to set boundaries without feeling like I’m “failing” the client. But the empire I want to build doesn’t have room for everyone—and that’s exactly why it will be worth building.