Make each site better than the last

Job #5 kicks off. #1-4 had similar capacities, similar customers, and worked (after a few delays and cost overruns). Don't just copy #4's folder structure into a new project directory and start work on a new design - you'll burn engineering time and create hard-to-predict problems.

Re-drawing the plot plan means reworking the piping, which then requires different pumps, and edits to every downstream calculation. This snowballs, and you (effectively) started from scratch.

The problem with projects

Companies overwhelmingly build five projects that resemble each other. This leads to repeated engineering work and problems on every site. Behind schedule and over budget is the norm, even after contingency. Even for companies that sell 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.

Most teams don't even consider the difference - 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

One-off projects limit up-front engineering. If an additional $50,000 in engineering hours is expected to save $50,000 on the project, the engineering doesn't happen. But saving $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 many copies of the same product. Five is not a very large number. It much better than one.

The maximum quality of a project is set at kickoff, by basic accounting, and before the true work starts.

The bigger win is iteration

Amortization engineering over many copies is only the start. The first copy of a product is always the worst one. Iteration two can account for the unreliable vendor, the tight maintenance spot, and the last-minute requirement. Site three has those fixes already, and also removes a few valves that were never used. Sites four and five benefitted from an experienced team and proven procedures.

Five separate projects have too little in common to iterate on. A lesson from job two just doesn't apply if you bought slightly different equipment from a separate vendor. Products improve by iterating on the same thing. Projects do not accrue that learning.

Your tooling isn't meant for making a small number of the same thing

There is software for projects, and software for products. Nothing in the middle.

• PLM is for products: part numbers, BOMs, CAD, and a lot of overhead per part. It isn't meant for FEED documents, a submittal cycle, or the fact that no two sites have the same tie-ins.
• Project document control (Aconex, Procore, SharePoint) doesn't let you track or compare changes from one site to another. After each one-off job closes, the container goes cold and is used only for sporadic reference and copy-pasting.

Neither works for a base design with five variations.

Copying folders isn't a solution

Copying only works so well.

• No diffs. Copies don't show changes well, so 'what's different about site #5?' requires opening too many PDFs or trusting a coworker's memory.
• No way to apply changes across other sites. A fix from site #3 has nowhere to go. It sits in site #3's folder while sites #4 and 5 keep the old arrangement.
• No intent. You can copy changes from #4, but there's often no way to tell which changes should apply to all future projects and which are for a specific snafu.

Every deployment drifts apart from one another, and 'our standard design' 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 projects and the base.
• Improvements travel both directions: from a specific site to base, and from base to the sites.
• Differences stay legible for the life of the equipment, even as people move on.
• Every customer transmittal 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 die. It requires up-front investment in the promise of future savings, even when those iterations 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.

Kord organizes your 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. Cut down on issues in design and construction with Kord - include lessons from sites #1 to 4, without anyone needing to remember. If each of your projects takes about as long as #1 and aren't clearly better, you have five projects instead of a single product.