Insights · 13 min read
A practical guide to building a document management system: the core modules, the compliance layer, what drives the cost, and when a custom DMS beats SharePoint or Box.
By GGP Editorial
A shared drive is where documents go to be forgotten. Every company with more than a dozen employees knows the pattern. There is a folder called "Contracts_FINAL_v2". Next to it sits "Contracts_FINAL_v2_REVISED". Nobody is sure which one the client actually signed. Three people have a copy open right now, and one of them will save over the other two before the day ends.
A document management system (DMS) exists to end that. It is not a shared folder. It is a controlled repository where every document has one current version, one owner, a defined retention period, and an audit trail of who touched it and when.
This article is for the operations directors, compliance officers, IT leads, and founders who have decided the shared drive is not working and are weighing an off-the-shelf DMS against building one. It covers what a DMS actually is, the modules that matter, the compliance layer, what AI does and does not do, and what drives the price.
The naming needs a few minutes of attention, because vendors have muddied it. Three different things get called "document management", and they are not the same product.
File storage and sync. Dropbox, Google Drive, OneDrive, Box. These store files and sync them across devices, and they are good at that. They are not a DMS. They do not enforce a single current version, they do not run approval workflows, and their audit trails are shallow.
Intelligent document processing (IDP). This is the AI layer that reads a document and pulls structured data out of it — invoice number, contract value, customer name. IDP turns an unstructured PDF into fields. A DMS stores and manages the document; IDP reads it. They work together, but they are different builds. We wrote a separate article on building an intelligent document processing system if that is the problem you are actually solving.
Enterprise content management (ECM). This is the older, broader term — records management, web content, digital asset management, and document management under one umbrella. OpenText and the legacy ECM platforms live here. When most companies say "DMS" today they mean the document repository and workflow part of ECM, not the whole thing.
A DMS, at its core, answers four questions about every document: what is it, who can see it, what is the current version, and when does it get destroyed. Everything else is support for those four.
A DMS splits into modules. Not every build needs all of them, but the list is consistent across industries.
| Module | What it does | Why it matters |
|---|---|---|
| Capture and ingestion | Scan, upload, email-in, drag-and-drop, OCR | Documents enter once, with metadata attached at the door |
| Metadata and taxonomy | Document type, tags, classification scheme | Search and retention both depend on consistent metadata |
| Version control | One current version, full history, check-in/check-out | Ends the "FINAL_v2" problem |
| Access control | Role-based, folder-based, document-level rights | Who can see and edit what, enforced by the system |
| Workflow and approvals | Routing, review, sign-off, reminders | A document moves through a process instead of sitting in an inbox |
| Full-text search | Search inside PDFs, scans (with OCR), Office files | Finding a clause in 50,000 documents |
| Audit trail | Who opened, edited, downloaded, printed, deleted, when | The compliance and e-discovery backbone |
| Retention and disposition | Retention schedules, legal holds, automated deletion | What you keep and what you delete, defensibly |
| E-signature | Signing inside the system or via DocuSign/Adobe | Closes the loop from draft to executed |
| Integrations | Email, Office/Google, ERP, CRM, accounting | Documents live where the work happens |
A law firm wants version control, audit trail, and retention above all. A manufacturer wants capture and integration with its ERP and quality system. A healthcare provider wants access control and an audit trail built for HIPAA. The module list should follow the operation.
This category has mature vendors, and for a standard operation buying is usually the right call. M-Files and DocuWare are strong mid-market DMS. SharePoint sits inside Microsoft 365 and covers a lot of ground if you already pay for it. OpenText and Laserfiche cover the enterprise and public-sector end. Box and Dropbox have been adding metadata and workflow, though they still lean file storage.
If your needs are standard — store documents, version them, search them, maybe run a simple approval — buy. We tell prospects this directly. It is the short version of our custom software vs SaaS comparison.
Building makes sense in a few specific situations.
Your documents are part of a larger system. If documents have to live inside a custom contract management system, a claims platform, or a client portal, a separate packaged DMS means integration glue and two systems of record. Building the document layer into the product keeps one source of truth.
Your retention and classification rules are not standard. Regulated industries — finance, healthcare, legal, energy — often need retention schedules, legal holds, and audit detail that packaged tools charge extra for or do not expose. If your compliance rules are the product, you end up customizing a packaged DMS anyway.
You are selling the document capability, not just using it. If your product is a portal where customers upload and sign documents, you are building document management whether you call it that or not. A packaged DMS as the backend for your own product is usually a poor fit on both pricing and control.
Per-user pricing at scale. DMS SaaS is typically priced per seat. A company with hundreds or thousands of users, or one serving external users, can reach a point where the subscription costs more per year than a build — and you still do not own the repository.
This is where document software gets serious, and where a build either earns its cost or becomes a liability. The specifics depend on your industry, but the patterns repeat.
Retention and disposition. Most regulations do not tell you exactly how long to keep every document. They set floors and leave the rest to a documented, defensible schedule. GDPR requires that personal data not be kept longer than necessary, and it gives people the right to access and delete their data, which means the system has to be able to find every document about a person and act on it. US rules vary by industry — financial records, healthcare records, and employment records each have their own clocks. The system should encode the schedule and enforce it, because "we delete things manually" does not survive an audit.
Audit trail. HIPAA requires a record of who accessed protected health information and when. ISO 27001 and SOC 2 expect logged, reviewable access. A real DMS logs not just who edited a file but who opened it, downloaded it, and printed it. If your packaged tool does not log at that granularity, the build just became worth it.
Access control. Least privilege sounds obvious and is where most shared-drive setups fail. A DMS should enforce document-level permissions that follow the user's role, not a folder path someone set up in 2019 and forgot.
Legal holds and e-discovery. When litigation starts, you must stop deleting relevant documents. A DMS should support a hold that overrides the retention schedule for a defined set of documents. This is a feature packaged tools sell at the enterprise tier, and it is straightforward to build if you planned for it from the start.
The honest caveat: this article is not legal advice, and retention rules change by jurisdiction. Bring your counsel into the requirements phase. What you are building is the mechanism to enforce the rules they give you — not the rules themselves.
AI is the loudest part of the DMS market right now, and most of it is real but narrower than the marketing suggests.
Classification. AI can read a document and assign a type and metadata tags without a human filing clerk. This matters at scale — a back office receiving thousands of documents a month can stop hand-tagging. It is the same extraction and classification work as the intelligent document processing systems, embedded in the repository.
Search. Semantic search finds documents by meaning, not just exact words. "The agreement about the Singapore office" pulls the lease even if the word "office" is not in the filename. Useful once the repository is large; overkill on day one.
Summarization and Q&A. Pointing a model at a contract to get a summary or an answer is genuinely useful and cheap to add. It goes from demo to production quickly, in the same way we describe in integrating an LLM into existing software.
The caveat is the same as any AI feature: the model is only as good as the documents and permissions underneath it. Summarization over a repository with messy versions and no access control produces confident wrong answers. Get the repository clean first, then layer AI on top.
Document software is not priced per feature. The cost follows the number of document types, the compliance layer, the integrations, and the user base. Planning ranges across development shops look like this:
| Scope | What it includes | Typical range |
|---|---|---|
| MVP | Capture, metadata, version control, search, basic permissions, audit log | $40,000–$90,000 |
| Mid-tier | MVP plus workflows, retention schedules, e-signature, ERP/email/Office integration | $90,000–$200,000 |
| Enterprise | Add legal holds, granular audit, AI classification and search, multi-tenant or multi-entity, migration tooling | $200,000+ |
These are ranges to plan with, not quotes. The spread is wide because the scope is. The main drivers:
For a fuller picture of where the money goes, our custom software development cost article walks through it, and estimating a custom software project explains how to scope it so the number stays honest. If you want to keep the first release lean, the same levers as any MVP build apply.
A sensible sequence is this. Start with the document types and the taxonomy, because search, retention, and permissions all hang off metadata. Decide what "done" means: which modules, which integrations, which compliance rules. Build capture, the repository, version control, and search first — that is the core. Then permissions and the audit trail, then workflows and retention, then integrations and e-signature. AI classification and semantic search come last, once the repository is clean and there is real data to learn from.
Treat the first release as an MVP. A system that stores documents, versions them, enforces permissions, and logs access is useful on day one. A system that tries to model every retention rule and every AI feature on day one ships late and over budget.
How much does a document management system cost to build?
Planning ranges run roughly $40,000–$90,000 for an MVP, $90,000–$200,000 for a mid-tier system with workflows and integrations, and $200,000 and up for an enterprise build with legal holds and AI. The number follows document types, compliance, integrations, and users.
Should I build a DMS or buy one?
Buy if your needs are standard and your user count is modest. Build if documents are part of a larger product you are already building, if your retention and audit requirements exceed what packaged tools expose, or if per-user pricing has compounded.
What is the difference between a DMS and cloud storage like Google Drive or SharePoint?
Cloud storage stores and syncs files. A DMS adds enforced version control, approval workflows, retention rules, and a real audit trail. SharePoint blurs the line if you already pay for Microsoft 365, which is why it is usually the first thing to evaluate before a build.
Do I need AI features in my DMS?
Not on day one. Metadata, versioning, permissions, and audit give most of the value. AI classification and semantic search pay off once the repository is large and clean.
How long does a DMS build take?
A focused MVP usually ships in three to four months. A full system with migrations, several integrations, compliance features, and AI typically runs eight to twelve months.
Does a DMS need to be on-premises or in the cloud?
Most new builds are cloud. Regulated industries sometimes require on-premises or a specific data-residency arrangement. That is a requirements question for your counsel and your infrastructure team, not a default.
A document management system earns its keep on the day of the audit and the day someone needs one contract from three years ago. The shared drive looks fine right up until it does not.
GlobeSoft builds document, contract, and compliance systems as part of our broader work on enterprise software. If you are deciding between buying and building, or you have a document problem that no off-the-shelf tool models cleanly, describe the documents and the systems they need to touch. We will help you scope it and give you a number you can trust.
Tell us what you are building and where you are today. We typically reply within 24 hours.
