For most of my career, the problem was not a lack of smart people.

It was the number of times good teams had to retype, restate, chase, rebuild, and defend the same facts across e-mail, spreadsheets, PDFs, folders, and meeting notes. The people were capable. The work was real. The friction was structural.

That pattern stayed with me across roles.

The pattern I kept seeing

On live jobs, contract risk rarely arrives as a neat legal question.

It shows up as scattered evidence, unclear obligations, late notices, disconnected change tracking, and too much time spent reconstructing what should already be visible. By the time a team realizes a commercial issue is serious, the clean operating window is already smaller than it should be.

I kept seeing the same underlying problems:

  • the same information entered more than once
  • critical documents trapped in the wrong place
  • commercial decisions made without a clean evidence trail
  • teams relying on heroic memory instead of repeatable systems

That is not just inefficient. It weakens judgment.

Why I did not want another dashboard

I am not interested in building software that just repackages confusion.

The goal is not another front end that looks organized while the underlying work still depends on manual re-keying and document scavenger hunts. The goal is a system that reduces friction at the source:

  • capture once
  • preserve provenance
  • keep facts tied to evidence
  • make obligations and changes easier to track while work is still steerable

That thinking came directly from project experience, not from a generic software idea.

Why I started building Pylonary

I started building Pylonary after leaving my last employer because I wanted to turn a repeated industry problem into a practical system.

The core idea is simple: construction teams lose too much time and quality to fragmented document handling and commercial administration. If those flows become cleaner, faster, and more traceable, decision quality improves. That matters long before anything becomes a formal claim.

Pylonary is my attempt to build around that reality.

Why this matters to me

I have spent years working where contract language meets field reality: scope, schedule, cost, documentation, and closeout pressure. That work changes how you think about software.

You stop caring about novelty for its own sake.

You care about whether a system helps a team:

  • see obligations earlier
  • keep change control clean
  • reduce avoidable manual work
  • preserve evidence before it becomes urgent

That is the standard I want Pylonary to meet.

Why I am writing about it here

This site is still about me, my work, and the way I think about commercial clarity.

But Pylonary is part of that story because it comes from the same source: years of watching how projects become harder than they need to be when the systems behind the work are too fragile, too manual, or too disconnected.

That is why I made Pylonary.