Build vs Buy: What Building Your Own Meeting Memory System Actually Costs
A weekend script to capture meeting notes looks free next to a monthly subscription. It almost never stays free, because the real cost of a homegrown system shows up years later, after the person who built it has moved on. A framework for deciding honestly, borrowed from a much older argument about core versus commodity code.
The one-evening project that never quite finishes
The pitch for building your own meeting notes system is always the same: it looks small. A script that pulls a transcript, a bot that joins the call, a spreadsheet or a Notion database to hold the output. Someone on the team can have a first version working before the end of the week, and it is tempting to read that speed as the real cost of the project.
incident.io's own engineering blog tells a version of this story that is worth reading in full rather than summarized from a search result: a founder and a friend built an internal expenses system instead of buying one, and what started as receipt submission and categorization grew, request by request, into email forwarding, reporting, manager approvals, and organizational hierarchy tracking. The team's own conclusion, stated plainly in the post: building an internal system is very rarely going to be anywhere near as valuable as delivering the product the company is actually selling.
Meeting notes tools follow the same shape almost every time. The first version handles the happy path: one platform, one transcript format, one export destination. Then someone asks for search. Then someone asks for a Slack digest. Then someone asks why last quarter's notes are not in the same place as this quarter's. None of those requests are unreasonable, and none of them were priced into the original one-evening estimate.
Ask what the company actually sells before asking what it costs
Joel Spolsky's 2001 essay on Not Invented Here syndrome gives a sharper test than a cost estimate, and it has aged well precisely because it does not depend on any particular technology: "If it's a core business function, do it yourself, no matter what." A software company should write its own code because code is the product. It can safely buy accounting software, because accounting is not what it sells. A pharmaceutical company should build its own drug research tools and buy its accounting package for the same reason, just inverted.
Applied to meeting notes, the test is direct. If the company's product is meeting intelligence software, transcription, or workplace search, then building that capability in house is not overhead, it is the job. For almost every other company, a searchable record of meetings is a commodity function in Spolsky's sense: necessary, but not the reason customers pay. An operations team, a sales org, a founder's own calendar, none of them are in the business of building transcription pipelines, even though all of them need one.
This is the question worth asking before any cost comparison, because it changes what a fair comparison even looks like. A team whose product is meeting software should expect to spend real, ongoing engineering time on capture and retrieval, because that investment compounds into the product itself. A team whose product is something else is spending that same engineering time on a side project that compounds into nothing but maintenance.
The build looks cheap because the estimate only covers the first month
A build estimate almost always prices the version that ships, not the version that survives. The incident.io account is specific about where the real cost showed up: not in the first working prototype, but in the years after, when the original builder had moved to a different team or a different company, and the system's own complexity and undocumented design turned an easy question, why did this note disappear, into an expensive one for whoever was left holding it.
That pattern has three parts that a first estimate rarely accounts for. The first is scope creep that never resets the estimate: each new integration, each new meeting platform, each new export format is scoped and built individually, and none of them trigger a return trip to the original build-or-buy decision. The second is bus factor: a tool built by one engineer in a few evenings is usually documented by nobody, and the person who understands why a given decision was made is the same person who eventually leaves. The third is opportunity cost, which does not show up on an invoice at all: every sprint spent extending an internal meeting-notes tool is a sprint not spent on whatever the company actually charges customers for.
None of this means an internal build is always wrong. It means the honest comparison is not this month's engineering time against a subscription price. It is three years of accumulating feature requests, plus the eventual cost of someone unfamiliar with the codebase inheriting it, against three years of a vendor relationship that someone else is paid to maintain.
Buying is not a zero-effort decision either
The honest version of this argument has to include the cost on the other side, because buying is not free of ongoing work. A team still has to evaluate candidates against real meetings rather than a vendor demo, still has to decide what happens to the record if the vendor relationship ends, and still has to get a team to actually adopt the tool once it is purchased, none of which disappears just because the software is not homegrown.
Data portability deserves its own line in that evaluation, separate from price or feature checklists. A meeting record that only exists inside one vendor's interface, with no export path to a format the company actually controls, recreates the same lock-in risk that a poorly documented internal tool creates, just with a different party holding the keys. The question to ask a vendor is not only what the tool does, but what happens to three years of notes on the day the company decides to leave.
The fair framing is not build versus buy as a one-time fork in the road. It is build versus buy as two different ongoing cost profiles, engineering time and knowledge concentration on one side, subscription cost and vendor dependency on the other, and the right answer depends on which profile the company is actually equipped to carry for the next several years, not which one looks cheaper on day one.
A short test before anyone writes the first line of code
Four questions, asked in order, settle most of these decisions faster than a spreadsheet comparison. First, is meeting capture and retrieval the thing customers pay this company for, or is it something the company merely needs internally. Second, if the original builder left tomorrow, is there a second person who could maintain this system without archaeology. Third, has anyone priced the third year of feature requests against three years of a subscription, rather than pricing the first version alone. Fourth, if the answer is to buy, does the record stay portable enough that the decision is reversible.
A team that answers all four honestly and still lands on building has usually identified a real, differentiating reason to own the code. A team that has not asked the second and third questions yet is the one most likely to end up owning, in Spolsky's words, a core business function it never meant to take on.
The point of the test is not to make buying the default. It is to make sure the build side of the comparison is priced honestly, at the three-year mark rather than the one-evening mark, before the decision gets made.
Where a tool like Driffle fits into the buy side
For teams that land on buy, the case is not that a vendor tool is smarter than a script someone could write, it is that the maintenance, the platform coverage, and the retrieval layer are somebody else's ongoing job rather than an unscoped addition to an engineering roadmap. Driffle transcribes meeting audio directly from the device rather than joining as a visible bot, and turns that transcript into a searchable record of decisions, follow-ups, and screen context without adding a maintenance line item to anyone's sprint.
That searchable layer is the part a first internal build tends to skip, because search and cross-meeting retrieval are harder to scope than transcript capture, and they are exactly the feature a team notices missing eighteen months in, once the archive is large enough that nobody can find last quarter's decision without asking around. Centralized team access and billing come with the tool rather than as a second project someone has to build on top of the first one.
None of that is an argument that every team should buy. It is an argument for pricing the build option honestly against the questions above, and for treating a meeting memory system as what it usually is: infrastructure the company needs, not the product it sells.
Sources
- In Defense of Not-Invented-Here Syndrome - Joel on Software (Joel Spolsky)
- Making the wrong choice on build vs buy - incident.io blog
FAQ
Isn't a simple internal script obviously cheaper than a monthly subscription?
It is cheaper in the first month and often more expensive by the third year, once feature requests, platform changes, and the departure of whoever built it are counted. Price the three-year maintenance cost before comparing it to a subscription, not the cost of the first working version.
What if we build now and want to switch to a vendor tool later?
That switch is easiest when the internal system exports to a format the company controls rather than locking notes into one person's database design. Build with an export path in mind from the start, the same way a vendor relationship should guarantee one.
How do we make this decision quickly without turning it into its own project?
Four questions usually settle it: whether meeting capture is the product the company sells, whether a second person could maintain a build if the original engineer left, whether anyone has priced three years of feature requests rather than one, and whether a bought tool's records stay portable if the company later leaves it.
Does buying a tool mean giving up control over the data?
It should not, and that is worth confirming before signing rather than after. Ask what export path exists for the full record, not only what the tool does day to day, the same question a well-run internal build should be able to answer about itself.