One Repeated Setup Beats Eight Custom Ones

I built eight projects one at a time over about a year. Each one made reasonable choices about what a project needed. The result was not chaos. It was worse: eight versions of reasonable, with no reliable way to check one against another.

TL;DR: A repeated project setup becomes valuable when its standards are enforced by checks that report exactly what they measured, admit what they could not measure, and avoid false alarms.

What Is A Standard Project Setup?

A standard project setup is one agreed shape for building, testing, releasing, and operating software. It gives every project the same basic controls and vocabulary, while still allowing the product itself to be different. For a business owner, it means the team learns to operate one dependable pattern instead of rediscovering eight of them.

Eight Versions Of Reasonable

The differences looked small until I compared the projects as a group. Three returned the same basic status information in three different formats. Only two of the eight included any accessibility testing. One project was live in production with no automated checks at all. Every change to it went live unverified, with no dependable way back if the release failed.

None of those choices had arrived with a big decision to ignore quality. They accumulated because each project answered the same questions independently. One answer was copied from an older project, another solved the immediate need, and another was postponed because the site was small.

That kind of variation creates an operating cost. A familiar alert means something different on another site. A release that is safe in one project is risky in the next. Even a simple review begins with archaeology.

One Written-Down Way To Build

The fix was not a separate rule for every difference I found. I created one standard shape that new projects could start from and existing projects could move toward.

In plain business terms, this is the difference between eight snowflakes and one thing I actually know how to operate. The projects can still serve different customers and use different technology where the work requires it. Their basic expectations for testing, deployment, recovery, and health reporting should not change without a recorded reason.

The same thinking applies to automation. Repetition is not valuable merely because a computer performs it. It becomes valuable when the repeated process produces a known result and makes exceptions visible.

The Standard That Enforced Nothing

Writing the standard down felt like progress. It produced roughly 5,800 lines of carefully worded rules covering how these projects should behave.

Then I inspected the automated gate that was supposed to enforce them. It executed nothing at all. There were two independent reasons, and either one was enough to make the gate useless. The rules could be precise, the report could look official, and a project could still pass without being examined.

That was the turning point: a documented standard is a suggestion; a check that runs is a rule.

Documentation still matters. It explains intent, trade-offs, and exceptions that a program cannot judge. But if a requirement can be measured and nothing measures it, the requirement depends on someone remembering to look every time. Over eight projects and a year of changes, memory is not a control.

What The Checks Found

I turned about twenty-five of the most useful rules into checks that run against every project. I focused on things that were inexpensive to measure, broadly applicable, and tied to problems I had actually seen.

The initial failures fell from 22 to 5 in one session. Every covered project allowed four different ways to accept a change where the standard allowed one. None cleaned up its working branches after a change was accepted. Two allowed changes to bypass the checks entirely. One had no protective rule configured at all.

Those findings were not abstract style preferences. They described how unverified work could reach production and how routine housekeeping could accumulate. This is also why the lessons from a power outage review travel well beyond servers. A system often appears healthy until an event forces its assumptions into the open.

A Check Must Show Its Work

Two design rules turned out to be worth more than any individual check.

First, a checker must print exactly what it measured. Several project copies were sitting on unmerged work, so the same check could produce a different result depending on which version it examined. A count of problems without the measured version beside it is a rumour. A useful report carries enough context for someone else to reproduce and trust it.

Second, if a checker cannot measure something, it must say "not run," never pass. Missing access, absent project inventory, or an unavailable service does not mean the project is clean. It means the result is unknown. Presenting unknown as success is how a check quietly becomes decoration.

The Checker Must Be Right

The first version of one rule flagged three projects that were actually correct. The check had misunderstood a valid setting and turned good work into noise.

I corrected the rule and added examples that proved both the passing and failing behavior. That matters because a checker that raises false alarms stops being read. Once people expect the report to be wrong, a real warning has to compete with all the noise, and the entire control may as well not exist.

For a business with more than one software project, I would ask three questions: Does every project start from the same basic shape? Is the standard enforced by anything that actually runs? When a check passes, does it say how much it looked at? If those answers are unclear, let's talk about making the setup easier to operate.