Henry's Room · Chapter One: From an Idea to a Real Website

About this chapter

This first chapter records the period from the earliest traceable version on September 5, 2026, to October 24, 2026.

It is a retrospective: why I started, what happened, why I kept changing things, and how I now see this space. Technical analysis belongs in Chapter Two.

Project and article by Henry, with OpenAI Codex assisting development and organization. Credits for open-source projects and third-party services appear at the end.

1. At First, I Just Wanted Somewhere of My Own

The project began with an ordinary question: could Cloudflare’s free services help me build a website?

I did not have a complete plan. I certainly did not know what it would become.

I wanted a blog: somewhere for technical experiments, experiences with photography, and thoughts from everyday life.

Visually, I wanted clarity, whitespace, order, and some of the restraint I associate with Apple products. Not a portal, not a screen crowded with modules, and not another indistinguishable template.

Looking back, the first wish was not to own a feature-complete system. It was to have a place that belonged to me.

By September 5, the earliest traceable version had a home page, articles, an archive, and an about page.

Seeing those pages open under my own domain was enough to make the beginning feel real.

But a first version is not a finished website.

The actual tinkering had only just begun.

2. September 5–6: A Website, but Not Yet a Comfortable Place to Write

I did not want every writing session to begin with tasks unrelated to writing.

One early addition was therefore a browser-based editor: open it, write, publish, and see the article on the site.

The idea sounded simpler than the experience.

The login was especially confusing. A wrong password produced an error. The right one produced nothing: no explanation and no next screen.

Later, I sometimes got inside only to find an unresponsive page. Logout seemed to be the only working action; refreshing sent me back to login.

My question was straightforward: “If the password is right, why can’t I get in?”

That confusion has nothing to do with attractive buttons. You cannot tell whether to wait, try again, or use another browser.

Another problem appeared after publishing. The new article was visible on the home page but missing from the admin list. One piece of writing seemed to occupy two different realities.

The site did not merely need to do something. It needed to tell me whether that thing had actually happened.

Those days brought less visible work: saved-state feedback, drafts, previews, errors, and finding an article again after publishing it.

These details decided whether I would want to return to the editor.

At first, “zero to one” meant a reachable website. Now I wanted that “one” to let me write the next article comfortably.

3. September 7–12: More Changes, and More Things That Felt Wrong

The most common feedback became: “Something about this feels strange.”

Why was the title off-center? Why did one final character wrap alone? Why was light mode flat? Why did collapsing the archive pull the footer upward?

Sometimes I could not name the problem precisely. I knew it looked wrong, but not whether the cause was type, spacing, or the relationship between sections.

So I described the feeling, looked at the next version, and continued.

A Writing Tool Cannot Just Accumulate Buttons

The editor grew in the same way.

First it accepted text and published. Then came different writing modes, formatting, images, previews, word counts, and history.

More features brought new problems: tools had no clear order, the mobile toolbar filled too much of the screen, and mobile fixes made the desktop editor unnecessarily narrow.

I eventually said explicitly that desktop and phone needed different interaction layouts, not one page scaled up and down.

By September 12, the two experiences were genuinely separating.

A tool that becomes more powerful but less inviting to open is still unfinished.

Why Did One Progress Bar Take So Long?

Publishing feedback needed repeated attention.

Sometimes it said published before the article was live. Sometimes success appeared while progress continued. Sometimes leaving the page erased the progress without finishing the work.

I commented on its position, shape, and dismissal behavior. Increasingly, however, the question was whether I could trust it.

When a page leaves me wondering whether to publish again, polish does not remove the uncertainty.

This problem did not end in those first days. It remained something the project returned to.

I Was Very Attached to the Moving Background

I also spent a surprising amount of time adjusting the background.

I wanted breathing color: faster motion, stronger tones, less repetitive paths, perhaps another color.

Then the three patches felt too obvious. Their centers were too dark. Removing the centers produced rings. Another version resembled transparent circles. Another seemed entirely blue.

The sequence is slightly funny in retrospect, but it was genuine.

I wanted the first instant on the site to feel right. Repeatedly adding effects did not reliably produce that feeling.

Some versions looked appealing but made scrolling feel delayed, as though the content arrived a beat late. The thing meant to make the page alive was making reading less comfortable.

I had not yet let it go, but I was beginning to wonder whether the quality I wanted required adding anything at all.

4. October 17–19: It Began to Feel Like My Room

By mid-October, another substantial round of changes began.

This time I looked beyond individual buttons and patches of color.

Was this a technical blog or somewhere broad enough for different experiences? What mattered most on the home page? Why did a feature-rich site still feel unfinished?

The name settled into Henry 的空间, with Henry’s Room in English. The short Henry logo remained, and the home-page line became:

Stay curious. Keep making progress.

Under it sat technology practice, observations, and progress notes.

The separate photography section disappeared, but photography was not excluded. I simply no longer wanted every interest to demand a permanent home-page module.

About, Now, and the home-page status area began saying different things rather than repeating one introduction.

The Articles Started Recording Real Projects

I wrote about localizing Sapphire, Henry Media Library, and Henry Model Manager.

Not every project reached the finish line.

The abandoned AI API gateway and the iOS-style gallery that inspired the media library also deserved articles.

A personal space should not display only completed work. Expectations, changes of direction, and decisions to stop belong in the record too.

For the first time, the site was more than a structure waiting to be filled. It had a history of its own.

Writing those articles also made attribution a clear requirement. Upstream projects and their authors needed naming. My changes should not blur into someone else’s work behind the phrase “I built this.”

Finally, I Let the Always-Moving Background Go

Performance became impossible to ignore.

After the blog had been open for a while, my computer became warm and the fans noticeably spun up.

That contradicted the original purpose: somewhere people could stay and read, not a display that kept their devices busy.

On October 18, the persistent aurora background was removed. The visual direction became quieter, more paper-like, and more local in its depth.

It was an important decision to abandon something deliberately.

Not everything that takes time to build deserves to stay.

Sometimes removing it brings the project closer to its original purpose.

5. October 18–22: Thinking About the Person on the Other Side

Comments, subscriptions, and friend links changed the responsibilities of the site.

Other people’s words, email addresses, waiting, and expectations were now involved.

Comments Need More Than a Submit Button

I wanted random avatars, approximate locations, and replies that looked like conversations.

In use, replies initially resembled unrelated new comments. Location labels also produced reports that did not match the actual source.

I made a point of saying: do not lose existing comments while changing this.

That became a broader rule:

Interfaces can be rebuilt. Content already entrusted to the site cannot be treated as disposable.

I also wanted moderation and reply emails. They should look like a properly composed letter from the site, not a few careless lines.

Actual use exposed more gaps: missing reply notifications, unnecessary notifications between identical addresses, and long unbroken comments stretching email layouts until they were unreadable.

These were not grand architectural topics, but real recipients would encounter them.

A Notification Should Not Arrive Before the Article

Email subscriptions arrived on October 20.

Readers who wanted to return should not have to keep refreshing to discover new writing.

But collecting addresses was not enough. People needed confirmation, a clear idea of what they subscribed to, and a way out. I needed manageable states rather than vague messages.

Later, article notifications were moved after successful deployment.

I did not want someone to follow an email into an article that did not yet exist or was still the old version.

Mail quotas also needed visibility before sending stopped altogether, so they entered everyday administration.

Once somebody trusts a site with an email address or a thoughtful comment, “just experimenting” is no longer the whole explanation.

Friend Links Connected This Room to Other Places

By October 22, applications and management were forming a complete workflow.

Visitors could apply, while I could add a site directly in the admin.

This also had stuck saves and unclear approval-to-publication states.

It looked different from article publishing, but the user’s question was the same: I have acted; what is happening now?

Again, knowing where you are matters more than another attractive entrance.

6. October 22–24: Asking What Was Still Unfinished

The next optimization phase lasted many conversations.

I asked what remained, what could be grouped into the next batch, and why progress felt slow.

Early changes gave immediate satisfaction. Later work often could not be demonstrated with one before-and-after screenshot.

Some work reconciled publishing states. Some organized a growing admin. Some dealt with old content. Some made sure a working flow still worked when actions happened in a different order.

I established a boundary: keep the overall identity and existing articles, comments, and other data. Other areas could improve.

I also deferred certain tasks. Not every direction needed advancing at the same time.

This was not abandoning quality. It was recognizing different priorities and different limits on what could be verified immediately.

A Recovery Point Became a Condition of Making Changes

Earlier, I mostly asked whether the next version would look better.

Later, I routinely added: make a rollback backup first.

The site now held real writing and other people’s contributions. It was no longer an empty shell that could be rebuilt without consequence.

A way back made decisions easier. I did not need a website that could never fail; I needed failures not to erase what had accumulated.

Some Boundaries Cannot Be Made True by Renaming Them

Private articles came from a simple desire: keep writing here without letting every visitor read it.

Private comments, images, and attachments gradually entered that conversation.

But adding a “private” label does not rewrite history. Previously public resources remain a separate issue, and older relationships need author review.

I learned to say clearly what was done, what remained, and what could not yet be guaranteed.

7. October 24: Back to a Few Words and a Second on the Home Page

After the admin and existing issues, attention returned to the front end.

The featured text-to-cover proportion, article hierarchy, subscription typography, and mobile dock order were reconsidered.

The development journal’s filters were hard to read and followed scrolling awkwardly. Two statistics sections felt disconnected. These received focused changes.

This time, I did not want everything demolished together. Fix what felt wrong; preserve what already felt comfortable.

Despite everything the site could now do, the latest feedback still concerned tiny feelings.

Why did refreshing the home page make it twitch?

After that was fixed, why could I no longer see an entrance animation?

What I wanted was a light opening: content becoming clear without the layout jumping inward, and without having to wait for a performance before reading.

At the beginning, I might have asked for more spectacle.

By this point I cared more about appropriateness: did the effect help me stay, or take attention from the writing?

That change also reflected how I was beginning to see the whole website.

8. What I Want This Chapter to Preserve

Henry’s Room is now very different from those first few pages.

I can write, save unfinished work, preview, publish, and revise. Readers can find older articles, comment, subscribe, and save something for later.

What I am doing, what I have done, and what the website itself has experienced now have distinct places.

Features are beginning to relate to writing and reading instead of appearing merely because they can.

I do not want to end by declaring everything complete.

There will still be problems and habits I have not considered. Old material needs attention. Some experiences require longer observation.

This chapter records a transition:

From wanting a website, to making one, to accepting responsibility for it.

There was no dramatic single turning point. More often it was an ordinary improvement: login finally worked, an article could be found again, replies resembled conversation, or the background stopped keeping the computer busy.

Sometimes a fix looked finished until the next visit revealed another problem.

Those repetitions made the site more than an attractive first page.

In my essay about vibe coding, I considered how AI makes ideas easier to realize. Here I wanted to record what happens afterward: why I continue looking, using, and correcting.

This room does not need everything.

I hope it can hold things that actually happened: completed projects, unfinished plans, confusion at the time, later understanding, and questions without answers yet.

That is where Chapter One ends.

Chapter Two turns to implementation and technical choices. For now, I wanted to preserve the road itself.

Stay curious. Keep making progress.

Open-Source Projects and Third-Party Components

The following credits identify authors, upstream sources, and licensing. They are acknowledgments, not a technical analysis. Names, code, and trademarks remain with their respective owners.

Astro and Official Integrations

Projects: Astro, @astrojs/rss, and @astrojs/sitemap.
Authors and maintainers: Fred K. Schott, the Astro team, and contributors.
Upstream: withastro/astro.
License: MIT.
Use: pages, article content, feeds, and sitemaps.

Marked

Authors: Christopher Jeffrey, the MarkedJS team, and contributors.
Upstream: markedjs/marked.
License: MIT and accompanying notices.
Use: admin editing and previews.

Turndown

Author and contributors: Dom Christie and contributors.
Upstream: mixmark-io/turndown.
License: MIT.
Use: connecting visual and Markdown writing modes.

resvg-js

Maintainers: the resvg-js project and contributors.
Upstream: thx/resvg-js; the former yisibl/resvg-js address redirects there.
License: MPL-2.0.
Use: article share images.

Node.js

Maintainers: the Node.js project and contributors.
Website: nodejs.org.
License: MIT for the core, with separate bundled notices; see the official license.
Use: builds and development tools.

Python

Maintainers: Python Software Foundation and contributors.
Website: python.org.
License: primarily PSF License Version 2.
Use: deployment, backup verification, and automated checks.

Git

Maintainers: the Git project and contributors.
Website: git-scm.com.
License: GPL-2.0.
Use: content versions and development history.

The build includes transitive dependencies. Exact versions and obligations follow the lockfile and accompanying licenses. This is not a complete software bill of materials and does not claim upstream work as original.

Cloudflare

Provider: Cloudflare.
Website: cloudflare.com.
Services used: Pages, Workers, Workers KV, D1, Turnstile, and related network services.

GitHub and GitHub Actions

Provider: GitHub.
Reference: GitHub Actions documentation.
Use: source and article history, automated builds, and deployment.

Resend

Provider: Resend.
Reference: Resend documentation.
Use: website email notifications.

These are third-party services, not original open-source components of this site. Free allowances do not remove limits, fees, privacy terms, or provider conditions.

Design Reference

The visual direction draws on the typography, whitespace, and interaction order of Apple products. Henry’s Room is not an Apple product and has no official affiliation or endorsement. Trademarks remain with their owners.

This Project and AI Assistance

Henry initiated, designs, and maintains Henry’s Room, with OpenAI Codex assisting development and content organization. That assistance does not alter upstream licensing obligations.

At publication, the repository was private and no project-wide open-source license had been declared. Using open-source dependencies does not make the entire site, articles, or assets freely redistributable.

Sapphire, the media library, and the model manager are separate projects discussed here, not dependencies of the blog. Their articles contain their own credits.

No passwords, access tokens, backup keys, subscriber addresses, or visitor records appear in this article.

Project and article by Henry. Recorded through October 24, 2026. Further dates appear in the development journal.

Continue with Chapter Two: Turning a Blog into a System Worth Maintaining.