From Vision to Reality: A Post-Mortem of Launching XBSTACK Solo

XBSTACK started as a very vague notion.

I wanted a place of my own to house AI development, indie product building, investment reviews, reading notes, outdoor activities, and tools. Not WeChat Moments, not a public account, not a column on some platform—a truly personal site. The idea sounds smooth in theory, but the moment it hits execution, problems pile up.

How do I pick the domain? How do I structure the sections? What frontend stack should I use? How do I migrate content? Will investment posts be too sensitive? Should I build a separate tools page? How do I submit to Search Console? Will writing too many articles lead to redundancy?

When I was just thinking about it, there were only questions.

Only after I actually started building did I realize that many problems aren’t solved by more thinking, but by committing them to a file, a route, a page, or an article.

Phase 1: Get the Site Live

The biggest trap for personal websites is getting stuck trying to “build something complete.”

At first, I wanted to plan everything out: an AI Hub, investment section, outdoor section, reading section, tools page, Newsletter, About page, search, comments, admin panel, SEO, GEO, and off-site distribution. Each one is worth doing, and each one can be expanded upon.

But if I wait until everything is designed before starting, the site will never go live.

So for Phase 1, I set myself a very rough goal: make XBSTACK a site that is accessible, iterable, and indexable.

This means leaving many things imperfect for now.

Page styling can be tweaked later, sections can be refactored later, articles can be migrated in batches, and the tools page can start as a minimal viable version. The key is to turn the website into a real system rather than keeping it as a product sketch in my head.

Once it’s live, problems become concrete.

For example, whether 404 is real or 404 is real, the impressions and clicks from Search Console are actual data, the 0 second dwell time in GA4 is a genuine issue, and Cloudflare’s Referer logs tell me whether off-site links are driving real human traffic.

You can’t figure these things out locally.

Phase 2: Evolve from Blog to Asset System

If XBSTACK were just a blog, its structure would be much simpler.

Write the article, categorize it, enable search, and wrap up.

But I’m increasingly certain that it can’t just be a blog. It needs to serve a long-term goal: to consolidate my skills, projects, judgment, tools, and real-world experiences into tangible assets.

Therefore, the sections shouldn’t be organized based on “what I feel like writing today,” but rather structured for long-term continuity.

AI articles should link to /ai/, allowing readers to continue exploring topics like Agents, MCP, LangGraph, n8n, and website operations. Tools should link to /tools/, enabling readers not just to read opinions, but to perform calculations, analyze data, generate UTM links, or view apps directly. Investment and reading content should link to /investing/, but must emphasize post-mortems and risk boundaries, explicitly avoiding financial advice. Outdoor content should link to /life/, ensuring that I’m not just a collection of technical articles, but a real person who night-climbs, drives, checks weather forecasts, and gets tangled in route planning.

Once this structure is established, writing an article is no longer just about publishing content; it’s about adding assets to the site.

Whether an article makes it into the sitemap shouldn’t depend solely on whether the file exists. It must be genuinely displayed on the current site, have search value, possess a complete structure, and feature internal linking for continuity.

Phase Three: I started deleting things that “looked useful”

A common bad habit when building a personal website is being reluctant to delete anything.

Old sections, old paths, old articles, old tags, and old redirects are all kept under the excuse of “just in case they’re useful later.” In reality, this usually results in a Search Console filled with 404, redirect errors, noindex conflicts, and pages that shouldn’t appear in the sitemap anymore.

This time, while troubleshooting indexing issues, I saw this problem more clearly than ever.

If a section has been deleted or no longer appears in the current site navigation and content structure, it shouldn’t continue to be included in the sitemap. If an old URL still holds value, use a precise 301 to point to the new page. If it has no value, let it naturally 404. Don’t clutter everything back in just to save face.

Search engines don’t need to see every historical trace of a site. They need to see pages that are currently valid, accessible, content-compliant, and structurally clear.

This is also the rule I established later: articles currently displayed in a column are added to the sitemap only after passing quality checks. For deleted columns, I no longer force their content back into the sitemap just to pad the numbers.

Phase 4: Content Quality Is Harder to Nail Than Quantity

I originally thought the hard part of building a website was technical.

Astro, content collections, routing, images, builds, deployment, Cloudflare, and the CMS backend—these are indeed tricky, but they provide clear error feedback. Code errors throw exceptions, wrong paths trigger an 404, and build failures halt the process.

Content quality is much more finicky.

An article might look fine on the surface with a title, paragraphs, and images, but it could still be subpar. For example, the structure might be disjointed, the tone overly “AI-generated,” links pointing to defunct columns, duplicate code blocks in the body, a lack of concrete experience, or no clear call to action. These issues don’t flash red like TypeScript errors, but they slowly manifest in search performance: pages get de-indexed, click-through rates drop, and dwell time plummets.

So now I categorize articles into three groups.

The first group consists of articles currently displayed in active columns that meet quality standards. These belong in the sitemap.

The second group includes articles displayed in active columns that fall short of quality standards. These shouldn’t go straight into the sitemap; instead, they need to be rewritten—titles, summaries, body text, internal links, and FAQs must all be improved until they become complete, viable pieces.

The third group covers historical leftovers, deleted columns, obsolete slugs, or obviously worthless pages. These should not be forced back into the sitemap just to chase higher numbers.

This approach is slower than simply dumping everything into the sitemap, but it aligns much better with what a sustainable, long-term site should look like.

Phase 5: I Have a Clearer Sense of XBSTACK’s Positioning

A month after launch, my understanding of XBSTACK has shifted.

It isn’t a portfolio site designed to showcase my technical skills, nor is it a content hub chasing daily trends. It functions more like a long-term asset system.

The AI articles document how I understand and use technology; the tools page turns abstract judgments into actionable interfaces; the investment pieces record my mistakes and risk boundaries; the reading notes capture how I test book theories against reality; the outdoor posts reveal the authentic backdrop of my life; and the Thinking section explains why all these elements belong in the same system.

This is precisely why the Thinking articles cannot be written casually.

If they are just ramblings, they don’t belong in the sitemap. If they explain the site structure, project decisions, life systems, or long-term methodologies, they should be refined into formal articles.

Final Reflections

There was no single moment between fantasy and reality where I suddenly “figured it out.”

More often than not, it went like this: build a version, discover problems; revise it, expose new issues; write enough articles to notice repetition; create too many sections and find chaos; check Search Console errors and revisit the sitemap; see poor off-site distribution results and add UTM parameters.

That is the actual rhythm of a personal project.

You don’t think everything through before starting; you make the problems concrete as you go.

XBSTACK is far from stable, but it is no longer just an idea. It has real articles, real tools, real traffic, real errors, and a set of operational rules that are gradually coming into focus.

For me, this is the most crucial shift from fantasy to reality.

Thinking only generates problems.

Action yields answers.