I used to think progress on a technical project was easiest to measure by what I added.
Another page. Another feature. Another integration. Another round of polish.
Building Eldritch IT and Field Notes changed that. Once the sites were real, progress stopped being a count of additions and became something harder to fake: did the latest change make the system clearer, more trustworthy, or easier to operate?
Shipping gave the work consequences. That was useful.
A private project can survive vague copy, duplicated ideas, awkward navigation, and assumptions that have never met a production build. A public system has a way of exposing all of them.
The lesson was not that everything should ship early. The lesson was that eventually a project needs contact with reality, because reality produces evidence that another hour of staring at the editor cannot.
Production turned preferences into questions
Before Field Notes was live, I could spend a long time deciding whether something felt finished.
After it was live, I could ask better questions.
Can a new reader tell what this site is for?
Does an article add a distinct idea, or is it a renamed version of something already published?
Can I find related material without turning every article into a wall of links?
Does the production build treat drafts the way I intended?
Does the design still work when the content is much longer than the sample that originally shaped the layout?
Those questions are better because they describe observable outcomes.
That is the same reason I like test matrices in infrastructure work. A feeling is useful as a signal. It is weak as a validation method. I wrote more about that distinction in the test matrix I use before I trust a change.
Shipping exposed the difference between polish and evidence
One of the easiest traps in web work is polishing the wrong thing.
A section can be beautifully styled and still say almost nothing. A landing page can look complete while making claims the underlying business has not earned yet. A technical article can have clean headings and still duplicate three older posts.
I ran into all three versions of that problem.
The first iterations of the sites benefited from templates, generated code, AI-assisted copy, and familiar design patterns. Those tools made it possible to move quickly. They also made it possible to produce something that looked more mature than my understanding of it.
That distinction matters.
A generated section is not automatically bad. A starter component is not automatically disposable. AI-assisted writing is not automatically generic. But none of those things transfer responsibility away from me.
Once the work is mine, I need to be able to explain why it exists.
That led to a cleanup rule I now use across the project:
If I cannot identify the job a section, feature, or article performs, it is a candidate for removal before it is a candidate for improvement.
That rule has saved more time than polishing ever did.
Real content put pressure on the design
A site built around placeholder content can lie to you politely.
Everything fits because the examples were selected to fit. Titles are convenient lengths. Descriptions wrap nicely. There are only a few categories. Navigation has not accumulated history yet.
Then real content arrives.
Field Notes became more useful as the articles became longer, more specific, and more connected. It also became a better test of the site itself. Archive pages had to handle an actual archive. Series navigation had to represent real sequences. Cross-links needed to help readers rather than simply prove that links existed.
That pressure improved the design because the content stopped adapting itself to the template. The template had to serve the content.
The same thing happened between the business site and Field Notes. They initially shared too much conceptual space. Separating their jobs made both easier to edit: the business site could stay concise, while Field Notes could hold the detailed engineering record.
That separation eventually became part of building one technical identity across two sites. The sites can share a voice without pretending they have the same audience or purpose.
A failed build is still progress if it removes an assumption
I do not enjoy breaking a production build.
I do value what a good failure can reveal.
Some of my most useful lessons about Astro came from changes that failed outside the narrow context where I first tested them. Content metadata became more than frontmatter once I saw how many pages depended on it. Layout ownership became clearer when duplicated output showed that two layers both believed they were responsible for the same thing. Draft handling became an architectural concern once unpublished files could affect a production collection.
I covered those lessons directly in what Astro build failures taught me as a beginner. The broader lesson survived the framework-specific problems:
a failed change can still move a project forward when it produces evidence and the evidence changes the next decision.
That is different from random breakage.
If I make five unrelated changes, get a failure, and then thrash until the build turns green, I have not learned much. If I make one bounded change, read the first useful error, correct the assumption, and run the same path again, the failure becomes part of the engineering record.
The goal is not to avoid every mistake. It is to make mistakes cheap enough and visible enough to teach me something.
Iteration needs a stop condition
There is an ugly side to “continuous improvement.”
It can become a respectable name for never being finished.
A project that can always be improved can also consume every available evening. There will always be another component to refactor, another paragraph to tighten, another metric to add, another tool to evaluate, and another design trend to chase.
That is why I now define the boundary of an iteration before I start it.
For a normal Field Notes pass, I want to know:
- What specific weakness am I trying to correct?
- What evidence says it is a weakness?
- What is allowed to change during this pass?
- How will I know the change worked?
- What am I deliberately leaving alone?
That last question matters more than it sounds.
Scope is partly a list of what I will do. It is also a defense against every nearby idea volunteering itself for the same maintenance window.
This is closely related to the difference between maintenance and endless tinkering. A system does not become more trustworthy merely because I touched it recently.
Publishing also forced a better editorial standard
A growing archive creates a problem that a new blog does not have: new ideas must compete with your own old ideas.
Early on, almost any useful observation could become a distinct post. Later, titles that sounded different began collapsing into the same underlying argument.
Troubleshoot methodically. Document what matters. Keep systems recoverable. Understand your tools. Define the job before adding complexity.
Those are good principles, but repeating them under forty titles does not make the archive forty times better.
So publishing changed from “is this draft decent?” to “does this draft earn a place beside what already exists?”
That is a much higher bar.
I wrote about the backlog problem directly in a backlog is not finished until the ideas are distinct. The practical result is that deleting, combining, or abandoning a draft can be progress too.
Not every idea deserves a URL.
Progress can be subtraction
Some of the best improvements to these sites have been removals.
Unsupported claims removed from copy.
Drafts removed after publication.
Sections removed because they repeated the paragraph above them.
Tools removed from a workflow because they no longer answered a unique question.
Ideas removed from the backlog because another article already said them better.
Subtraction feels less productive because there is less visible output afterward. Operationally, it can be the opposite. Every unnecessary thing I remove is one less thing to explain, maintain, verify, secure, or accidentally contradict later.
That fits the larger operating standard behind Eldritch IT: Order from Complexity. Order is not the same as having more structure. Sometimes it means refusing structure that has no job.
My current definition of progress
I still like shipping things.
I like watching an idea turn into something real. I like adding a capability that solves an actual problem. I like the moment a build passes after I finally understand why it did not.
But I no longer count activity as progress automatically.
A change is progress when it leaves me with better evidence, a clearer boundary, a more understandable system, or a more useful result.
Sometimes that means adding something.
Sometimes it means rewriting it.
Sometimes it means deleting it.
And sometimes the correct iteration is deciding the current version already does its job and walking away from the keyboard.
That last one took me the longest to learn.
Security and privacy note
The examples in this article intentionally describe project and operational patterns rather than publishing private infrastructure details. Hostnames, addresses, credentials, account identifiers, internal paths, private endpoints, and environment-specific topology do not improve the lesson and do not belong in the public version of the record.
AI transparency
AI assisted with editorial organization and revision. The projects, production failures, site revisions, and conclusions described here are based on my own work building and maintaining Eldritch IT and Field Notes.