Build or Buy an EDMS? Compare Ownership and Control

Buy and configure an EDMS when a supportable commercial product meets your essential document workflows. Consider building when a material requirement remains unmet and you can fund the software's full operating life. Retain the current platform and extend it when the gap is narrow and its underlying controls remain suitable. None of these routes removes the need to establish fitness for the intended use.

The central question is who will own the controlled document service after the project team leaves. A working upload screen is not a complete EDMS. Equally, a signed subscription agreement does not establish that your roles, document states, migration and interfaces work correctly.

This comparison is for life-sciences teams deciding how to provide document management. It includes a make-or-buy worksheet and contrasting examples. Hosting location is a separate decision: purchased software can run in different environments, and a custom application can use managed infrastructure.

Compare three operating models

“Build” includes commissioned software and low-code applications. Using an external development firm does not turn a bespoke application into a generally supported product. “Buy” can include substantial configuration. A heavily customized commercial implementation may carry both supplier dependency and custom maintenance work.

Describe each candidate precisely: product and edition, custom components, hosting operator, identity service, signature service if used, interfaces and support owners. Compare the same document populations and lifecycle. A repository for working drafts is not equivalent to the authoritative system for approved quality procedures.

If the uncertainty is whether the workflow belongs in document management, quality processes or regulatory information management, first resolve the QMS and RIM responsibility boundaries. Otherwise, an EDMS project can quietly acquire the responsibilities of several systems.

Separate a genuine requirement from a familiar habit

Begin with one consequential workflow, such as reviewing a controlled procedure, making the approved revision available and withdrawing the superseded revision from routine use. Identify the people, decisions, records and failure consequences. Then describe the outcome without prescribing your current screen layout.

“Only authorized approvers can approve the identified revision” is a requirement. “The approval button must appear in the fourth column” may be a usability preference. A preference can matter, but it should not trigger a bespoke regulated application without a clear business reason.

For every proposed custom feature, ask what fails if you use the product's supported method instead. If the answer is additional training, compare that effort with maintaining the customization. If the answer is an unacceptable loss of document context or an essential workflow that cannot be controlled, keep the requirement and obtain evidence of the gap.

A commercial demonstration that omits the difficult step does not establish fit. Conversely, an internal prototype that implements that step does not establish overall readiness. Both must address the surrounding lifecycle: permissions, approval state, changes, retrieval and continued operation.

Buying does not remove validation responsibilities

Determine regulatory applicability from the records and their use. Under 21 CFR Part 11, scope is tied to relevant electronic records and signatures. Its closed-system provisions address validation, copies, retention, access and audit trails; signature provisions address matters including manifestation and linkage. These controls do not become irrelevant because the application was bought, nor universally applicable merely because it is called an EDMS. 21 CFR Part 11, particularly sections 11.1, 11.10, 11.50 and 11.70.

Read that regulation alongside FDA's scope-and-application guidance. The guidance describes enforcement discretion for specified provisions while preserving applicable underlying recordkeeping obligations. It is not a blanket exemption from establishing trustworthy records or intended-use suitability. FDA Part 11 scope-and-application guidance.

For computerized systems used in EU GMP activities, Annex 11 addresses both commercial and bespoke systems. Section 3.3 calls for reviewing commercial-product documentation against user requirements; section 4.6 addresses assessment and reporting across the lifecycle of bespoke or customized systems. The January 2011 revision therefore provides no basis for treating a purchase as validation-free. EU GMP Annex 11, revision 1.

In practical procurement terms, ask what evidence is available, what your team must produce and who approves the resulting use. Supplier materials may support that work. Their usefulness depends on coverage, relevance and the proposed configuration. See the broader computerized system validation guide for lifecycle planning; this decision should budget that work under every option.

Compare the controls you will actually operate

The following are evaluation questions to adapt to your intended use, rather than a universal regulatory checklist.

Document lifecycle and permissions. Identify the authoritative revision at each step. Determine who can edit a draft, approve a revision, change metadata, make it effective and supersede it. Include administrators and service accounts. A role diagram is useful only if the implemented behavior matches it, including denied actions.

History and signatures. Specify which events require a preserved history and how reviewers retrieve it. Distinguish a document's version history from an audit record of relevant actions. If electronic signatures are required, define their meaning, identity controls and relationship to the exact record. A typed name or generic activity log should not be accepted as proof that the requirement is satisfied.

Export and retrieval. Define an example record package before procurement: native content or required rendition, necessary versions, metadata, relationships and applicable approval/signature history. Agree which parts must remain searchable and readable after export. A folder of current PDFs may be useful, but it may omit context required for your records.

Recovery and continuity. Name the service that must recover and the evidence you need afterward. Restoring document bytes without their permissions or approval context may not restore usable service. Decide acceptable loss and interruption limits from the process, then obtain evidence for those limits. Do not assume that a backup-job success message proves restoration works.

Security and change. Assign identity administration, vulnerability handling, dependency updates, incident response and change assessment. Commercial software shifts some execution to a supplier; custom development leaves more of the design and coordination with your team. Either arrangement needs a named owner for the work that remains.

Annex 11 sections 7, 10, 16 and 17 address storage/recovery, controlled changes, continuity and archiving within their GMP scope. Use those expectations where applicable, while defining your system-specific acceptance criteria. Annex 11 operational provisions.

Treat maintenance as a funded service

A build proposal should identify more than who writes the first release. Name who understands the data model, reviews changes, responds to incidents, manages dependencies and supports users. Include succession: can another qualified maintainer recover and change the system using the retained code, documentation, credentials and deployment process?

If a contractor delivers the application, specify ownership and access to source code, build instructions, relevant licenses, technical documentation and support obligations. Receiving a source-code archive does not prove your organization can operate it. The proposed support team needs a credible handover and continuity plan.

For purchased software, examine the division of work just as closely. Who assesses a supplier release? Who updates configuration and integration code? What happens when an API or file format changes? A support contract may cover a product defect while excluding the custom connector on which your workflow depends.

NIST's Secure Software Development Framework, SP 800-218 version 1.1, provides recommended practices and a common vocabulary for software producers and purchasers discussing secure development. It is useful for structuring this conversation; it is not an EDMS certification or a substitute for applicable life-sciences controls. NIST SP 800-218, final February 2022.

If no one accepts continuing maintenance responsibility, record the option as unresolved. Do not assign zero maintenance cost because the work has no owner.

Compare lifetime costs without hiding internal work

Use the same planning horizon, currency, user populations, environments and document volumes for each option. State whether the calculation is undiscounted budgeting or a finance-approved discounted analysis. Do not compare a developer's initial estimate with a vendor's multiyear subscription and call the difference a saving.

Create one cost ledger per option. Each line needs a cost owner, basis, timing, source, inclusion status and uncertainty range. Use these categories to check coverage:

An undiscounted comparison can sum all nonoverlapping ledger lines incurred in the chosen horizon. If a package includes an activity, mark that activity as included and reference the covering line; do not charge it twice. Record costs after the horizon separately so a short comparison does not conceal retained-record obligations. Previously incurred sunk costs are not avoidable future savings.

Keep direct cash expenditure and internal labor visible as separate subtotals. Use a consistent finance-approved labor basis, and avoid adding the same staff allocation again as a second “opportunity cost.” Benefits such as faster retrieval need their own stated assumptions and evidence; they are not negative costs inserted to make a favored option win.

For sensitivity, vary the uncertain inputs that could reverse the choice: migration effort, integration maintenance, user growth or a supplier's documented renewal terms. A blank maintenance estimate means the total is incomplete. It should never silently become zero. This guide supplies no vendor prices or default percentage contingency because neither would establish your scope.

Use this make-or-buy decision worksheet

Complete a separate copy for each specific option. Record the scope, version or proposal date, decision owner, assessment date and evidence references. Use Pass, Fail, Unresolved or Not applicable with rationale. “Pass” means the evidence satisfies the stated criterion for this option; it does not mean the whole system is approved for production.

First decide which criteria are mandatory for proceeding to your next stage. A known failure on a mandatory criterion disqualifies the option for that stage unless its scope or design is changed and reassessed. An unresolved mandatory criterion holds the selection pending evidence. Benefits elsewhere cannot compensate for a missing critical control.

At an early discovery stage, a credible plan may be enough to fund further investigation; it is not enough to assert that an unbuilt control works. At production release, apply the actual acceptance evidence required by your procedures. State the stage explicitly so “approved to explore” cannot be read as “approved to operate.”

Among options that meet the mandatory gates, compare your documented preferences: workflow fit, effort, adaptability, support and financial exposure. There is no universal weighted score. Retain the reasons for the choice, its assumptions and the conditions that would reopen it.

Apply the worksheet to opposing buyer scenarios

Scenario A: buy a configured product. A small sponsor needs controlled procedures, established review roles and reliable access to effective revisions. Assume a shortlisted commercial configuration meets its essential workflow and the supplier/customer responsibilities can be evidenced. The sponsor has no funded software-maintenance team.

The commercial route can proceed to detailed evaluation under those assumptions. A custom build remains unresolved at continuing ownership even if its prototype looks good. The decisive reason is not that small companies cannot build; it is that this organization has not provided the operating capability its build would require. If the commercial option later fails an essential control, it also cannot proceed simply because the build is weak.

Scenario B: build a defined application. A research organization has a specialized, changing document assembly workflow. Assume its evaluation finds material requirements that shortlisted products cannot support acceptably. It has an established software service team, funded maintenance, quality involvement and a documented assurance approach.

A build can proceed to a bounded development decision if the evidence supports those assumptions. It still has to close its control and release gates. The reason to build is the demonstrated requirement gap combined with credible lifetime ownership, not a belief that code ownership guarantees lower cost or better compliance. Remove the maintenance commitment and the recommendation returns to unresolved.

Scenario C: retain the EDMS and extend one boundary. A company already controls approved source records satisfactorily, but needs a tailored preparation interface. A narrow extension may let the repository remain authoritative while the new application manages working outputs. Confirm document IDs, exact versions, permissions and return paths; do not create a second editable “approved” record by accident.

This option loses its advantage if the supposed extension actually replaces signature, approval or retention behavior without corresponding evidence. Define the boundary before declaring the project small. These scenarios are illustrative decision exercises, not reported customer outcomes or completed product tests.

Record the decision and the condition that could change it

Finish with a short decision record: chosen scope, options considered, mandatory-gate results, evidence gaps, cost horizon, operating owner and next-stage approval. Include a review trigger, such as a material workflow change, withdrawn support, an unresolved export limitation or loss of maintenance capacity.

For example, this completed record applies Scenario B's assumptions to a fictional research organization:

The open recovery and export rows are not failures observed in a product. They are missing evidence. If feasibility work later demonstrates loss of required approval context on export, that becomes a known failure to resolve before the relevant release decision. This distinction keeps the record useful as evidence develops.

An AI-assisted development tool may accelerate implementation work, but generated code does not answer who approves a lifecycle transition, how a record survives recovery or who maintains the service. Apply the same evidence and ownership questions to it. Likewise, an AI retrieval feature needs an explicit source/version boundary rather than permission to silently change controlled records.

Assyro publishes this guide and offers regulatory document-management capabilities. If your defined scope is regulatory document preparation and review, evaluate Assyro's document-management offering against the same worksheet. Do not infer a full QMS replacement, every required integration or your configured control evidence from that positioning. Bring a representative workflow to an Assyro discussion, with the authoritative system, required output and unresolved decisions identified.