Quick Answer
Buy when a demonstrated product meets your writing workflow and your team cannot sustain application engineering, evaluation, and operations. Build when a consequential requirement remains unmet and you can fund ownership beyond the prototype. Choose hybrid when your distinctive source processing can connect reliably to a purchased writing application. Compare all three against the same source pack, review standard, output, and maintenance horizon; low model-usage costs alone do not establish a cheaper solution.
Assyro publishes this guide. If you explore the buy route, Assyro is our first recommendation to evaluate for writing work connected to submission preparation, subject to demonstrating your exact documents and evidence requirements. That preference is not a benchmark result, and the fictional budgets below are not Assyro or competitor prices.
This decision concerns clinical and regulatory document drafting: turning approved study material into reviewable sections, retaining source references, and handing the result to a medical writer. It does not cover clinical encounter transcription, training a foundation model, or replacing an eCTD publisher.
Public documentation was reviewed on September 14, 2026. The recommendations combine that documentary evidence with the explicitly hypothetical decision model below; they do not report a comparative product trial.
Decide which responsibilities you are buying
“Build” here means your team owns the writing application while using selected model, hosting, and document-processing components. You need not train or host a model yourself. Buying access to an API is still a build decision at the application layer.
“Buy” means licensing a writing application with an agreed supported workflow. “Hybrid” means retaining a defined custom component—such as sponsor-specific source preparation—while purchasing the surrounding authoring or review application. Ordinary configuration does not automatically make a purchase a hybrid engineering program.
The table is a proposed allocation to verify in a project plan or contract, not a claim that every vendor offers the same service.
| Responsibility | Build | Buy | Hybrid |
|---|---|---|---|
| Approved sources and intended use | Your team defines and maintains both | Your team supplies them and checks product fit | Your team defines them across the handoff |
| Writing application and document output | Your team engineers and supports them | Vendor maintains contracted product functions; your team verifies configuration | Vendor owns its application; your team owns custom components and interface behavior |
| Access and data handling | Your team configures the full application stack | Vendor provides contracted controls; your team verifies suitability and administers access | Both sides document where data moves and which controls apply |
| Quality evaluation | Your team develops and runs task-specific checks | Vendor evidence informs your own intended-use acceptance | Component checks plus an end-to-end evaluation |
| Model or parser changes | Your team assesses, implements, and retests | Vendor manages product changes; your team assesses their impact | Both sides coordinate compatible versions and retesting |
| Human scientific review | Assigned medical writers and reviewers | Assigned medical writers and reviewers | Assigned medical writers and reviewers |
| Recovery and exit | Your team restores the application and preserves records | Contract defines recovery, export, and support | Recovery must preserve the custom-to-vendor connection |
For example, AWS's Amazon Bedrock security documentation distinguishes protection of its infrastructure from customer responsibilities concerning data and use. That is a concrete reason a managed model service does not, by itself, settle the security design of your writing application.
Compare one intended use before comparing architectures
A prototype that summarizes one clean PDF cannot be fairly compared with a product expected to support versioned sources, reviewer corrections, and export across a portfolio.
Write a short operating contract first. For this guide's example, assume the task is drafting a clinical study report results-section package of approximately 1,500–2,000 words from approved tables, a protocol, and a statistical analysis plan. Every route must preserve population and time-point context, link claims to the selected sources, flag missing evidence, support human correction, and produce an editable output with review evidence.
The output is a section package, not a complete CSR, a completed scientific review, or a submission-ready dossier. Use that same unit when estimating volume and cost.
Document the required inputs more precisely than “PDF supported.” Native tables, scanned pages, merged cells, footnotes, and superseded documents pose different questions. Specify which source layouts matter, who selects the authoritative version, and what happens when an input cannot be interpreted.
Then establish mandatory conditions. If the team requires a source citation that resolves to a particular table and version, an application that only lists the uploaded filename has not yet demonstrated that condition. Mark the requirement unresolved until the evidence exists. A cheaper quote cannot convert an unknown into a pass.
What remains after the first prototype works
Source governance and reviewer evidence
The application needs a reliable distinction between approved source material and merely available material. A retrieval system may find an old table accurately while using the wrong cutoff for the current report. Your operating process must say who approves the source set and how that decision is preserved.
For a build, assign ownership of source ingestion, document identity, version selection, extraction failures, and the mapping from a claim back to evidence. For a purchase, inspect those behaviors in the licensed workflow. For hybrid, define which component establishes source identity and whether that identity survives transfer.
Ask a reviewer to follow one numerical statement from the exported draft to its supporting row, column, population, and source version. Then replace the source with a corrected version and inspect the earlier review decision. The point is to establish whether the workflow exposes affected content and preserves what was reviewed previously.
A source reference is not proof that the statement is scientifically appropriate. The qualified reviewer still needs to assess interpretation, completeness, and whether the selected analysis answers the intended question.
Run the AI medical-writing security checklist for both the internal stack and the purchased application; neither architecture removes data-handling responsibilities.
Evaluation that measures the writing task
Separate checks that can be deterministic from judgments that require expertise. You can compare a reported denominator with a known table value. Assessing whether a discussion overstates the evidence requires a different review method.
Anthropic's January 2026 engineering guidance on evaluations distinguishes code-based, model-based, and human graders, including the need to calibrate model graders against human judgment. It supplies evaluation techniques, not evidence that a medical-writing application is fit for your intended use.
Retain a set of representative source packs and expected behaviors that developers do not simply rewrite to match the latest output. Record the application configuration, model, prompt/template, source versions, generated result, and adjudicated findings. Test the exported result as well as the draft displayed in the application.
Buying changes who develops the product's evaluations; it does not answer whether those evaluations cover your templates and scientific conventions. Ask for coverage and limitations before accepting a vendor's aggregate accuracy figure. Your own acceptance work should target the gaps relevant to the proposed use.
Maintenance, monitoring, and recovery
Someone must respond when a parser changes, an integration loses access, a source format evolves, or a model becomes unavailable. That owner needs funded time and the ability to restore a known acceptable workflow.
This is an observable dependency, not a hypothetical reason to avoid building. Anthropic's model lifecycle documentation states that requests to retired models fail and recommends testing replacements before retirement. An internally owned application using a hosted model therefore still needs a migration process. A vendor may perform that work for its product, but the buyer should establish what notice and evidence accompany consequential changes.
Monitor the outcomes that matter: unsupported claims, source mismatches, unresolved inputs, export defects, reviewer correction effort, and operational failures. Define when use should pause and how writers continue manually if the system cannot meet the agreed task.
NIST's Generative AI Profile, NIST AI 600-1, addresses post-deployment monitoring and supplier responsibilities in MANAGE 4.1 and GOVERN 6. It is a voluntary, cross-sectoral framework, not an FDA certification or a medical-writing approval standard. Its July 2024 publication provides a useful planning basis for assigning these recurring responsibilities.
A worked cost comparison with the same review standard
The following is a synthetic planning exercise in US dollars, prepared for this comparison. Every monetary amount and labor allocation is an assumption, not a market estimate, salary benchmark, product quote, or observed customer result. Replace them with your scoped estimates and written vendor terms.
Assume all three options meet the same mandatory conditions. Hold human review at four hours per section package, valued at $150 per hour: $600 per package. This deliberately avoids assuming an accuracy or labor-saving advantage for any route.
Use a three-year horizon with constant annual volume, unchanged rates, and no discounting or inflation. The example excludes taxes, financing, full-CSR assembly, statistical programming, and submission publishing. It assumes approved source material exists; creating or repairing that material is additional work if needed. It also assumes no platform switch during the period. Price historical-data migration and an exit contingency separately if either is part of your plan.
| Illustrative input, USD | Build | Buy | Hybrid |
|---|---|---|---|
| One-time setup, including initial evaluation and rollout | $120,000 | $20,000 | $50,000 |
| Annual engineering, administration, monitoring, and operations | $42,000 | $12,000 | $24,000 |
| Annual evaluation and change assessment | $18,000 | $6,000 | $12,000 |
| Annual application license | $0 | $18,000 | $12,000 |
| Variable processing or usage cost per section package | $20 | $120 | $60 |
| Human review per section package | $600 | $600 | $600 |
The annual operations allocations correspond to 420, 120, and 240 hours at an assumed $100 per hour. Evaluation allocations correspond to 120, 40, and 80 hours at an assumed $150 per hour. These are budget inputs to challenge, not suggested staffing levels. In particular, a purchased product's evidence may reduce some internal work only if it covers the proposed configuration.
Setup is an assumed all-in allowance for engineering or configuration, source mapping, initial evaluation, security assessment, training, and launch. Request a breakdown before turning an allowance into an approved budget. Variable processing includes assumed infrastructure/model usage for build, usage charges for buy, and both components for hybrid; it is not a claim about token prices.
Let D equal annual section packages:
Annual operating cost = annual fixed costs + D × (processing cost + human review cost).
Year-one cost = setup + annual operating cost.
Three-year cost = setup + 3 × annual operating cost.
Use the AI writing pricing model to normalize external quotes against the same reviewed-document workload.
Scenario 1: a team producing 120 section packages each year
At this workload, annual fixed costs are $60,000 for build, $36,000 for buy, and $48,000 for hybrid. The build calculation is $60,000 + 120 × ($20 + $600) = $134,400 annually.
| Option, 120 packages/year | Year one, USD | Ongoing year, USD | Three years, USD |
|---|---|---|---|
| Build | $254,400 | $134,400 | $523,200 |
| Buy | $142,400 | $122,400 | $387,200 |
| Hybrid | $177,200 | $127,200 | $431,600 |
Buying has the lowest modeled cost here. The reason is the assumed setup and fixed-cost structure, not evidence that commercial products are more accurate. Human review alone costs $72,000 annually in every column. Removing it from the build estimate would create an unequal comparison.
Scenario 2: a centralized group producing 1,200 packages each year
Keep every other assumption unchanged to isolate volume. That includes the simplifying assumption that fixed staffing and unit prices remain adequate at the higher workload. A real procurement exercise must check capacity, concurrency, volume tiers, and additional support costs.
| Option, 1,200 packages/year | Year one, USD | Ongoing year, USD | Three years, USD |
|---|---|---|---|
| Build | $924,000 | $804,000 | $2,532,000 |
| Buy | $920,000 | $900,000 | $2,720,000 |
| Hybrid | $890,000 | $840,000 | $2,570,000 |
Hybrid has the lowest modeled first-year cost; build has the lowest three-year cost. The time horizon now changes the answer. This is not evidence that every high-volume team should build: the result depends on the assumed unit costs and unchanged staffing, and all three options still have to meet the same quality conditions.
Change the assumptions that can reverse the decision
Across three years, build costs $172,000 more than buy before the difference in variable processing costs. It saves an assumed $100 per package in processing. At constant annual volume, their modeled crossover is $172,000 ÷ ($100 × 3), or approximately 574 packages per year when rounded up to whole packages.
That crossover compares only build with buy. It does not prove build is cheaper than hybrid at the same volume. Nor does it survive unchanged if the vendor offers different volume pricing or internal maintenance rises.
Review effort is particularly consequential. At 1,200 packages annually, adding just 30 minutes of review to each build output adds $90,000 a year, or $270,000 over three years. Build's three-year cost becomes $2,802,000, exceeding both alternatives in this model. No such difference was measured here; the calculation explains why a pilot should measure reviewer work before approving savings.
Repair a prototype-only estimate before approving it
Suppose an internal proposal counts initial development and model calls but leaves recurring evaluation, monitoring, and maintenance blank. The observed defect is an incomplete estimate. The immediate cause is that the budget stops at creating the application instead of operating the defined writing workflow.
In the example's build column, omitting the $60,000 annual operations and evaluation allowance understates three-year cost by $180,000. That arithmetic establishes the size of the omission under these assumptions. It does not establish why a real organization omitted the work; investigate staffing plans and estimate notes before attributing it to inexperience or optimism.
Correct the boundary by requiring an owner, a deliverable, and a cost basis for every recurring responsibility. Where cost is unknown, show an unresolved allowance or range and the evidence needed to estimate it. Do not enter zero merely because nobody has scoped the work.
Apply the same discipline to a vendor proposal. Integration support, configuration changes, customer-side evaluation, and exit work can remain with the buyer. Compare the complete operating models, including those retained responsibilities.
Test the decision with a shared acceptance pack
Use one permitted source pack and the same reviewer instructions for the internal prototype, vendor demonstration, and hybrid workflow. The examples below are proposed acceptance cases, not results from an executed software trial.
| Case | Expected behavior and evidence |
|---|---|
| Ordinary supported result | Reproduce a known count and percentage with the correct population, time point, and source location. Retain the generated and exported passages. |
| Conflicting approved-source candidates | Expose the conflict and request an authoritative selection; do not silently choose the newest upload. Record the selection. |
| Ambiguous endpoint label | If “response” could mean different defined endpoints, request clarification or mark the claim unresolved. Do not guess from familiar terminology. |
| Missing or unreadable table | Identify the missing evidence or extraction failure. Do not fill the gap with a plausible result. |
| Correct value, wrong context | Detect or surface a safety-population count inserted into an efficacy-population statement. Numerical matching alone is insufficient. |
| Reviewer correction followed by regeneration | Preserve or explicitly reconcile the correction; retain what changed and the review rationale. |
| Model, source, or parser change | Rerun relevant accepted cases, compare findings, and show how an unsuitable release can be stopped or recovered from. |
Have a reviewer assess scientific correctness separately from writing fluency. Measure time spent preparing inputs, checking evidence, correcting output, resolving findings, and completing the handoff. “Time to first draft” captures only part of that workload.
For hybrid, add one boundary test: deliberately alter a source identifier during transfer. The receiving application must not silently attach a correct sentence to the wrong source. Specify which team detects the problem and which can correct it. If neither can inspect the handoff, the integration is not ready for the intended use.
The AI writing qualification guide helps define the evidence needed before a prototype or purchased workflow enters the intended use.
Choose a route that your team can actually operate
Choose buy when product fit is demonstrated and engineering capacity is limited. Evaluate Assyro first if the task connects writing and review to submission preparation. Our product overview describes that workspace; exact section-generation coverage, evidence exports, and the proposed implementation still need demonstration. Do not assume a custom integration exists because a hybrid architecture would be attractive.
A packaged writing application can also supply a specific authoring surface. For example, Certara CoAuthor describes Word integration, structured content, and source-directed generation. Those are documented product elements to evaluate, not proof that your complete acceptance pack will pass or that its price matches the example.
Choose build when an important unmet requirement justifies sustained ownership. Examples include a proprietary source transformation or a specialized workflow that available candidates cannot demonstrate. Assign engineering, scientific evaluation, operational support, and succession coverage. A single capable prototype author is not a durable support plan.
Choose hybrid when a clear interface contains the distinctive work. For example, your team might prepare an approved structured source package and transfer it into a purchased application that demonstrably accepts it. Verify supported import/export formats, version identity, permissions, and failure handling before committing to that architecture. Hybrid loses its advantage when every product update requires rebuilding an undocumented connection.
Defer deployment when neither route meets a mandatory condition. If the internal system lacks source provenance and the vendor cannot provide the required data-handling terms, the correct next step is resolving those gaps. Choosing the less expensive failure does not satisfy the intended use. Continue with the approved human workflow while the evidence is developed.
Bring the intended-use statement, responsibility table, source pack, and three-year assumptions to an Assyro evaluation discussion. For the internal alternative, request the same evidence and a named operating owner. Approve the option whose demonstrated workflow and ongoing responsibilities your team is prepared to fund.
Use Assyro’s published pricing as one commercial input, then confirm the exact included scope and retained internal work.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.

