Custom engineering document management
Appfront builds custom software for managing drawings, diagrams, specifications and calculations for capital-intensive installations and structures. The question is rarely where a document is stored, but which revision is currently valid, who released it, and whether the superseded version has demonstrably been withdrawn from circulation.
Document management for an installation is different from the office
Engineering document management, often called document control or EDMS in tenders, concerns the technical documentation of a physical asset: P&IDs, isometrics, electrical diagrams, structural drawings, strength calculations and supplier documentation. It plays a role in the process industry, energy, infrastructure, shipbuilding and building services.
The difference from office document management lies in the nature of the document. A contract has a version, and that version is the contract. A drawing has a revision, and that revision is a statement about an object that itself changes. If the installation and the drawing drift apart, the archive isn't just inaccurate; it's misleading.
Two adjacent questions belong elsewhere. If it concerns master data that must be consistent across several systems, such as asset and tag numbers, you're looking at master data management software. If it concerns procedures, work instructions, deviations and audits, that belongs in a custom quality management system.
One valid revision
Exactly one revision is the valid one. That status follows from a release with a name and date, not from a file name.
Withdrawal is an action
The system records to whom a revision was issued and sets against it a withdrawal that only closes once confirmed.
Documentation follows reality
A change on site opens an obligation on the related document, with an owner and a status.
Three drawings of the same pipe, and nobody knows which one applies
A laminated drawing hangs in the cabinet by the installation, printed during the last major shutdown. The project manager's mailbox holds revision D. The contractor starting next week is working from the tender set, revision B. All three were valid at one point, and none of them flags that anything newer exists.
As long as it concerns dimensions, this means rework. For an installation where safety depends on using the correct drawing, the nature of the problem changes. An isolation plan drawn up from an outdated P&ID may specify a valve that was moved during the previous modification. The permit to work is then formally in order but materially wrong, and invisible until it matters. That is not an archive problem but a risk in the installation itself.
As-built and as-designed drift apart
Small changes during construction, an emergency repair at the weekend, a pump replaced with a different type, a pipe rerouted to make space. Each intervention is defensible and disappears from view as soon as nobody is required to report it. The pattern is well known: the as-built is promised at the end, by which time the project team has been disbanded, and the last ten per cent never arrives. A system that breaks this pattern ties the reporting obligation to change management, so that an approved change opens an obligation that is taken into account at handover.
Third-party documents should pass through a gate
Contractors and suppliers deliver a considerable share of the documentation: as-builts, inspection reports, material certificates and maintenance manuals, in their own numbering and formats. If these land directly in the archive, you will have, within a year, an archive nobody dares build on. An acceptance process should sit in between: a check for completeness and format, renumbering to your structure, review by the responsible discipline, and only then inclusion. The return route for rejected submissions belongs in the contract.
Revision status is the core, not a field on a form
A document status is only worth something when it follows from an action performed by a named person, and when the system attaches consequences to it. In most installation environments this comes down to four states.
Under preparation by the author. Others may look along but must not use it as a basis for work; anyone who prints it carries that designation with them.
Submitted to the reviewers of the relevant disciplines. Comments attach to the revision, so it remains traceable which remark led to which change.
Released for use, with name, role and date. From that point the revision is immutable: a correction results in a new revision. Distribution starts here.
The successor has been approved. The system generates the withdrawal instruction from the distribution history. The document remains accessible for historical purposes, but is marked as such.
In project environments further states are added: a separate release for construction alongside a release for information, or a hold when a revision has been withdrawn without a successor. Which status model you need is a question to settle before construction begins: changing it afterwards means reinterpreting the history of every existing document.
What such a system must be able to do
How heavily each of these components weighs varies: an asset management organisation with a stable archive has different needs from a project organisation handling hundreds of documents a week.
Numbering scheme that follows the object
A number that encodes installation, system component and document type remains readable years later. As a rule, the numbering scheme is held within the system itself.
Searching on metadata
Discipline, system, tag number, project phase, revision status and supplier as searchable fields, instead of a round of enquiries among colleagues.
Acceptance of submissions
A submission portal with checks for completeness, format and naming, plus a review round per discipline.
Distribution and withdrawal
Record who received which revision, so that withdrawals can be targeted. Print on request with a watermark and print date.
As-built feedback
A change on site creates an obligation on the affected documents, with an owner and a deadline.
Handover file as a requirements list
The contents of the handover file are fixed at the outset per system component, so that what is missing is visible well in advance.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Coding and standards: what exists, and what does it do for you?
International standards exist for structuring and numbering installation documentation, and it pays to align your numbering plan with them. IEC 81346-1:2022 sets out the structuring principles and reference designations you use to identify objects across disciplines. For the document type, IEC 61355-1:2008 was long the framework, with its document kind classification code. Early 2025 that standard was replaced by EN IEC 81355-1:2025, which shifts the focus to information containers and replaces the DCC with an information kind classification code (ICC).
In construction and infrastructure, the NEN-EN-ISO 19650 series is the framework: part 1 covers concepts and principles, part 2 the design and construction phase, part 3 the operational phase. The series is deliberately general, so DigiGO is working on practical guidelines. For drawing work in civil engineering, road and hydraulic engineering, the NLCS sets out the coding system, layer structure and metadata.
In the process industry and the oil and gas sector, CFIHOS is the designated framework for information handover at completion. It is maintained by IOGP as JIP36 and describes which data and documents a contractor delivers, and in what form. That is easier to enforce contractually than an in-house list.
For Brzo establishments, documentation is not an administrative afterthought. The Besluit risico's zware ongevallen 2015 (Major Accident Risks Decree 2015) transposes the Seveso III Directive (2012/18/EU) into Dutch law and requires a safety management system as set out in Annex III of that directive; Article 12 requires upper-tier establishments to keep an up-to-date list of hazardous substances present. In an inspection, the question is rarely whether you have documentation, but whether you can demonstrate that it is current.
When you are better off not building custom software
Mature EDMS and PDM packages exist for exactly this problem, and for a good share of readers here, such a package is the right choice. If you work with a common revision system, your numbering scheme follows a standard and your processes fit within what the package offers, you buy years of development work and a proven approval model. Swapping that for a custom build is rarely wise, and the same goes if your document volume is limited or nobody wants to take on the maintenance.
Custom software is justifiable in a narrower set of situations: when your numbering or approval structure differs substantially from what a package supports, when the system must integrate with environments the vendor does not know, or when a feature you need has sat on a vendor's roadmap for years.
You should know in advance what custom brings with it. Maintenance, user support and further development become your organisation's responsibility. In regulated environments, there is also the obligation to substantiate and document how the system itself works, and to keep that up to date with every change. With a package, you partly rely on the vendor for this; with a custom build, it rests with the client.
Custom development is worth considering when
- your numbering or approval structure does not fit a package
- you must integrate with systems the package vendor does not support
- several sites with their own regimes must share one archive
- external parties deliver under your contractual terms
- you own the code, data and migration path
Related services
Where adjacent problems belong, so you don't end up building one system for three problems.
Master data management
The master data behind your documents: asset and tag numbers, equipment types and suppliers. If those differ slightly everywhere, no document management system will help. See master data management software development.
Quality management
Procedures, work instructions, deviations and audits follow their own rhythm and belong alongside the engineering archive. See custom quality management system development.
Software for the manufacturing industry
If you produce yourselves, with bills of materials and engineering-to-order, that is a different question. See manufacturing industry software development.
Frequently asked questions about engineering document management
The questions clients ask just before making a decision.
A folder structure tells you where a document is, not whether it is the current revision; anyone can copy it or open an old version without it being noticed. In a document management system, status follows from an approval with a name and date, an approved revision is immutable, and superseding triggers a withdrawal instruction for each recipient.
For many organisations, that is the better choice. If you work according to a common revision methodology and your processes fit within the package, you buy years of development work and a proven approval model. Custom software is only justifiable with a deviating approval structure or with integrations the vendor does not support.
Superseding is an action with consequences, not a silent status change. The system records to whom a revision was issued and in what form, and when the successor is approved it generates a withdrawal instruction per recipient that only closes once confirmed. Prints carry a watermark with the revision number and print date.
Through an acceptance process, not via the inbox. External parties deliver into a portal that checks completeness, format and naming, followed by renumbering to your structure and review by the responsible discipline. Record the delivery requirements in the contract, otherwise the portal will be bypassed.
The client owns the source code and the data. We deliver the repository, the build and deployment scripts, the database schema and the technical documentation so that another party can take over. The document formats remain open, so the archive stays readable even without our application.
Then what counts is demonstrability, not merely the presence of documentation. The system records per revision who drafted, reviewed and approved it, to whom it was distributed and when the previous one was withdrawn. That chain can be exported, which matters for Brzo sites with their mandatory safety management system.
By anchoring the numbering plan and metadata to a standard rather than to the application. Designating objects according to IEC 81346 and classifying document types according to the successor to IEC 61355-1 gives you an archive that keeps its meaning outside the system. Store in open, archive-suitable formats.
What is going on in your archive?
Tell us which installation it concerns, how your revisions and approvals currently run, and where the documentation falls out of step. We will also give you an honest view on whether a standard package would serve you better.