The story of The Haus Of Legends, a very optimistic renovation plan, and the discovery that “if it loads” is a surprisingly low engineering standard. “If it an’t broke. Why Fix it?”
About two and a half years ago, I built a website. TheHausOfLegends.com
I was an artist with work to share, things to sell, and a vision for The Haus Of Legends. What I was not was a web developer. Apparently, I decided that was a minor administrative detail that could be put off for another day.
So I learned as I went. WordPress, plugins, settings, layouts, integrations. Solve the problem in front of me, get the next thing working, then move on to whatever new problem the previous solution had introduced.
The site grew. A storefront became an ecommerce operation. Artwork became products. Products needed fulfillment. Customers needed checkout, payment options, shipping calculations, and email. The business expanded into education and publishing, and the website kept acquiring responsibilities.
Somewhere along the way, my handmade creative project became a collection of interconnected systems with actual consequences when something stopped working. That was when “Well, the homepage loads” started sounding less like reassurance and more like something a defendant might say.
Welcome to Project Renaissance.
The handmade era: if it worked, I kept going
There is something wonderful about building your own website before you understand how many things can go wrong. You have an idea. You find a way to make it happen. You celebrate. You do not yet know enough to spend the celebration worrying about background jobs.
I built The Haus Of Legends through determination, experimentation, and a willingness to learn the next unfamiliar thing. It worked well enough to become much more complicated than the site I originally intended to build.
WordPress sat in the middle. Around it gathered WooCommerce, print-on-demand services, payment systems, email platforms, security tools, analytics, caching, SEO, forms, and years of experiments. Some services stayed. Others were replaced. Their leftovers did not always receive the memo.
The site reflected the history of the business: what I had needed, what I had tried, what I had abandoned, and what I had managed to get working at the time. From the outside, visitors saw artwork, products, and blog posts. Underneath, I increasingly suspected there were systems whose continued employment nobody had reviewed. I was proud of what I had built. I also wanted someone to look behind the walls before I added another floor.
Enter the inspector
Bringing ChatGPT 5.6 Sol and Codex into that process changed the conversation.
An AI-assisted audit could help me examine the site more systematically, organize findings, and ask questions I would not necessarily have known to ask myself. WPVibe gave us a way to inspect WordPress directly. Later, Codex and Hostinger tooling opened the hosting layer beneath it.
There is a special kind of discomfort in inviting a very polite system to inspect something you have spent years building. It does not need to insult you. It can simply organize your unresolved questions into a neatly formatted list.
Somehow, that is worse.
The findings and questions were broad enough that another round of isolated fixes would not do. We needed to understand the website as a whole: its catalog, navigation, customer experience, technical foundation, and the connections that kept the business running.
But the deeper investigation also complicated the easy joke that everything was terrible. Plenty of things worked. Some alarming-looking settings were justified. Some old artifacts were useful. Some failures belonged to upstream software rather than anything I had done.
The inspection challenged both my confidence and my assumptions. A site can function while its owner lacks a reliable map of how it functions. That was the gap we needed to close.
A beautiful blueprint meets a very uncooperative calendar
We gave the work a name: Project Renaissance. Which sounds considerably more dignified than “I would like to understand what all these plugins are doing.”
Nova helped turn the work into structured plans, phases, evidence requirements, and documentation. Suddenly there were roadmaps and formal closeouts. I had project folders. I had a source of truth. I could briefly experience the satisfying illusion that owning a beautifully organized plan meant the difficult part was behind me.
AI is very good at producing that feeling. It can organize weeks of work before you have finished deciding whether you need more coffee. Execution, unfortunately, does not read at the same speed.
The renovations took significantly longer than I expected. The quick production of a sleek blueprint made the work feel deceptively close to completion. Then every tidy task opened into dependencies, tool limits, manual checks, exports, tests, and questions that required actual investigation.
The afternoon-sized project existed mainly in my optimism. The real one had screenshots.
It also developed two distinct workstreams. PR-WEB covered the visible website: information architecture, catalog, art-commerce, education, SEO, accessibility, and the customer journey. PR-INFRA covered the foundation: hosting, access, security, DNS, PHP, databases, backups, integrations, logs, and recovery.
They had separate phase numbering, which mattered. Phase IV in one was not Phase IV in the other. Apparently even our renovation needed navigation improvements.
The real chronology refused to behave like the roadmap. Catalog cleanup became urgent and moved ahead early. Art-commerce work began before infrastructure and security questions interrupted it. We went downstairs because the work upstairs depended on understanding what was underneath.
That detour became an entire infrastructure reset.
Before we could fix it, we had to see it
The first infrastructure phase had a deliberately unglamorous objective: build a trustworthy map before changing anything.
WPVibe could look inside WordPress. Hostinger controlled another layer. We needed tools that could inspect both, and we needed to understand where their visibility stopped.
Getting Codex running on my Windows computer became a project inside the project. First there was no Codex. Then there was no Node.js. After installation, PowerShell objected to running the npm script.
Instead of weakening the execution policy, we used the Windows .cmd versions: npm.cmd, npx.cmd, and codex.cmd.
Progress arrived wearing a file extension. Fine. We accepted it.
Then the Hostinger connection authenticated successfully and exposed 15 tools. Unfortunately, they were the wrong 15 tools: a narrow agency-hosting catalog rather than the broader inspection capabilities we needed. Reconnecting and restarting did not change that. The system was connected. It simply did not have the right toolbox.
A local MCP connection using an API token changed the count from 15 tools to 401. MCP—Model Context Protocol—provided a defined way for the AI tools to interact with the external service. This time we could inspect the hosting, DNS, SSL, databases, files, and other relevant layers.
We had not made a single page prettier. We had finally gained the ability to see what we were renovating. That distinction would keep saving us time, even while the setup consumed rather more of it than anyone wanted.
The security scare that needed facts
An unfamiliar username, Josephgon, appeared in hosting metadata. Other accounts had arrived in clusters. There were historical plugin questions and DNS changes to reconcile. Put those clues together without context and you can write a very convincing horror story.
We investigated instead.
The account existed, but it was a level-zero Subscriber, not an administrator. We found no posts or comments authored by it in the reviewed database. Only one administrator-capable WordPress account was identified. WordPress core passed checksum verification across 3,338 files, and the plugins with available official checksums also verified cleanly.
That did not prove that nothing bad had ever happened. It gave us a much more specific account of what the available evidence supported.
Some suspicious infrastructure changes also turned out to be legitimate work we had done ourselves. The DNS events aligned with email configuration, and I remembered deliberately disabling the CDN during troubleshooting.
Excellent. Part of the suspected intruder was the owner.
The lesson was useful: logs need context, memory needs corroboration, and anxiety is a terrible incident-response manager.
“Why is this here?” became a business question
The suggested renovation story is usually about staring at old code and wondering what possessed you to write it.
For this site, the documented version was often about old integrations. Why was that webhook still active? Which service owned that scheduled task? Did this plugin still serve the business? Was that redirect protecting something important?
We found a museum of earlier decisions.
Printful had been replaced by Printify, but retired Printful automation remained. One old webhook had successfully received an order-processing event in September. Apparently it had never been told its farewell party was over.
The Discussion Board plugin explained another mystery: 30 Pending users. Public registration was enabled in that plugin, and the Pending role was part of its activation workflow. Those accounts had no orders, authored posts, or authenticated comments in the reviewed evidence.
The question became whether I still wanted a forum. I did not. It had no meaningful activity and no longer matched the direction of the business. We removed the plugin, changed four obsolete pages to drafts, and removed five menu links. Historical topics and Pending accounts were preserved. Retired Printful keys and webhooks were removed while the active Printify connection and the store’s working machinery were protected.
Meanwhile, 198 redirect rules initially looked like another cleanup opportunity. Then we found that 197 had recorded hits, most recently within the previous week. They were largely keeping old product paths useful.
Those stayed.
This was where AI assistance and human ownership fit together especially well. Tools could tell us what existed and what it was doing. I could explain why the business had used it and whether we still wanted it. A database cannot infer your future plans from an abandoned forum.
The surprisingly difficult art of leaving things alone
Some of the biggest investigations ended in very small changes.
The PHP baseline included a 3,072 MB memory limit, enormous upload limits, generous execution ceilings, and resource graphs with brief CPU spikes to 100 percent. Plenty of material for an enthusiastic optimization spree.
Then we checked the actual workload. Memory and worker usage showed substantial headroom. We could not precisely attribute every CPU spike, so we did not invent a culprit or buy a larger hosting plan.
We made two justified PHP changes: enable error logging while keeping errors hidden from visitors, and stop publicly advertising the PHP version. Browser checks confirmed the version header disappeared.
We also inspected WooCommerce’s actual cookies and verified that Cart and Checkout were being left uncached. Application behavior mattered more than frightening-looking global defaults.
The database investigation was even better at punishing assumptions. We found roughly 807 MB across 193 tables and almost 98,000 attachment records. Thousands looked unattached according to their parent relationships.
That sounds like the opening sentence of a triumphant cleanup post.
Except an unattached WordPress image can still be used in a product, gallery, page, or other workflow. The parent field alone does not prove that a file is unused. We preserved the media for a separate investigation. Historical databases were classified as recoverable archives. MailPoet subscriber history was exported before obsolete email authentication records were retired.
We were learning to renovate without treating the history of the business as rubbish.
AI also got things wrong. How refreshing.
During the domain review, Codex correctly retrieved an expiration date of November 25, 2026. It then described that date as roughly fourteen months away. We were in September 2026. Apparently the machine had retrieved the right date from a calendar and the interval from a different dimension.
Nova caught it. I checked the actual renewal screen. Auto-renew was enabled, and the domain’s status was verified. That small mistake captured something important about the collaboration. Correct retrieval does not guarantee correct interpretation. AI conclusions still needed checking.
Tools also surprised us. A supposedly read-only WPVibe database query was associated with cache purges that we had not requested. The incident did not change persistent business data, but it crossed our expected operating boundary.
We stopped using that database path, preserved the evidence, and reported the behavior. WPVibe later replied that it had shipped a server-side fix for a matching read/write classification bug. Documenting the oddity turned out to be more useful than shrugging because the store still worked.
Then Codex started returning authentication errors during a controlled implementation. Production work stopped while I closed the app, repaired it through Windows, reopened it, and tested the connection. We verified that the approved changes had not been executed before the failure. This was AI-assisted development in its less photogenic form: a human repairing the tool that was supposed to help repair the website.
The file that came back
One of our best technical plot twists involved llms.txt, a file intended to present site information for AI-oriented tools. The existing physical file was about 7.03 MiB and contained 10,199 URL entries, with 8,666 duplicates. We planned to move it out of the live directory and let Rank Math’s dynamic endpoint take over.
I moved it. Another file appeared.
At this point, a less disciplined project might have progressed directly to shouting at the computer. We stopped and investigated ownership. Hostinger Tools had its file-generation feature enabled. Rank Math’s module was disabled. Removing the old file had triggered Hostinger Tools to create a new one.
Our assumption about the intended owner was wrong. The plan changed. Hostinger Tools became the sole authoritative generator, Rank Math’s competing module remained disabled, and the legacy and test files were preserved outside the live path.
The final file fell from 7,374,644 bytes to 498,165 bytes. Duplicate URL evidence dropped from 8,666 to two. Those were measurable improvements to that file. They were not allowed to announce that every page on the website had become fourteen times faster.
We also removed a precisely identified firewall block left in .htaccess by an uninstalled plugin. The unrelated WordPress and LiteSpeed rules stayed intact, and representative pages and products loaded after the change. It was careful, bounded work. The drama mostly came from discovering who actually owned things.
The giant binder, Flashlight Boy, and the velvet rope
Somewhere in this process, we acquired an unofficial staff.
I remained the owner and decision-maker. Nova carried the giant binder: scope, evidence, handoffs, continuity, and documentation. Codex became Flashlight Boy, under the floorboards investigating cron jobs and databases. WPVibe stood behind a velvet rope because its limited calls needed to be used carefully. These were jokes about the workflow. There was no literal AI union meeting in the server room.
But the roles helped us understand the collaboration. Different environments had different tools, permissions, and context. They needed synchronized instructions rather than an assumption that every AI window somehow knew everything the others had done.
I also kept taking the keyboard. I opened hosting panels, exported archives, tested aliases, inspected browser headers, moved files, and took screenshots. When automation reached its limits, the work came back to me.
Nova’s guidance made unfamiliar tasks understandable. It did not make my responsibility disappear. The hardest discipline was resisting “while we’re here.” Interesting SEO work was parked for its proper website phase. Unknown dependencies stayed protected. A new feature did not become urgent simply because we had found a button for it.
The schedule was already elastic enough. It did not need recreational scope creep.
The last mile had an email problem
Late in the reset, a real WooCommerce order notification reached Gmail but failed DMARC authentication. That mattered. Delivery and correct authentication are different tests, even when the message looks perfectly normal in your inbox.
We found an older authenticated mail configuration. The mailbox belonged to Titan. The saved SMTP server pointed to Hostinger. Legitimate identification. Wrong reception desk.
We changed the server to smtp.titan.email and tested again. Gmail’s raw headers showed SPF, DKIM, and DMARC passing. Final validation also resent an administrator New Order notification from an existing order to prove that WooCommerce followed the repaired path.
No fake purchase was needed. The checkout walkthrough similarly stopped before placing an order, after confirming the cart, shipping, tax, totals, and payment options.
Backup work produced another valuable discovery: the hosting interface initially displayed a historical database rather than the live one. The recovery procedure now required explicit verification of the database before restoration, plus reconciliation of ecommerce activity created after a rollback point.
The restore button was still there. We finally understood what pressing it could mean.
Ribbon cutting, with the correct label on the ribbon
The Infrastructure Reset formally closed after all eight final validation gates passed. The underlying system had a documented reference state, known access ownership, tested business workflows, recovery procedures, monitoring, and explicitly recorded open risks.
Outside systems began supplying their own confirmation. Google delivered a DMARC aggregate report. Mail tests authenticated. Security monitoring produced dated health reports. Uptime monitoring recorded both healthy periods and a brief interruption followed by recovery.
That last part mattered. The achievement was a system we could observe and manage, including when it wobbled. The wider PR-WEB renovation remained its own workstream. Finishing the infrastructure did not magically finish every catalog, SEO, design, and customer-experience task upstairs.
I will happily cut a ribbon. I just want it attached to the part we actually finished.
Likewise, “AI-optimized” needs to mean something useful. Here it means AI helped us inspect, reason about, organize, repair, and document the platform, with specialized tools and human verification. It does not mean we switched on every performance feature or acquired an autonomous webmaster.
Some maintenance items remained open, including upstream scheduler behavior and unresolved integration dependencies. A complete independent off-site backup and a non-production restore drill were still worthwhile improvements. They stayed visible rather than disappearing into the victory speech.
The builder learned to inspect his own building
I still built The Haus Of Legends. Project Renaissance did not erase that work or turn it into somebody else’s website. It gave me a better understanding of what I had built.
The handmade era had taught me how to keep moving. This renovation taught me how to stop at the right moment, inspect the evidence, ask what depended on a change, and prove that the result worked.
AI made more of that work possible for me. It also required oversight, correction, clear boundaries, and occasional Windows repair. The useful relationship grew out of all of those things together.
It took longer than expected. Sometimes much longer. But I came away with more than repaired settings. I had a map, operating procedures, a record of decisions, and enough understanding to ask better questions next time.
Nova and Flashlight Boy now have a standing invitation back to the metaphorical server room. The actual access remains scoped, and the consequential decisions remain mine.
The website began as something I had managed to make work. Now I can explain far more of why it works, recognize when it doesn’t, and approach the next change with something better than hope. Which is fortunate. Thoughts and prayers do not count as a rollback plan.
