Internal AI tool vs vendor: what a 30-person biotech should do
The build or buy software decision used to be settled by whether you had engineers. Now that a capable person can produce a working tool in a weekend, the deciding question has moved, and most comparison articles have not noticed.
At thirty people you probably do have someone who could build it. That is the change. What has not changed is that the person who could build it is the person you least want spending a month on internal tooling, and that a tool nobody owns in year two is a liability rather than an asset.
The five questions that actually decide it
Feature comparisons are the wrong instrument here, because both options can be made to have any feature. These five decide it instead.
| Question | What the answer tells you |
|---|---|
| Does the record have to survive an audit? | If yes, buy. Validation, controlled change history and a defensible trail are the vendor's whole product, and rebuilding them is more work than the tool. |
| Do several people have to work in the same record at once? | If yes, buy. Concurrency, permissions and a shared view are not weekend features. |
| Is the hard part capture, or upkeep? | If capture, either option works. If upkeep, both a bought form and a built form fail the same way, because neither reads your mail. |
| Who owns it in two years? | If the honest answer is nobody, price the build with a shelf life or do not start it. |
| Does a purchase have to clear procurement and a security review? | If yes, the review may cost more than the tool, and that changes which options are even worth evaluating. |
Where the vendor genuinely wins
Regulated records, shared editing, and anything where a third party expects to see a recognizable system. Those cases are not close, and this site says so on the pages where they apply: the electronic lab notebook question resolves to buy on build or buy lab notebook software, and the clinical study record resolves to buy on build or buy clinical trial management software. Vendors also win when the category is genuinely mature and your version of the problem is genuinely ordinary. Not everything deserves a bespoke answer.
Where the internal build genuinely wins
When the shape of the work is actually yours and no category matches it. When the data must not leave your machine. When the thing you need is small, and buying it means adopting a system ten times larger to get the one part you wanted. And when you have a person who will still be there, and still have the hours, in two years.
What decides whether that bet pays is not the effort in the first version. It is who carries the thing once the person who built it goes back to the job they were hired for, which is why the fourth question above is the one worth arguing about before anyone opens an editor. The platform choice underneath it, including what changes when the assistant runs on your own machine, is in Claude Code for biotech versus off-the-shelf AI tools.
There is a question that reframes the whole comparison. Treat the need as settled, and the only live question is whether the thing gets built internally or bought from somebody. On that frame the third option, doing neither, is not neutral. It is a decision to keep paying the cost in dropped threads.
Why this looks different in drug development
In most industries the internal build competes with a mature category tool. In a small biotech it usually competes with a spreadsheet and a person's memory, because the category tools were priced and designed for companies with a hundred times your headcount. So the comparison is not build against buy, it is build against the status quo, and the status quo has a cost nobody has ever measured.
The specific shape of that cost is that your dates depend on other people's organizations. A vendor tells you the report slips. A partner tells you a lot failed release. A site tells you activation moved. Each message rewrites a chain that ends at a filing date or a first dose, and the rewriting is done, if at all, three weeks later in a review. No category tool catches that, and no weekend build catches it either, unless somebody deliberately built the reading half. The worked version is on build or buy biotech project management software.
The third path, and where it stops
Neither buying a form nor building one, but installing a system that reads the mail and meetings you are already in and keeps the records current on its own. Single seat, one person, plain files that person owns, everything outbound drafted and waiting for a yes. The concept behind it is an AI company brain, and the deal-side worked example is build or buy deal tracking software.
The effort question, since that is what the five above keep coming back to: the app installs in about half an hour, yourself or done with you instead, and it is in limited early access, so getting a copy starts with a conversation. That is the honest comparison against a weekend build, which is a weekend followed by whoever owns it for the next two years.
Its boundary is the same everywhere on this site. It is not validated, it holds no regulated records, it does not do discovery or pharmacovigilance, and it is not a shared team system. If the five questions above point you at a vendor, go and buy from them. The full category map is on build vs buy software for a biotech.
The option that is neither build nor purchase
One seat, plain files on a machine you own, and the reading half already written: a vendor saying the report slips gets filed to the program, the chain of dates behind it redrawn, and the reply staged for your yes. The demo covers it before anyone commits a weekend to version one.
See the demo