CascadeGTM Thoughts
Buy, Build, or Vibe Code
The GTM tech stack buy -vs- build answer changed eighteen months ago and it just changed again. Here is how I decide what to buy -vs- build in a GTM stack today, with an interactive matrix you can work through by stage, from pre-revenue to +1B ARR.
By CascadeGTM, GTM strategy and revenue engineering. Published June 2026.
For decades, growth stage companies have wrestled with one question. Build it, or buy it. For most of those years the answer stayed clear. You bought, unless you had a surplus of skilled engineers to spare or a business critical problem you could not solve any other way. The logic held. The engineers who can build a high performance revenue engine can also build your product, and your product is what wins customers and builds your moat. Internal tools do not. So you bought your stack, and you pulled engineers onto attribution, scoring, or routing only when you had no other option, usually with some reluctance.
That logic started to crack about eighteen months ago. Over the last six months it broke. The matrix below gives you my call for every category at every stage. Then I walk through what changed, what to do in your next budget cycle, and the rule that holds it all together.
What changed in the last eighteen months, and the last six
Two shifts moved the line, and they are not the same shift. Read the markers, not every word.
Eighteen months ago
Building got faster
AI coding assistants got good enough to matter. Cursor, GitHub Copilot, and Claude wrote real code, and a developer shipped a working tool in a fraction of the old time. Build cost fell by half or more.
Maintenance cost did not move. So the math still favored buying anything you planned to run for years. Forrester's 2024 research is the reason why. Seventy eight percent of a software product's lifetime cost lands after launch, and upkeep runs 15 to 20 percent of the build budget every year.
The last six months
The agents started maintaining the build
Coding moved from autocomplete to agentic. Claude Code, Claude Cowork, and tools like them now plan, write, test, deploy, and refactor on their own. They do the unglamorous work that used to eat your engineers.
Claude Fable 5, released June 9, 2026, shows the ceiling. Simon Willison called it something of a beast
. He handed it a real senior engineer task, it finished the work, found and fixed four issues in his underlying library, and wrote the tests and the docs. A few hours of his time turned into what felt like several days of work. Fable scored 80.3 percent on SWE-bench Pro at launch.
The new risk, model access moves
Three days after launch, a US export control directive forced Anthropic to suspend Fable 5 for every customer worldwide. Build on a single frontier model with no fallback, and a policy change takes your tool offline overnight. So build, and keep your model layer swappable.
Today
What I would build now that I would not have six months ago
I told teams to buy enrichment, attribution, and competitive intel, because the build was cheap and the upkeep was not. Today I build them. A research and enrichment agent that replaces three point tools. A lead scoring model wired to your data, with the agent writing the tests and docs. A competitor monitoring agent that repairs its own scrapers. An internal agent that answers questions across your CRM and warehouse. Each was a maintenance headache six months ago. Now the agent carries that load and one GTM engineer keeps the set running.
Most teams are running AI experiments right now. Most of the SDR pilots this year were exactly that, pilots that never scaled. A pilot is not a revenue engine. Building is easier than it has ever been and the tools are more powerful than ever. With the right GTM engineer, you build differentiating tooling and a revenue engine efficient enough to carry you to your next growth horizon.
What to do in your next budget cycle
Walk into planning with a clear position by role.
CFOs and founders
Treat buying as a predictable line item with vendor support behind it. Treat building as an asset you staff, secure, and maintain. Fund a build only above the roughly sixty thousand dollar a year mark, because below that the subscription costs less than the engineer hours to build and run your own version, and fund it only where it compounds into an advantage you keep. Then fund the person who makes building pay. Add headcount for a senior GTM engineer, the profile who builds your revenue engine with LLMs doing the heavy lifting. Pay them like the engineers they are. GTM engineers earn engineering grade salaries, and the strong ones carry variable pay tied to pipeline produced or revenue booked, which keeps the build pointed straight at the number.
CROs, CMOs, and CCOs
Build only when the work is a core differentiator that moves pipeline, win rate, retention, or cash collected in a way buying cannot. Everything else is a buy. And make sure a true GTM engineer supports the team, because a build without an owner becomes an outage with your name on it.
GTM ops and engineering
Hold a clear line. Buy commodities, and never spend your hours rebuilding a CRM or a billing system. Build the differentiators that amplify revenue, the scoring, the routing, the signal work that matches how you sell. Then manage what you build. Promote the few builds that earn their place onto one maintained layer with a named owner and an off switch. Take a hard look at your roadmap and cut the builds that do not pay. Most teams are running experiments right now, so protect real time for maintenance, because the build you shipped last quarter still needs you this quarter.
My rule still holds, buy to reach revenue, build to defend it
The tools changed. The rule did not. Buy the things that get you to revenue. Build the things that defend and grow it. Commodity infrastructure is a buy, because every competitor has the same options and you gain nothing by writing your own. Your edge lives in the connective tissue, the scoring, the signal routing, the workflows that match how your team sells. That is where a build earns its keep.
Six questions I ask before any build
- Is this a core differentiator for us, or a commodity everyone has?
- Does a category leader already solve it well at our size?
- Who owns this after launch, and do they have the time?
- What is the security and compliance exposure if we own it?
- What is the real five year cost, including maintenance and the engineer's hours?
- Does building move pipeline, win rate, or retention in a way buying cannot?
If you cannot name the owner in question three, stop. You do not have a build. You have a future outage with your logo on it.
Where building pays across the GTM stack
I mapped all seventeen categories in the matrix at the top of this page. Tap any cell to see the call at that stage, the default tool, the cost, and for every build, the exact stack a GTM engineer would use. A few patterns hold no matter the company.
The hard buys you should never build
Some categories stay a buy at every stage. Billing leads that list. Payments and revenue recognition carry PCI scope and ASC 606 rules, so you buy Stripe and move on. Conversation intelligence is a buy because the transcription quality and the model are the vendor's moat. Contact data is a buy because no one out researches a database with hundreds of millions of verified records. CRM, CPQ, marketing automation, and sales enablement round out the group. Building any of them spends your scarce engineering time on a problem solved years ago.
The real build candidates
The build zone is narrow and specific, and that is the point. Lead deduplication tuned to your data. A signal routing layer on a raw intent feed. Custom attribution that weights touchpoints the way your deals close. A competitor monitoring agent. Customer health scoring on your product usage. Each sits on bought infrastructure and runs on data only you have. That is the test. Build where your data makes the output better than anything on the market, and read the data architecture work that has to come first.
Building got cheap. Owning still costs. The companies that win treat that gap with respect. They buy to reach revenue, build to defend it, and maintain what they build. If you want help drawing that line for your own stack, start a conversation with us.
Common questions
Should I build or buy GTM software?
Buy the tools that get you to revenue and build the ones that defend it. Commodity infrastructure like CRM, billing, contact data, and call recording is a buy at every stage. Build only where your own data makes the output better than anything you can purchase, and only when you have a GTM engineer to maintain it.
Has AI and vibe coding changed the build versus buy decision?
Yes, and it changed twice. Around late 2024, AI assistants cut the cost of building. In the last six months, agentic tools started doing the testing, deployment, and maintenance too, which lowered the upkeep that used to make buying the safe call. Builds that did not pay six months ago pay now, as long as you keep a model fallback and a named owner.
When does building software become cheaper than buying?
Building turns competitive with buying around the point where you spend about sixty thousand dollars a year on a tool. Below that, buying wins on total cost once you include maintenance, which Forrester puts at 15 to 20 percent of the build cost every year.
What GTM tools should you never build in house?
Never build billing, CRM, conversation intelligence, contact databases, CPQ, marketing automation, or sales enablement. They carry compliance exposure or rest on data and scale that vendors already own. Work through the full breakdown in the matrix at the top of this page.
Do I need a GTM engineer to build internal tools?
Yes. Without an owner for the work, a custom build becomes a future outage. GTM engineering job postings grew 205 percent in 2025 because builders who own revenue systems are now the constraint, not more manual headcount.
How much does it cost to maintain custom software?
Plan for 15 to 20 percent of the original build cost each year, plus the opportunity cost of the engineer doing upkeep instead of new work. Forrester found that 78 percent of a software product's lifetime cost lands after launch.