Buy vs. Build, Revisited: Rethinking the Question in the AI Era
For most of the last twenty years, the answer to "buy or build?" in the Salesforce world was almost automatic: buy. Building was slow, expensive, and risky. Buying a managed package or add-on meant speed, a vendor roadmap, and someone else's problem when things broke.
That math has changed. AI-assisted development has collapsed the time and cost it takes to build well-structured, well-documented solutions on the platform. We think it's time to ask the question again, honestly, instead of defaulting to the answer we've always given.
The easiest way to think about it is the choice every homeowner eventually faces: buy an existing house, or build one.
Buying an existing house is fast. You tour it, you make an offer, you move in. But you also inherit every decision the previous owner made. The formal dining room you'll never use. The fourth bedroom you're heating and paying taxes on. The kitchen layout that almost works. From the first week, you're rearranging your life around the house instead of the other way around.
Building a house used to be the option reserved for people with deep pockets and a lot of patience. It took longer, it cost more, and there was real risk it wouldn't come together. But when it was done, every room existed because you needed it.
In software, the cost of building just dropped dramatically. The patience required did too. That changes which option makes sense.
The move-in-ready house: what CPQ taught us
Salesforce CPQ is the clearest example we know. Yes, it has reached end of sale, and Salesforce is steering customers toward Revenue Cloud. But the lesson outlives the product, because the same pattern shows up in almost every large package.
We have implemented and supported CPQ for years. In that time, we have never had a client use every feature in the package. Most use a fraction: product rules, some pricing logic, a quote template. Yet every one of them pays for the whole house.
The cost doesn't stop at the license:
You pay for rooms you never enter. Advanced approvals, multi-dimensional quoting, subscription amendments, usage pricing. If your business doesn't need them, they still come with the price tag and the complexity.
You fund renovations you didn't ask for. Every release and update carries development time for features that may never touch your use case. Some of your spend goes to someone else's roadmap, and some of your team's time goes to regression-testing changes that don't matter to you.
You start rearranging furniture on day one. Because the package was built for everyone, it fits no one exactly. We routinely see workarounds designed into the first implementation: a custom field here, a Flow that fights a package trigger there, a pricing plugin that exists only to bend the out-of-the-box logic into shape.
That last point is the one we don't talk about enough. When a project starts with workarounds, you haven't bought a solution. You've bought a starting point you have to fight against.
Building is faster than it used to be: Stellar Roofing
A recent project with Stellar Roofing shows what building looks like now. Stellar needed a way for reps to build roofing estimates, bundle products the way crews actually install them, and carry that estimate all the way through to the signed agreement, the project, and rep commissions.
The traditional answer would have been a quoting package plus a stack of customizations to make it speak roofing. Instead, we built an estimating solution natively on their Salesforce org, designed around how Stellar sells:
Estimates and estimate lines built for roofing, including product bundles and bills of materials
Estimate details that flow directly into the SOW and customer agreement
Commission calculations, including floors, driven from the same data
Connections into the tools their field team already uses
There was no package to fight and no features to pay for that Stellar will never use. When Stellar's team asks for a change, like adding line item descriptions to the SOW or allowing discounts at the estimate header and the line item level, we change the solution itself instead of looking for a workaround inside someone else's product.
AI-assisted development is what made this practical. Work that would have taken a team months to design, write, test, and document now moves in a fraction of the time. That shift is the whole reason this conversation is worth having again.
"But who maintains it?"
This is the objection we hear most, and it's a fair one. Clients tell us they take comfort in a package because there's a larger knowledge pool behind it: other customers, community forums, consultants who have seen the same configuration a hundred times, a vendor support line.
We understand the appeal. But look at what that knowledge pool actually gives you. It gives you general knowledge of a product that was built for everyone. It doesn't know your workarounds. It can't see inside the package's code. When something breaks at the seam between the package and your customizations, the community answer is usually "it depends," and the vendor answer is often "that's outside of standard functionality."
With a solution you own, the knowledge pool is different, and in the ways that matter, deeper:
You have the entire codebase. Nothing is locked, hidden, or managed. Every rule, calculation, and automation is visible and changeable.
It's documented for your business, not the market. The solution only does what you need it to, so there is far less of it to understand.
AI changes the maintenance equation too. The same tools that speed up the build make it easy for any capable admin or developer to read, explain, and safely modify code they didn't write. The "only the original developer understands it" risk is much smaller than it used to be.
Upgrades happen on your schedule. No package release will change behavior you rely on without your say.
In house terms: owners of a custom home don't worry that nobody else has the same floor plan. They have the blueprints.
Where to draw the line: why not build your own CRM?
If building is this much faster, the natural next question is: why stop at add-ons? Why not skip Salesforce entirely and build your own CRM?
Because even people who build custom homes don't manufacture their own land.
Salesforce is the plot of land. It's the foundation, the utilities, and the zoning that make building possible: security, identity and access, the data model, sharing rules, automation, reporting, mobile, integrations, AI, and a platform that stays up and passes audits. None of that is what makes your business different, and all of it is expensive and risky to recreate. That work is already done, and it's maintained by thousands of engineers whose whole job is keeping the ground solid.
What sits on top of that land is where your business lives: how you quote, how you estimate, how you hand work to the field, how you pay your reps. That's the house. And that's where building now makes sense.
So our recommendation isn't "build everything." It's this: buy the land, build the house. Buy the platform and the commodity services that every business needs in the same way. Build the parts that reflect how your business actually works.
When buying the house is still the right call
None of this means packages are the wrong answer. It means they shouldn't be the automatic one. Some businesses tour the move-in-ready house and find it fits: they will live in nearly every room.
Revenue Cloud is a good example. For companies whose revenue model is the complex, standard-shaped one it was designed for, the breadth of the product is the point. That means subscriptions, amendments, renewals, usage-based billing and multi-entity invoicing. Those clients aren't paying for rooms they'll never enter. They're buying years of Salesforce investment in problems they would otherwise have to solve themselves.
It also sits differently than CPQ did. Revenue Cloud is built on the core platform rather than installed as a separate managed package on top of it. That puts it closer to the land than to a house someone else designed.
The test is the same either way: how much of it will you actually use, and how much will you spend working around the rest? If you asked that question and the answer was "buy," you did exactly what this post is arguing for.
What still makes sense to buy
Some things are the plumbing and wiring of the house. You want them done to code, certified, and backed by someone whose entire business is getting them right. A good rule of thumb: buy it when the value comes from compliance, a network, or regulated infrastructure rather than from your process.
E-signature: Legal enforceability, audit trails, and compliance standards are the product. Nobody wins by rebuilding them.
Payment processing: PCI compliance, fraud protection, and bank relationships are regulated infrastructure.
Tax calculation: Rates and rules change constantly across thousands of jurisdictions.
Address validation and data enrichment: The value is the vendor's data set, not the software.
Email and SMS delivery: Deliverability depends on sender reputation and carrier relationships you can't build.
Accounting and ERP: A system of record with its own audit, reporting, and regulatory requirements. Integrate it, don't recreate it.
Security, identity, and backup: The cost of getting it wrong is too high to be a first-time builder.
Notice what these have in common: they are the same for everyone. The moment a tool needs to reflect how your business works, the balance tips back toward building.
Asking the question again
The buy vs. build decision used to be a question of cost and speed, and buying usually won on both. AI has narrowed that gap to the point where the better question is fit: how much of this will we actually use, and how much will we spend working around the rest?
Before your next package renewal or new add-on purchase, ask:
What percentage of this product's features do we use today?
How many workarounds did we build to make it fit?
Is this a commodity service every business needs the same way, or does it reflect how we work?
If we owned the code, what would we change first?
If they point toward a package, that's a good answer too, as long as it's a decision and not a default. Salesforce is an ecosystem. Let's treat it as one, and build the house that fits on it.