The Build-In-House Read: Pitch, Reframe, or Skip an Account

This read is for founders, account executives, SDR leads and partnerships teams. Run it on any account that fits your profile, before it goes into a sequence, to judge whether the account is likely to build your capability in-house instead of buying it. You score six public-signal dimensions, add them up, and land one of three verdicts: Pitch, Reframe, or Skip. Each verdict comes with the evidence behind it and the opening angle it calls for. The read also covers the reverse case, where an account is retiring a homegrown system and turns from a "builder" into the best opening in your territory.

Why a fit account can still end in "we'll just build it"

A real share of buyers now skip purchases they would once have made. In McKinsey's State of AI survey, 32 percent of respondents said their organization had decided against buying at least one software product or feature because agentic coding tools let them build it. Fit scoring and intent scoring miss this, because until the late-stage call a builder account looks just like a buyer.

Agentic coding tools are software coding agents that write and change code with limited human direction. They have made it cheaper to build internal tools, integration glue and prototypes. As a result, the "we'll just build it" objection now shows up in categories where it used to be rare.

The surveys measure different things, so keep them apart:

Three readings matter for a seller.

• The risk is concentrated. McKinsey's high performers are respondents who say 5 percent or more of their EBIT, plus "significant value", comes from AI. They skip purchases at about half, against 31 percent for everyone else. But they make up only about 6 percent of respondents, and they are twice as likely as others to report scaling software coding agents. That makes agent adoption the variable to check, not company size.
• Builders hit a cost ceiling. High performers report being constrained by costs in their use of coding agents about three times as often as others do. That is your Reframe lever, covered below.
• The Retool number is a ceiling. Retool surveyed 817 of its own customers and builders. 35 percent had replaced at least one SaaS tool with a custom build, and 78 percent expected to build more of their own tools. These are customers of a build platform, so treat 35 percent as an upper bound, not a population rate.

Buyers also disagree on the default. One build-vs-buy guide tells them to buy first so they can prove the pain is real before committing to a build. Retool frames building as the new default. You won't know which stance your champion holds until you ask, which is why the read gathers evidence first.

The six dimensions and what each proves

The read scores six dimensions. Five measure build pressure, and the sixth runs in reverse: evidence that the account is retiring a homegrown system cancels the build pressure.

1. Category buildability: how easy your product category is to build in-house.
2. Engineering capacity against the problem: whether the account has staff who build this kind of thing.
3. Build history: whether the account has replaced bought software with its own before.
4. Current hiring shape: whether open reqs point at building or at buying.
5. Agentic-coding adoption: whether the account uses coding agents, the variable that separates high-skip organizations from the rest.
6. Homegrown-sunset evidence: whether the account is retiring an in-house system. This is the reverse signal.

1. Category buildability

The category label sets the baseline before you look at the account at all. Workflow automation and internal admin tools carry the highest build risk. Systems of record and back-office commodity software are almost always bought.

No published lookup table covers every industry. The table below is pieced together from three sources, so treat it as a starting point and refine it for your market.

What it proves: how much effort a build would take, for anyone. How it lies: the label describes the category, not your product. If you sell a system of record that ships with integration glue, the account may buy the core and build the glue. Score the part you actually need them to buy.

2. Engineering capacity against the problem

What matters is staff capacity aimed at your problem, not total engineering headcount. Count the platform, internal-tools and developer-experience engineers, and note whether a named leader runs them. Platform engineering means an internal team that provides reusable services, components and tools to other engineers.

Two secondary benchmarks give a sense of scale. One says mature platform teams make up 5 to 10 percent of an engineering organization, roughly one platform engineer per 8 to 12 product engineers. A community rule of thumb says a dedicated platform team is overkill below about five developers and worth serious consideration past roughly 20 to 30. Nobody has published a way to measure the ratio from public profiles, or a threshold that marks a lasting build function. So count, and don't pretend to precision.

Refolk's index shows how scarce leadership is:

The ratios are derived, and the title and employer breakdowns come from a 25-profile sample, so read them as indicative only.

Because leaders are scarce, a named Head of Platform is a stronger signal than one more platform IC. The sampled leaders work at scale-ups such as Justworks, Drata, Sanity, Gamma and Rho, not only at big tech, so don't assume only large companies have this function.

What it proves: the account can staff a build. How it lies: many platform teams only run CI/CD and developer portals, the kind of tooling Spotify's Backstage represents. They never ship a business app. Titles also inflate. Before you score a team as capacity, check what it ships and open a sample of profiles.

Counting is the slow part. In Refolk, you can ask in plain English for the platform engineers and heads of developer experience at one named company. The profiles come back ready to count, and you can check titles on the same screen instead of scrolling a company page.

3. Build history

Build history means dated, public evidence that the account has replaced bought software with its own. Look in engineering blogs, conference talks, public GitHub orgs and executive remarks. It shows willingness to build. Nobody has published how reliably it predicts the next build.

Klarna is the instructive case. Klarna dropped Salesforce, and its CEO clarified: "We did not replace SaaS with an LLM, and storing CRM data in an LLM would have its limitations. But we developed an internal tech stack." It reported about $2M saved, and the CEO said at SXSW London that it had "1,200 small software service things that we had closed down." Later, Klarna told CX Today it is blending alternative third-party and in-house solutions, and it moved HR to Deel, not to a homegrown system. Two lessons:

• The evidence came from earnings calls, conference remarks and the CEO's posts on X, not from engineering blogs or code. Search executive remarks as well as engineering artifacts.
• One account built some things and bought others in the same period. Tag each artifact by category: inside yours, next to it, or outside it.

What it proves: the organization has made the build call before. How it lies: an artifact in a different category says little about yours, and an open-sourced tool with no recent activity may describe a team that no longer exists. Date every artifact.

4. Current hiring shape

Hiring shape means the mix of open reqs that point at building versus buying. Nobody has published a taxonomy that sorts the two, so here is the split I use:

• Build reqs: engineers hired to work on a named in-house system in your category.
• Buy reqs: admin or implementation roles on a vendor platform, or migration roles moving onto one.

Sources disagree on how long a req stays meaningful:

• One provider puts typical posting-to-purchase time at 60 to 120 days.
• Another prefers a 24-hour or 7-day window, warning that 30 days drags in roles that may already be filled.
• A third says a hiring spike decays as a signal within 30 to 45 days.

I score on reqs posted in the last 45 days. I note reqs up to 120 days old as context but don't score them. Pick your own window, write it on the sheet, and stick to it.

What it proves: where budget is going right now. One vendor claims companies post 73 percent of openings within 30 days of a budget approval. How it lies: another vendor says job postings alone correlate with purchase at only +7 percent, with a single signal about 20 percent true-positive, and two signals within 30 days reaching 50 to 60 percent. Both are vendor claims, but they point the same way: never let hiring alone decide a verdict.

5. Agentic-coding adoption

Agentic-coding adoption is the variable that separates high-skip organizations from the rest. Check public statements, and check reqs or engineer profiles that name coding agents such as Claude Code or Cursor. If you find nothing, fall back on the account's industry rate.

McKinsey's sector figures for skipping a purchase to build:

• Technology companies: 41 percent
• Healthcare payers and providers: 39 percent
• Professional services and energy firms: 38 percent

About two in ten organizations are scaling coding agents, and 31 percent of larger enterprises are.

What it proves: the build is cheap enough to attempt. How it lies: one engineer listing a tool on a profile is not adoption by the organization. And adopters run into cost limits, which can make them more open to a buy conversation, not less.

6. Homegrown-sunset evidence

Sunset evidence means a dated executive remark, migration req or vendor admin hire showing the account is retiring an in-house system. It runs in reverse: an account with every builder trait that is also retiring its homegrown tool is the strongest opening you will find.

Sunsets rarely make headlines. Klarna's later reversal on AI customer service, where it began rehiring human agents, got far less press than the original announcement. Coverage follows the launch, not the correction. So you have to dig sunset evidence out of reqs and later interviews. The clearest pattern is a vendor admin or implementation req posted alongside engineers migrating off an in-house system.

Scoring each dimension and reading the total

Score dimensions one to five from 0 to 2, where 2 means more likely to build. Add them up for a total from 0 to 10, then apply sunset evidence as an override. The cutoffs below are my working judgement. Nobody has validated them against outcomes, so log your verdicts and adjust the cutoffs once you have results.

BUILD-IN-HOUSE READ
Account:
Product category label:
Date of read:
Req window used (days):

1. Category buildability (0/1/2): __   Source:
   0 = system of record, back-office commodity, regulated or customer-facing
   1 = CRM, BI, project management, customer support
   2 = workflow automation, internal admin tool, integration glue, internal dashboard

2. Engineering capacity against the problem (0/1/2): __   Evidence:
   0 = no platform, internal-tools or DevEx staff found
   1 = ICs found but no leader, or team output is CI/CD only
   2 = named platform or DevEx leader plus ICs who ship business tools

3. Build history (0/1/2): __   Dated artifacts:
   0 = none found
   1 = in-house builds outside your category
   2 = dated in-house replacement in or next to your category

4. Hiring shape (0/1/2): __   Dated, linked reqs (confirmed open):
   0 = buy reqs dominate (admin, implementation, migration onto a vendor)
   1 = mixed, or no relevant reqs in the window
   2 = build reqs dominate (engineers named on an in-house system)

5. Agentic-coding adoption (0/1/2): __   Evidence:
   0 = no evidence, industry outside the high-rate sectors
   1 = unknown, but in technology, healthcare, professional services or energy
   2 = public statement or reqs naming coding agents

TOTAL (0 to 10): __

6. Homegrown-sunset evidence: confirmed / unconfirmed / none
   Dated quote or req:

VERDICT RULES
0 to 3 = Pitch
4 to 6 = Reframe
7 to 10 = Skip, only if two or more of dimensions 2 to 5 score 2; otherwise Reframe
Confirmed sunset in your category = Pitch, whatever the total

VERDICT: Pitch / Reframe / Skip
Opening angle:
Recheck on:

The two-signal rule on Skip exists because a single signal is weak. Category alone can't justify walking away, since it says nothing about this particular account. A Skip needs at least two account-specific dimensions at full score.

The two heaviest dimensions are category and capacity. Plotting them against each other gives the shape of the decision before you look at the others:

The 30-minute procedure

The procedure takes one account through all six dimensions in about 28 to 30 minutes. Split it by role: the AE or founder labels the category once per product, the SDR counts capacity and pulls reqs, and the AE checks build history.

Step six is where most time gets lost, because the pattern you want is two different reqs at the same company. Refolk takes that pairing as one plain-English request, across LinkedIn, GitHub and the open web:

What each verdict calls for: the opening angle

Each verdict comes with its own first message. Pitch means a standard opening. Reframe means opening on cost and on splitting the work. Skip means parking the account with a dated trigger to look again.

Pitch

Open the way you would with any good-fit account. If a confirmed sunset put the account here, name it: the in-house system, the dated evidence, and the cost of running it that they are trying to get away from. Don't gloat about the failed build. The engineers who built it may be in the buying group.

Reframe

A Reframe account can build it, so don't argue that it can't. Argue about cost and about where the work splits.

• Total cost of ownership. Count maintenance, model and token spend, and the engineers the build ties up. High performers are cost-constrained on coding agents about three times as often as others, so this lands with exactly the accounts most likely to build.
• Success rates, carefully. The Fortune write-up of MIT NANDA's research says purchased AI tools and partnerships succeed about 67 percent of the time, and internal builds about one-third as often. The report blames most failures on a "learning gap": tools that do not adapt to how a company works. Say "about one-third as often" and stop there.
• The split. Buyers already buy the platform and build the glue. Sell the layer they would never want to recreate, and leave the glue to their team.
• Buy first. Some buyers buy first to prove the pain is real before committing to a build. Offer that as the low-regret path.

Subject: Before you build {capability} in-house

Hi {first name},

I saw {the talk / the req / the post, with date} on {in-house system}. Your team clearly can build this, so I won't argue that point.

The question I'd ask is what it costs to keep running: maintenance, model and token spend, and the engineers it keeps busy after launch.

Most teams I talk to buy the {platform layer} and build the glue on top themselves. That way they own the parts that are specific to them and drop the parts that aren't.

If it's useful, I can show where that line would sit at {company}: what my team would take off your plate, and what yours would still own.

{signature}

Skip

Skip isn't a judgement on the account. It means the account isn't worth outreach now. Write down the trigger that would reopen it: a new platform leader, a migration req, a vendor admin hire, or an executive remark about retiring a tool.

How the read goes wrong

Most bad verdicts come from reading a real number as if it meant more than it does. Each failure below has a check you can run in under a minute.

1. Treating platform headcount as build intent. Gartner forecast that 80 percent of large software engineering organizations would set up platform engineering teams, up from 45 percent at its baseline. A secondary source attributing the figure to Gartner adds that fewer than 30 percent would get measurable developer productivity gains from them, and 55.9 percent of surveyed companies already run more than one internal developer platform. Having a platform team is common and says little on its own. Check: does the team ship business apps, or only CI/CD?
2. Reading 32 percent as category abandonment. McKinsey's figure means a third of organizations skipped at least one purchase. It doesn't mean a third have given up buying your category. Check: use the survey for context and score the account on its own evidence.
3. Quoting Retool's 35 percent as a population rate. The respondents are customers of a build platform. Check: call it a ceiling whenever you use it.
4. False sunset signals. A headline saying a company replaced a vendor with in-house AI can hide a switch from one SaaS vendor to another. Klarna's Salesforce story turned out to include alternative third-party apps, and its HR went to Deel. Check: find a follow-up statement from the company before you mark sunset as confirmed.
5. Stale reqs. Windows in the sources run up to 120 days, and a filled role still shows up in some searches. Check: record the posting date and confirm the req is still open on the day you score.
6. Misquoting MIT. Secondary sources turn "about one-third as often" into either 33 percent or about 22 percent. The sample is small, and much of the commentary repeating it comes from vendors who gain from a buy message. Check: quote the comparison, not a number.
7. Platform title inflation. Refolk's sample of US platform ICs included a "President" and a "Teaching Assistant". Check: open the profiles you count. A title match alone isn't enough.

One more limit: nobody has published how well build-history artifacts predict build behaviour, and nobody has validated a scoring model for this job. This read is a disciplined way to collect evidence, not a forecast. If your verdicts keep missing in one direction, change the cutoffs, not the evidence rules.

Keeping the read current

A verdict lasts only as long as its newest dated evidence. Recheck when a trigger fires, not on a fixed calendar, and re-run the base rates whenever a new edition of the source surveys comes out.

• Account triggers. A new Head of Platform or DevEx leader, a migration req, a vendor admin or implementation req, or an executive remark about retiring a tool. Any of these reopens a Skip or changes a Reframe.
• Base-rate refresh. The industry rates and high-performer shares come from annual surveys. When a new McKinsey State of AI edition comes out, update the sector rates in dimension five and the shares in your Reframe talk track.
• Calibration. Log every verdict next to its outcome. After a quarter of deals, see which band produced "we'll just build it" losses and adjust the cutoffs.

Saving the capacity and sunset searches as plain-English requests in Refolk means each recheck is a re-run, not a fresh research session.