Build it from open source? Count the seams first

Rafael

• 2026-10-18

When we talk to engineering teams at industrial companies, one objection comes up often: "We could build this ourselves." They usually can. A graph database for the relationships, a search engine for text, a vector store for meaning, a connector framework, a document parser, an OCR engine and an agent framework on top. Every one of those has a good open source option, and a capable team can wire them together in a quarter.

The objection deserves an answer, so we wrote one. Our new whitepaper, Build it from open source? Count the seams first, is written for architects and engineering leads making that call. It argues that the cost of such a stack sits between the parts.

The cost is in the glue

Google's paper on hidden technical debt in machine learning systems made this point about ML ten years ago. Generic packages lead to a "glue code system design pattern", and a mature system "might end up being (at most) 5% machine learning code and (at least) 95% glue code." An assembled AI stack has the same shape. Each part keeps its own copy of a record and its own idea of who may see it, and the code that keeps those copies in agreement is yours to write and run.

Dan McKinley's Choose Boring Technology gives the other half: "the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it." Six parts means six upgrade cycles, six backup procedures and six sets of failure modes, plus the glue tested against each.

The paper goes through it part by part. A short version:

Where the seams show

Permissions are the clearest case. In an assembled stack, an access rule has to exist in the search index, the vector store, the graph queries, every AI tool and every export path. Each is a separate piece of code, and when one disagrees with the others a person sees a record they should not.

In Curiosity Studio, a connector writes who may see a record as edges in the same graph as the record, in the same write. A query compiles the user's group memberships into a filter, and the access check runs once while a result set is built, before any count or facet is computed. So the pages, the count and the facets all describe what that user may see. A result count of 412 when the user may see 30 would already tell them that 382 records exist.

Consistency is the second case. Studio keeps the graph, the text index pages and the vectors in one RocksDB store. A record and its change log are committed together, and the indexes are fed from a queue kept in the same store, so after a crash they resume rather than rebuild. Deleting a record fixes every edge that pointed at it and removes it from every index. In an assembled stack, where each index holds its own copy, "the search still shows a deleted ticket" is a common class of bug.

Why this matters more now that apps are generated

The paper's sixth chapter is about generated apps. Describing an app and getting one back, often called vibe coding, is easy to demo. Simon Willison draws the line well in a recent post: for a personal tool it is fine, but "if you're building software for other people, vibe coding is grossly irresponsible because it's other people's information."

The failures on record so far are in that foundation. In February 2026 a security researcher reported an exam and grading app, generated and hosted on a prompt-to-app platform, that exposed 18,697 user records, 4,538 of them student accounts. Its generated access check was inverted: it blocked signed-in users and let anonymous visitors through. The platform said it scans every app before publishing and that acting on the findings is up to the owner. A developer who built a directory app the same way in three days wrote up two compromises in its first days online: a database view ran with its owner's privileges, so row-level security never applied to it. And a scan of 20,052 newly launched apps found database credentials in the browser code of 11% of them. A public key there is fine by design; the report's concern is the server key that bypasses every access rule, which it found in some of those apps.

A generic code generator starts from an empty folder. It has to invent a database, a login, a permission model and somewhere to host the result, and each of those is a security review. Our view is that the generated part should be small, and everything that makes it safe should already exist when the prompt arrives.

That is how it works in Studio. Sudo, the assistant that builds in Studio, reads your schema and writes ordinary C#: an endpoint, an AI tool, or the sources of your own front end. It works in a sandbox, compiles the change against your deployment and stages it as a diff. Nothing runs until a person approves the diff, and making a front end live is a separate step after that. The app reads through the same permission check as search and chat, so it cannot show a user anything the source system would not.

I wrote up one real case earlier this week: in The era of mockups is over, a coding agent built a non-conformance application with access control per program and per division on Curiosity, during one dinner.

When to build it yourself

The paper ends with the trade-offs. Studio has one engine per job and you cannot swap in a different vector index. It has one writer per deployment, with read replicas for scale. Custom code is C#, with Python for connectors. It has a typed graph, not a reasoner for formal ontologies. If your team wants to own every engine, or already runs a search layer it trusts, building is a reasonable choice.

Will Larson's Build versus Buy puts the decision as a question: "The perfected internal tool will always be better than the vendor's current offering, but you're not going to build the perfected internal tool right now, what will you actually build?" The paper asks you to answer it with the seams in the plan, not only the parts.

The whitepaper is 29 pages, with a test you can run on your own data. Read it on its page or download the PDF.

Read the whitepaper (PDF)

Further reading

• Hidden Technical Debt in Machine Learning Systems, Sculley et al., NeurIPS 2015. The origin of the "5% ML code, 95% glue" observation, and a catalogue of how glue code and pipeline jungles accumulate.
• Choose Boring Technology, Dan McKinley. Why every technology you add has an operational cost, and why "best tool for the job" ignores it. (HN discussion)
• Vibe coding and agentic engineering are getting closer than I'd like, Simon Willison. Where generated code is fine, where it is not, and how review habits shift as agents get more reliable. (HN discussion)
• Build versus Buy, Will Larson. A frame of risk, value and cost for the decision, fair to both sides. (HN discussion)