I’ve been building this site on the fly for months. Learning HTML, CSS, Tailwind, JavaScript, WordPress, git — all at the same time, all by doing. No bootcamp, no curriculum, just me and a series of AI conversations, building things, breaking things, starting again.
It works. I learn fast this way. But it leaves a mess behind.
Today I stopped building and started looking.
The state of things
My GitHub repo had two branches that had diverged months ago. I couldn’t remember what was on each one or why they’d split. There were files nested inside folders inside folders — `archive/project-assets/archive/v2 Tailwind/v3/` — that kind of thing. Blog drafts from last year scattered across two different directory structures. Design iterations buried where nobody would find them. A Plan.md that was half-obsolete.
Meanwhile, the live site had evolved into WordPress, but none of that was reflected in the repo. No database backup. No theme export. No record of what was actually live on the domain.
I also had a dev subdomain I’d forgotten about, a separate repo for personal content that was now redundant, and a hosting contract with a large price increase looming in a couple of months.
I’d overwhelmed myself again.
What I actually did
I sat down with Claude Code and talked it through. Not “tell me the answer” — more like “help me see what I’ve got.” That distinction matters.
The first thing we did was audit the repo for secrets. I’d suddenly realised it was public and felt a knot in my stomach. Turns out it was clean — no API keys, no passwords, nothing leaked. But the exercise surfaced an important question: should it be public at all? I was planning to store WordPress database exports containing hashed passwords. I also had personal content on the domain that I didn’t want exposed. The answer was obvious once I’d thought it through. I made it private before we went any further.
That’s the thing about talking things through. People who watch me work sometimes think I’m procrastinating or overcomplicating things. But catching a security decision before it becomes a security incident isn’t procrastination. It’s due diligence.
From there, the work was methodical:
Merged two branches into one
Resolved the conflicts, verified nothing was lost, deleted the old branch. One branch, one source of truth.
Reorganised the directory structure
Flattened the nesting, gave everything a name that says what it is. Blog drafts in one place. Design iterations in another. Image prep. Inspiration. Each folder now makes sense on its own.
Hardened the .gitignore
Two lines became twenty. It now blocks `wp-config.php`, environment files, credentials, and IDE clutter — but deliberately allows SQL exports because the repo is private and I need them for portability.
Exported the WordPress database and uploads from SiteGround
For the first time, the live site is backed up in the repo. Every post, every page, every image, every menu. If my hosting disappeared tomorrow, I could rebuild.
Verified the backup
Checked the SQL export against what’s live on the domain. 14 published posts, 5 pages, navigation, theme settings, contact form, SEO data — all present.
Deleted what was no longer needed
The dev subdomain (replaced by local development). A separate repo whose content was now captured in the WordPress export. Two fewer things to maintain.
Wrote a README
One with a clear record of what happened and a checklist of what’s next.
What I learned
The phrase “infrastructure review” came up during the session. I liked it. It’s what I did — took stock of every moving part, identified what was redundant, consolidated what mattered, and created a foundation for what comes next.
A friend recently told me that his workplace was full of inefficiencies and that he thought I’d be good at coming in to take stock and improve things. I hadn’t thought of myself that way. But looking at what I did today, I can see it. This is the same skill — just applied to my own work instead of someone else’s.
I’ve spent 25 years in enterprise finance systems as a contractor. Believe it or not, in that environment, version control wasn’t formalised, but something I did for my own purposes, with directories and date-stamped files. Operational workflows were whatever I made up. I never had the language to describe what I was doing. I couldn’t sell it outside of my niche, mainly because I couldn’t name it.
I’m starting to find the words now.
What’s next
The repo is clean. The backup is complete. There’s a checklist in the README covering the archive review, a robots.txt update, the hosting migration in May, and eventually a rebrand.
But the real next step is less tangible. I want to get more deliberate. Git commits that tell a story, not just snapshots taken when it feels like a good idea. Branches for actual features, not accidental divergence.
I don’t have a polished workflow yet. But I have a foundation. And I have a better understanding of what I’m actually good at, what comes naturally, and what I might need to pay more attention to.
That’s enough to build on.
Leave a Reply