ConceptIntermediateAI Opportunity & Model Strategy / Build vs buy vs fine-tune decisions / #22
Explain when the right answer is buy the platform and build the workflow on top.
SPARKthe vendor's case studies proved their model works on someone else's normal
Redwingate Legal handles contract work for corporate clients across nine internal practice groups. Statuvane is the contract platform they bought: storage, e-signature, version history, audit trail. DocketFlow is the thin layer Teodora Ionescu's team built on top, to route a new matter and flag risky clauses using Redwingate's own history, something no vendor's platform could ever know on its own.
The direct answer
Buy the platform for whatever every company in your position needs the same way: storage, workflow engine, audit trail, e-signature. Build only the layer where your own process, your own categories, your own client rules, is the actual thing that makes you different. If you can point to the exact judgment call that only your company's history can answer correctly, that's the one piece worth building. Everything underneath it is worth buying.
Do this, in order
Buy every capability that's identical for every company in your position.Why: storage, e-signature, and audit trails aren't where your edge lives, and building them is wasted effort.
Name the one judgment call that depends on your own history, and build only that.Why: a vendor's generic model was never trained on the categories that make your company different.
Test any vendor's "smart" feature against your own historical data before trusting it.Why: their case studies prove it works on someone else's normal, not yours.
Give the built layer a visible reason for every call it makes, plus a fast way to override it.Why: it turns a wrong call into a one-minute fix instead of a four-day mystery.
Keep the built layer thin. Don't let it creep into things the platform already does well.Why: rebuilding solved plumbing wastes the exact budget the build side needs most.
Say plainly what you won't automate yet, and why that's safe.Why: it shows judgment, not a wish list, and keeps trust calibrated to what's actually proven.
How to answer this, stage by stage
Nobody is scoring whether you can list build-vs-buy pros and cons. They're scoring whether you can point to the exact seam where "buy" should end and "build" should start.
Stage 1
Scope it to one real system
Say it like this
"Let's ground this in one real system. Redwingate Legal needs contract lifecycle management: storage, e-signature, an audit trail, and a way to route every new matter to the right practice group with the right risk flags. That's the exact system I'd split into buy and build."
Why this works
Keeps the answer from becoming a generic "sometimes you buy, sometimes you build" shrug with nothing real underneath it.
Stage 2
Say the structure out loud
Say it like this
"I'll run this as SPARK. Situation, how the work gets done today, without any tool. Payoff, the habit I actually want the system to build. Anchor, the one concrete design decision. Risk, what breaks the first time it's wrong. Keep out, what I deliberately won't build yet."
Why this works
Signals a repeatable design method, not a one-off gut call about which vendor demo looked impressive.
Stage 3
Reframe: it isn't "buy or build," it's "which layer is the plumbing"
Say it like this
"This isn't really a question of whether to buy or build. It's a question of which layer of the system is generic plumbing every firm needs the same way, and which layer is the judgment call only your own history can make correctly."
Why this works
This is where a strong answer separates from a blanket rule like "always buy" or "always build."
Stage 4
Give the one decision: the anchor
Say it like this
"Here's the anchor: buy Statuvane for storage, e-signature, version history, and the audit trail, the parts every legal team needs identically. Build DocketFlow as a thin layer on top that does exactly two things no vendor could do for us: route a new matter using our own three years of matter history, and flag clauses against our own negotiated client SLAs."
Why this works
This is the direct answer, stated as an actual architecture you could draw on a whiteboard, not a vague split.
Stage 5
Prove it with the compressed evidence
Say it like this
"We nearly bought an all-in-one vendor's smart-routing add-on for 210 thousand dollars a year. We tested it against 400 of our own historical matters first, after hearing a peer firm's routing model had misfiled a client's M&A matter for four days. It scored 61 percent on our own practice-group boundaries. DocketFlow, built on our own labels, scored 94, for 140 thousand up front and 40 thousand a year after."
Why this works
Compresses the whole case into the one test that actually justified building instead of buying that specific layer.
Stage 6
Name the AI-specific reasoning and the trade-off
Say it like this
"The honest reason this isn't a generic build-vs-buy call is that the vendor's routing model was trained on hundreds of firms' typical categories, and our practice groups split in a genuinely unusual way. A model trained on everyone else's normal can be confidently wrong on your specific normal, and it won't tell you. We accepted the cost of building that judgment layer ourselves, in exchange for correctness on exactly the boundaries a generic model was never trained to see."
Why this works
This is the load-bearing, AI-specific judgment. A normal software feature doesn't silently fail because it learned someone else's categories instead of yours.
Stage 7
Say what you'd keep out, then close
Say it like this
"I wouldn't build our own e-signature or document storage, since Statuvane already does that reliably for a fraction of what building it would cost. For Redwingate, the split held: buy every commodity piece, build only the two decisions that depend on our own history."
Why this works
Closes with real judgment about where the line sits, and restates the direct answer in one breath.
Let's learn
Picture this system before anyone has bought or built a single piece of it.
DocketFlow sits on top of Statuvane, a bought contract-lifecycle platform. Statuvane stores every contract, handles e-signatures, and keeps an audit trail. DocketFlow reads a new matter the moment it's created and routes it to the right practice group with the right risk flags, instead of an admin doing that by hand.
Before any of this, an admin at Redwingate opened each new contract request, read it, guessed which of Redwingate's nine practice groups it belonged to, and tracked the redline back-and-forth over email and a shared spreadsheet, about 25 minutes per matter just to get it to the right desk.
With DocketFlow, a new matter is routed and risk-flagged in under thirty seconds, correctly, on Redwingate's own unusual practice-group boundaries.
Four manual tasks, all riding on one person's memory of which practice group is which.
Here's the turn: the real decision was never "buy or build" as a blanket choice. It was noticing that storage and e-signature are the same problem for every law firm, but knowing which of Redwingate's nine practice groups a matter belongs to is a problem only Redwingate's own history can answer.
Buy whatever every firm needs the same way. Build only the piece that depends on knowing your own history better than any vendor ever could.
Routing accuracy on Redwingate's own 400-matter test
The vendor's model wasn't broken. It was trained on everyone else's practice-group boundaries, which happen not to be Redwingate's.
At its worst, paying for an all-in-one vendor's "smart" routing add-on costs more every year than building it in house would have cost once, while getting it wrong on nearly four out of ten matters.
The five letters, held up as one page. The anchor is the one decision the rest of the answer has to protect.
The choice I would take back
Redwingate's early plan assumed the vendor's "smart routing out of the box" pitch would work for them without testing it first, since it worked, they were told, for other firms. That made sense when nobody had yet noticed Redwingate's practice groups were unusually split. It stopped making sense the moment that split turned out to be exactly what the vendor's model had never seen.
What I would leave alone: I wouldn't build a custom e-signature flow or document storage system, since Statuvane already does both reliably and cheaply, and there's no Redwingate-specific judgment call hiding inside either one.
Naming what stays out is as much a design decision as naming what gets built.
The lesson: a vendor's case studies prove their model works on someone else's normal. They prove nothing about yours until you've actually tested it against your own history.
Now here is the same thing as a story
The short version above is what you'd say in a design review. Read this one for what it felt like the week a peer firm's four-day mistake changed what Teodora tested before signing anything.
Teodora Ionescu could read a new matter's cover email and guess the right practice group faster than the routing spreadsheet ever could.
When the all-in-one vendor's live demo first ran, it looked like a clean win: matters seemed to sort themselves in seconds, and the e-signature and storage worked exactly as advertised. For the first two weeks of the pilot, Teodora assumed the smart-routing feature would just need minor tuning after go-live.
The actual design decision, close enough to argue with: everything on the left stays bought, everything on the right gets built.
By week four, the doubt had grown. The demo data the vendor used never included anything like Redwingate's unusual "construction contracts" category, split off from commercial real estate in a way most firms don't bother with. Teodora stopped assuming it would sort itself out and started pulling real numbers.
Knowledge spark: why would a "smart" vendor feature fail quietly on one firm and not others?
A vendor's routing model is trained on labeled examples from many client firms. If most firms split their practice groups one way and yours splits them differently, the model was never shown your version of "normal." It doesn't error out. It just answers confidently, and wrong.
A peer ops lead at another firm, using the same vendor, mentioned on an industry call that a client's M&A matter had sat unrouted for four days, filed under the wrong practice group entirely, with nobody catching it in time.
We weren't paying for wrong labels on 39 percent of matters. We were paying to have Redwingate's own unusual practice overridden by a vendor's idea of normal.
Teodora pulled 400 of Redwingate's own historical matters and ran them through the vendor's routing model before signing anything. 61 percent correct. Nowhere close to safe for a firm whose practice-group lines don't match most others'.
The real question was never whether the platform overall was good. It was whether the one piece, matter routing, depended on knowledge only Redwingate had, or knowledge any vendor already had. Everything else, storage, e-signature, audit trail, was the same for every firm. That one piece wasn't.
The anchor's real test isn't whether it's ever wrong. It's how fast being wrong gets fixed.
When the original vendor plan was first pitched, nobody suggested testing the routing feature against Redwingate's own matters first. "Their case studies look solid," someone said in that meeting, and it sounded reasonable, since the case studies were real, just from firms with ordinary practice-group boundaries.
Three-year cumulative cost: vendor add-on vs buy-plus-build
Buying the plumbing and building only the judgment layer costs less every year, and gets the judgment call right three times as often.
One version pays more every year for a generic routing model that gets Redwingate's own practice wrong four times in ten. The other pays once for a model trained on exactly the boundaries that make Redwingate different, and keeps paying only for the plumbing everyone needs the same way.
What I'd tell myself, hearing about that four-day-late M&A matter at another firm: a vendor's case studies prove their model works on someone else's normal. They prove nothing about yours until you've actually tested it.
SPARK, mapped onto one buy-and-build decisionNot a script for always building the judgment layer. SPARK is what makes sure buy stays the default everywhere it should.
S
Situation. How does the work get done today, without you?
An admin manually reads each new matter and guesses its practice group by hand, tracking redlines over email and a spreadsheet, about 25 minutes a matter.
Grounding in one real task keeps the anchor from becoming an abstract architecture diagram.
P
Payoff. What habit do you want this to build?
Trust an automatic route and risk flag enough to act on it in under a minute, without re-deriving it by hand or waiting on a senior lawyer first.
The habit, not the thirty seconds saved, is the actual thing worth designing for.
A
Anchor. The one design decision everything hangs on.
Buy Statuvane for storage, e-signature, version history, and audit trail. Build DocketFlow for exactly two decisions no vendor's model was trained to make correctly: routing by Redwingate's own history, and flagging clauses against Redwingate's own client SLAs.
This is the hardest step, and the answer to the question, stated as a concrete split, not a philosophy.
R
Risk. What breaks the first time you're wrong?
If DocketFlow mis-routes or misses an SLA flag, a visible why-trail shows which historical matter or clause drove the call, and a one-click reroute turns a wrong call into a minute, not four days.
The anchor has to visibly survive its own risk, or it's just two unrelated halves of a decision.
K
Keep out. What you deliberately won't build yet.
No custom e-signature or document storage, Statuvane already handles both reliably. No fully autonomous redline generation, since that's a bigger trust step than routing and flagging.
Naming what stays out shows judgment instead of a wish list nobody asked for.
The recap, one line per letter: situation is the manual 25-minute-a-matter routing task, payoff is trusting an automatic route enough to act on it in under a minute, anchor is buying the plumbing and building only the two firm-specific judgment calls, risk is the why-trail and one-click reroute that keep a wrong call cheap, and keep out is the custom e-signature and autonomous redlining Redwingate deliberately isn't building yet.
And if you want to be sure it really works, try it somewhere elseSame five letters, a pharmacy chain instead of a law firm. The plumbing changes, but the seam sits in exactly the same place.
Beatrix Cardoso runs pharmacy operations at Larkbrace Pharmacy Group, deciding how to design a refill-review system across its stores. Mapped onto SPARK: situation is a pharmacist manually checking every refill request against the formulary and state-specific rules, about three minutes each. Payoff is trusting an automatic flag on genuinely risky refills enough to act immediately, and skip manual checks on the routine 80 percent. Anchor: buy a pharmacy-management platform's core system, inventory, insurance-claims processing, refill scheduling, the same for every pharmacy chain, and build a thin flag layer using Larkbrace's own multi-state refill-rule table, something no generic vendor tracks at Larkbrace's specific granularity across the states it operates in. Risk: a missed flag on a genuinely risky refill is dangerous, so the anchor needs an always-show-your-reasoning trail plus a conservative default, uncertain cases still flag for review rather than passing silently. Keep out: no custom inventory or insurance-claims system, since the bought platform already handles both reliably.
Different industry, same seam: buy what's identical everywhere, build only what depends on your own rules.
Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "buy the plumbing every company needs the same way, build only the judgment call that depends on your own history," and stop.
Cost: no time to test a vendor's smart feature against your own data before a decision is due. Say so honestly, and commit to running that test in the pilot's first two weeks, not skipping it.
The vendor's model got better, for real: if a future version of the vendor's routing model is retrained on firms with atypical categories like yours, that's exactly the kind of update worth re-testing against, not assuming away.
Where people run it wrong.
They buy an all-in-one vendor's "smart" feature without testing it against their own historical data first.
They build everything themselves out of a general instinct to "own the whole stack," including plumbing nobody would ever pay them extra for owning.
They treat "build the workflow layer" as a green light to automate everything, instead of naming exactly which judgment call earns that investment.
How to use it live. The moment an interviewer asks when to buy the platform and build on top, ask yourself: which single decision in this system depends on knowledge only my company has? Name that one thing out loud, and the rest of the split follows on its own.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework fits deciding what to buy versus build on top of it?
Tap to flip
ANSWER
SPARK: situation, payoff, anchor, risk, keep out. It roots the split in one real task instead of a blanket "sometimes buy, sometimes build" rule.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Teodora Ionescu, AI PM at Redwingate Legal, who tested a vendor's "smart routing" claim against the firm's own historical matters before trusting it.
3 · THE HABIT
What habit did Teodora fall into during the pilot's early weeks?
Tap to flip
ANSWER
Assuming the vendor's smart-routing feature would just need minor tuning after go-live, instead of testing it against Redwingate's own historical matters right away.
4 · THE ANCHOR
What's the actual anchor decision in this answer?
Tap to flip
ANSWER
Buy Statuvane for storage, e-signature, and audit trail. Build DocketFlow only for routing and SLA-flagging, the two decisions that depend on Redwingate's own history.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Assuming the vendor's "smart routing out of the box" pitch would work without testing it against Redwingate's own unusual practice-group boundaries first.
6 · THE NUMBER
Fill in the blank: the vendor's routing model scored ___ percent on Redwingate's own test, while DocketFlow scored ___ percent.
Tap to flip
ANSWER
61 percent, 94 percent, on the same 400-matter test.
7 · THE REPLAY
Same 400-matter test, DocketFlow built instead of the vendor add-on bought. What changes?
Tap to flip
ANSWER
Routing accuracy rises from 61 to 94 percent, and three-year cost drops from $630k to $515k, since building the judgment layer once beats renting a worse one every year.
8 · CROSS PRODUCT TRANSFER
Section 4 runs this again for a different product. Which one, and what stays the same?
Tap to flip
ANSWER
Larkbrace Pharmacy Group's refill-review system. The plumbing changes to inventory and claims processing, but the seam sits in the same place: buy what's identical everywhere, build only what depends on your own rules.
Check yourself Score: 0 / 0
Multiple choice
1. Why did the vendor's smart-routing add-on score only 61 percent on Redwingate's own test?
A. The vendor's model was broken and needed a bug fix.
B. It was trained on other firms' typical practice-group categories, and Redwingate's split their groups in an unusual way.
C. Redwingate's own admins entered the test data incorrectly.
D. The vendor deliberately weakened the demo to upsell a bigger contract.
Show hint
Look at the knowledge spark about why a "smart" feature can fail quietly.
Show answer
B. The model wasn't broken, it just never saw Redwingate's specific category boundaries during training, so it answered confidently and wrong.
True or false
2. True or false: this answer recommends building the e-signature and document storage system in house, alongside DocketFlow.
True
False
Show hint
Look at "what we left for later" and the K step.
Show answer
False. Statuvane, the bought platform, already handles e-signature and storage reliably. Building those would spend budget on plumbing with no firm-specific judgment call inside it.
Fill in the blank
3. Fill in the blank: DocketFlow costs ___ thousand dollars to build once, and ___ thousand dollars a year to maintain after that.
Show hint
Look at the cumulative cost line chart.
Show answer
140 thousand once, 40 thousand a year. Together with Statuvane's $85k a year, that's still cheaper over three years than the vendor's $210k-a-year add-on.
Short answer, where it wouldn't matter
4. Name a part of this system where buying, not building, is clearly the right call, and say why.
Show hint
Look at "what I would leave alone."
Show answer
Model answer: E-signature and document storage. Every law firm needs those identically, so there's no Redwingate-specific judgment call hiding inside either one, and Statuvane already does both cheaply.
Short answer, apply it yourself
5. Think of a tool you use at work or school that's a mix of "standard for everyone" and "specific to your situation." Where would you draw the buy-vs-build line?
Show hint
Think about which part of the tool only makes sense because of something specific to you.
Show answer
Model answer: A gradebook app: buy the grading and attendance system every teacher needs, but build a small custom rubric-weighting layer if your school's own grading policy is genuinely unusual.
Short answer, work the number
6. If DocketFlow's build cost had been $300k instead of $140k, would buy-plus-build still beat the vendor's add-on over three years?
Show hint
Add the new build cost to three years of Statuvane and upkeep, then compare to $630k.
Show answer
Model answer: Yes, barely. $300k plus three years of $85k Statuvane and $40k upkeep is about $675k, which would actually edge past the vendor's $630k, showing the build cost genuinely matters to the call, not just the accuracy gain.
Before you close the answer
Why this works
Tests whether you can locate the exact seam between commodity plumbing and firm-specific judgment, instead of treating build-vs-buy as one blanket decision for the whole system.
Follow-up traps
"Couldn't the vendor just retrain their model on your data too?" Response: some vendors offer that, but it usually comes at a premium and locks the proprietary training data inside their platform, so building it in house keeps both the cost and the data under Redwingate's own control.
"Isn't building always riskier than buying?" Response: not when the built piece is thin and has a visible why-trail with a fast override. The real risk isn't building, it's building or buying without a way to catch and fix a wrong call quickly.
If pressed
DocketFlow's routing model is retrained quarterly on newly closed matters, so its own accuracy keeps climbing on Redwingate's categories specifically, the opposite trajectory of a generic vendor model that stays fixed until the next contract renewal.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
