Job five kicks off. Your first four had similar capacities, similar customers, and worked (after a few delays and cost overruns). Engineering copies job four's folder structure into a new project directory and gets to work on a new design. 18 weeks of engineering later, and the design is unique.

The plot plan was redrawn, the piping reworked, different equipment models were chosen, and all the downstream calculations are slightly different. All downstream work gets redone, and new issues are found in the field. You (effectively) started from scratch.

You're not building the same thing five times

Almost nobody is. Companies overwhelmingly build five projects that resemble each other. The problem is that this leads to repeating engineering work without ending on a better design - behind schedule and over budget is the norm, even after your contingency. If you sell something you call a standard product, every site probably still behaves like a project.

'Product' means something specific - a single design (configurations are ok) that every site starts from, and where site-specific variations of that base do not require a fresh start. 'Projects' are one-offs - scoped to one customer, funded by one contract, finished at handover.

The project structure isn't treated as a decision; product is just never considered. Project is how the work arrives: a customer signs, a project code opens, a team gets assigned, and off we go.

Project math and product math

A project you do once justifies the engineering you can bill once. If an additional $50,000 in engineering is expected to save $50,000 on the project, the engineering doesn't happen. But if it saves $50,000 for each of ten sites, then you do the engineering and save $450,000 overall.

This is how phones and cars are so ridiculously good: high non-recurring costs divided by a very large number. Five is not a very large number. It is also not one.

The ceiling on how good your design ever gets is set at kickoff, by an accounting structure, before the first hours are billed.

The bigger win is iteration

Amortization is important, but it undersells products. The first version of a product is always the worst one. Iteration two accounts for the unreliable vendor or tricky maintenance spot. Site three has that fix already, and also removes the valves that haven't once been used. Sites four and five inherit the fixes, and already had proven procedures and a team that knew what every tag meant. When a transformer fails on site four, you can walk the fix backward into sites one through three.

Five separate projects have too little in common to iterate on. A lesson from job two just doesn't apply if the vendor shipped slightly different equipment. With every job started from the same set of templates, a company with a decade of experience can still overlook the same category of problems. Products improve by iterating on the same thing. Projects do not accrue that learning.

The tooling isn't meant for this

Two shapes of software get sold into this problem, and neither fits well.

• PLM models a product with no project: part numbers, BOMs, CAD, a release that ships the same everywhere it goes. It has no opinion about a FEED study, a submittal cycle, or the fact that no two sites have the same tie-ins.
• Project document control (Aconex, Procore, the SharePoint site someone stood up in a hurry) models a project with no product: a container with a start date, an end date, and no memory. When the job closes the container goes cold, and is only used for sporadic reference and copy-pasting.

Neither models a base design with five variations, and everyone ends up running one-off projects without realizing the alternative. The tooling didn't cause the problem, but it is built for only one paradigm.

A copied folder is not a base

Copying is the instinct, but it doesn't work well.

• No parent. A copy doesn't show changes well, so 'what's different about site five?' is a question you answer by opening too many PDFs and trusting someone's memory.
• No route home. The fix from site three has nowhere to go. It sits in site three's folder while sites one and two keep the old arrangement and site six copies the wrong ancestor.
• No intent. You inherit job four's decisions with no way to tell which were deliberate engineering and which were made in a rush.

Every deployment drifts further from its siblings, and 'our standard design' slowly becomes a phrase that appears in proposals and nowhere else.

What building a product actually asks of you

• Declare a base and give it an owner. Not the most recent job: a set that exists on its own, is revised on purpose, and that new deployments start from.
• Every deployment records what it forked from, with easy comparisons between each project and the base.
• Improvements travel both directions: out to the sites not yet built, back into the ones already running.
• Differences stay legible for the life of the equipment, which is considerably longer than the life of the project team.
• What you sent each customer, at which revision, stays answerable after the job closes.
• Work on the base is funded as an investment rather than hidden in whichever project code has room.

That last one is where most of these efforts quietly die. It requires up-front investment in the promise of future savings across many projects that haven't been sold yet.

Where Kord fits

Kord is the system of record for your documents: the P&IDs, 2D drawings, datasheets, specs, calc sets, and submittal packages that make up a deployment.

• Folder forking - a site branches from the base with the relationship recorded, so you can see what that site changed, pull base improvements into an active fork, and push a site fix back into the base.
• Review sessions - every change to the base or a fork is reviewed against a visual diff of what actually changed, with sign-off pinned to exact revisions.
• AI consistency checks - change a value and Kord reads across the set to find the documents still quoting the old one.
• Bring your own agent - use the latest tools from OpenAI, Anthropic, Microsoft, or Cursor; they integrate natively with Kord through MCP.
• Transmittals - named snapshots of what was approved and sent to each customer, with a trail that outlives the project.

PLM keeps the parts and BOMs. Kord takes the document set, and syncs on top of SharePoint, Google Drive, or Egnyte, so the files stay where they already are.

Each site should be your best yet, with the fewest issues in design and in construction. Everything learned on the first four should already be included, without anyone needing to remember. If each of your projects takes about as long as the first and isn't clearly better, that's the tell: you don't have a product line, you have five projects that rhyme. The fix isn't a better folder. It's deciding that the thing you sell is a product, and the sites are variations of it.