A year ago, if you needed software inside your company, you had two options: buy it or wait for engineering to build it. Today, there’s a third option emerging, and it’s quietly breaking that model – you just build it yourself. That’s what made my recent conversation with Bill Buecksler so interesting.
Bill is a go-to-market leader at 1Mind, not an engineer by training, and yet he recently committed his first GitHub repo and built a working internal tool in a few hours that replaced what would have historically been an ~$80K-$100K SaaS purchase. The interesting part isn’t the tool itself, it’s what it implies: the people closest to the problem can now solve it. For years, there was a structural gap inside companies between the people who understood the problem (sales, CS, ops) and the people who could build the solution (engineering), and that gap created friction – requirements docs, tickets, backlogs, months of lag, and often missed context. By the time something shipped, it was already outdated. AI collapses that gap.
The operators in the trenches, the ones talking to customers every day, now have the advantage because they know exactly where things break, and for the first time, they can actually fix it. What’s changed isn’t just the ability to build, it’s the workflow itself. The biggest misconception right now is that AI building is about typing one prompt and getting an output, but the real unlock is the conversation before the build – treating AI like a thought partner, asking it to challenge your assumptions, letting it ask clarifying questions, refining the spec together, and only then executing. That back-and-forth is where the leverage is. Not the code.
This shift also breaks the default build vs buy decision. The question used to be “which tool should we purchase?” and now it’s increasingly “should we just build this ourselves?” especially for internal tools. Bill’s example is telling: a simple internal RFP and infosec workflow, built in a few hours, minimal engineering involvement, replacing a six-figure SaaS contract. That’s not a one-off, that’s going to happen everywhere.
But it doesn’t mean build everything. There are still constraints – latency tolerance, token costs, maintenance overhead – so the real skill becomes knowing what’s worth building. This is where things get uncomfortable for SaaS. If your product is essentially a UI on top of a database with some conditional logic, it’s now reproducible quickly and cheaply by non-engineers , which means feature-based moats are collapsing. What’s left are the things that don’t replicate easily: proprietary data flywheels, network effects, deep workflow integration, and trust. Everything else is getting commoditized.
At the company level, this creates a new decision point: do you centralize AI in a small “center of excellence” team, or do you empower everyone to build? OneMind made a clear bet on the latter, training the entire company and giving everyone access, not because it’s cleaner, but because it’s faster . And in this environment, speed is the advantage. The best ideas don’t come from a centralized team, they come from the people closest to the problem. So if you’re in sales, marketing, or ops, the question isn’t whether you should learn this, it’s where to start.
The answer is simpler than people think: start with friction. What’s repetitive, manual, or slowing you down every day? Use AI as a thought partner to pressure test it, refine the idea, and then build. Because the one thing AI can’t generate on its own is context, and that’s the one thing you already have. When building becomes easy, the constraint shifts. It’s no longer “can this be built?” it’s “is this worth building?” and that’s where the next generation of builders will differentiate.
Full episode here: Link