A few months ago I watched two grown men get giddy like kids over a dictation app and a work-in-progress report. That meeting redirected my practice. This is the story of why I went narrow, and what it taught me about the difference between software that solves a problem and software that fits a business.
Two grown men, giddy over a WIP report
I was sitting in the office of a custom home building company with the owner and his lead project manager. We were working through where AI could fit their operation, and I showed them a small thing first: a voice dictation tool called Wispr Flow. You talk, it types, cleaner and faster than most people can write.
They loved it. Grown men, decades in construction between them, grinning at a dictation app.
Then we opened their WIP report. If you're not in construction, the WIP is the document that tracks every active job: costs to date, what's been billed, how complete the work actually is. It's the heartbeat of a building company, and in most of them it's assembled by hand, late at night, from systems that don't talk to each other.
And something shifted in the room. They stopped asking me questions and started talking to each other.
What if the job costs flowed in on their own. What if the report built itself. What if the Monday meeting started with answers instead of assembly. Within a few minutes they were sketching automations I hadn't suggested, finishing each other's sentences, and then the owner said the thing that stayed with me: with this in place, they could take on two or three more projects with the same team.
And then, quieter: they could stop working twelve and fourteen hour days.
That was the moment.
These are not men who get excited about technology. They are practical, direct, no-nonsense people who have been sold a lot of software over the years. What lit them up wasn't the tools. It was seeing their own company, the one they already run, working the way it always should have.
The market research came second. The joy came first.
I drove home from that meeting knowing something had changed, and then I did what I always tell my clients to do: I checked the feeling against the facts.
The construction software market is crowded. Estimating tools, scheduling tools, client portals, accounting add-ons. What I could not find, anywhere, was what happened in that room: software architected around how one specific builder actually runs their jobs, end to end, with AI doing the connecting work between the pieces. For companies at this size, it simply did not exist.
There was something else in the research I almost didn't write down, because it doesn't show up in any market analysis: I like these people. Builders are down-to-earth, funny, practical, and direct. They say what they mean, they decide fast, and they have no patience for theater. That fits me.
Who you enjoy serving is a legitimate business criterion. Nobody puts it in the spreadsheet. It belongs there, because you will do your best work for the people who give you energy, and your worst work for the people who drain it.
So I made the call. I kept my consulting practice deliberately small, a few executive leadership teams at a time, and pointed everything else at one industry.
Software that solves a problem is not software that fits a business
Here is what I found inside every building company I sat with, and what I suspect you would find inside your own organization if you looked with fresh eyes.
They all have software. Plenty of it. Each subscription was bought to solve a real problem, and each one did solve that problem, more or less. But solving a problem is not the same as fixing how the business runs. The estimating tool doesn't know what the accounting system knows. The schedule lives in one place and the truth lives in another. The team fills the gaps with spreadsheets, re-typed data, and workarounds, and the owner fills the rest with hours.
The vendors aren't villains. This is economics. Software built to serve ten thousand companies has to serve the average of them, and nobody runs the average company. So every generic tool asks your operation to bend toward its workflow, and every bend costs you something: a double entry here, a workaround there, a person whose actual job has quietly become feeding the software.
The root problem, how the whole business runs from first call to final invoice, stays untouched. It was never the vendor's problem to solve.
What changed is that custom software is no longer reserved for the enterprise. Building software shaped precisely to one company's operation used to cost seven figures and take years, which is why only giants had it. AI collapsed that cost. A mid-sized operation can now have software that fits it the way the enterprise always could. That is the work I do for custom home builders now, under a company I started called Ridgebeam.
Going narrow felt like shrinking. It was the opposite.
For years I resisted specializing, and my reason was the same one I now hear from every leader who resists it: narrowing feels like turning away opportunity.
Here is what actually happened when I went narrow.
Every conversation started compounding. When you serve one kind of business, you stop translating and start recognizing. The second builder's WIP problem looks like the first builder's WIP problem. The pattern library grows. The tenth conversation is an order of magnitude more valuable than the first, because you arrive already knowing where the bodies are buried. A generalist starts every engagement at zero. A specialist never starts at zero again.
Depth is also what makes custom possible at all. You cannot build software around how a business actually runs unless you deeply know how that kind of business runs. Breadth produces templates. Depth produces fit.
Specializing was the whole answer. Not a marketing tactic, not a positioning exercise. The narrower the focus, the deeper the knowledge, the better the work, the stronger the results, the more the work gives back. That flywheel does not spin for generalists.
What this means if you lead an organization
Two questions worth sitting with this week.
First, audit your stack for bent workflows, not for features. Walk through one core process and count the places where your team is serving the software instead of the software serving the team: the re-keyed data, the bridge spreadsheets, the report someone assembles by hand because no system holds the whole truth. That count is the real distance between what you bought and how you run. The question to bring to every tool, and every vendor, is not "does this solve the problem" but "does this fit how we actually operate."
Second, ask where you are staying broad because narrow feels risky. In your offers, your markets, your own role. The math that worked on my practice works on organizations too: depth compounds, breadth resets. Most leaders I sit with already know the narrow thing they should commit to. What they lack isn't insight. It's permission.
The part I didn't expect
I went into that builder's office to talk about AI. I walked out having found the direction of my next decade, and it had less to do with technology than I would have guessed.
What decided it was the giddiness. Two practical men seeing their own company handed back to them, imagining dinner at home instead of a 7pm job-cost meeting. I get to cause that feeling, in an industry full of people I genuinely like, doing work nobody else is doing.
That's the joy. That's the purpose.
The narrower I went, the bigger the work became.
