Three-year total cost
Implementation, maintenance and internal time, for each option.
- Home
- Consulting
- Build vs buy advisory
Build vs buy advisory
Build versus buy, modeled on your actual numbers.
Build versus buy is usually argued with anecdotes and decided by whoever is most confident. We model it: total cost at your real volumes over three years, what each option constrains, and what happens if you change your mind later.
- 3-year cost model
- Vendor evaluation
- Lock-in risk
What you get
Two options, compared on the same terms.
Tested against growth
Sensitivity to volume, where per-row pricing often breaks.
An honest capability check
Whether your team can realistically own a build.
Lock-in, priced
What leaving costs, and whether your data comes with you.
The problem
Both sides quote the number that suits them.
The buy case counts the license and ignores implementation, integration and the engineer who ends up maintaining it anyway. The build case counts the initial sprint and ignores that maintenance runs forever and the person who built it will eventually leave. Neither models the volume growth that changes the answer entirely, and neither prices the switching cost if the decision proves wrong. So a decision worth hundreds of thousands over three years gets made on two incomparable numbers.
What the analysis covers
What's included.
- Three-year total cost of ownership for each option, including implementation, maintenance and internal time
- Sensitivity analysis on volume growth, since per-row and per-profile pricing often breaks at scale
- Vendor evaluation against your actual requirements, separating must-haves from demo features
- Capability assessment: whether your team can realistically own a build, honestly stated
- Lock-in and exit analysis, including what leaving costs and whether your data comes with you
- A clear recommendation with the reasoning and the assumptions exposed for challenge
How we work
How we run it.
Step 1
Define requirements precisely, separating what you need from what a demo made appealing
Step 2
Model total cost for each option at current and projected volumes
Step 3
Assess your team's capacity and appetite to maintain a build, which is usually the deciding factor
Step 4
Present the comparison with assumptions visible, so your team can test the conclusion
What we use
Tools, platforms and methods.
- TCO modeling
- Vendor evaluation
- Requirements analysis
- Architecture review
Related work
Projects we've delivered.
120+ automations live
Tinuiti
We rebuilt the ETL, warehouse and automation layer across Amazon, Walmart, TikTok, Instacart and Criteo.
Read the case study
Risk scores in 5 min
Protego
We built Protego's SP-API backend: secure OAuth, ingestion pipelines and the Reports API workflow.
Read the case study
50+ campaigns, one dashboard
BTR Media
We built ETL pipelines into one data model and one dashboard for Amazon, Walmart and Instacart campaigns.
Read the case studyFAQ
Common questions.
Aren't you biased toward recommending a build?
It is a fair question given what we sell, so the analysis exposes every assumption for you to challenge. In practice we recommend buying more often than not: for standard problems with mature products, buying wins clearly. Building wins where the capability is genuinely differentiating, where per-unit vendor pricing breaks at your scale, or where no product fits without heavy customization.
What do teams most often get wrong in the model?
Two things, consistently. On the build side, treating maintenance as near zero when it is typically a meaningful ongoing fraction of the initial cost, every year. On the buy side, ignoring how usage-based pricing scales, which is how a comfortable contract becomes the largest line item in the data budget within two years.
Can you evaluate specific vendors we are considering?
Yes. We assess them against your written requirements, dig into pricing mechanics at your projected volumes, and identify contract terms worth negotiating. We take no vendor commissions or referral fees, which is what makes the assessment worth having.
What if the answer is a mix?
It frequently is, and that is a legitimate recommendation. Buy the commodity layer, build the differentiating part. What matters is drawing that line deliberately rather than ending up with a hybrid nobody designed.
Related
Related services.
CDP architecture
Identity resolution, unified profiles and consent-aware activation in your warehouse.
Learn moreData maturity audit
A written assessment of your data stack and a prioritized roadmap, in 2 to 3 weeks.
Learn moreHow we work
A fixed-scope build first, then we run it monthly or hand it to your team.
Learn moreModel the decision properly.
Tell us what you are choosing between and we will model total cost and risk at your real volumes.