Dev Log: Why I Built This Site and How I Designed the Writing Pipeline

I’ve tried to write consistently more times than I’d like to admit. Notion weekly reflections, Twitter threads, WeChat articles, journaling apps. The pattern was always the same: a few solid entries, a growing gap, then silence. At some point I’d quietly archive the template and pretend it never happened.

For a while I assumed the problem was discipline. Then it happened enough times that I started questioning that story.

Why build a site at all

The obvious question is: why not just write on an existing platform? Medium, Substack, 公众号 — they’re all free, they handle hosting, they have built-in audiences.

I tried those. The problem wasn’t the platforms. The problem was that every platform adds its own friction — its own formatting rules, its own editor quirks, its own expectations about what a “post” should look like. And they all come with an audience you can’t control. When you’re starting out and every post gets zero engagement, the platform’s metrics become a constant reminder that nobody cares. That’s a motivation killer.

I wanted something different. A place that’s mine. No analytics dashboard staring at me. No follower count. Just a list of things I’ve written, getting one line longer each time I publish something.

That’s what One Mile Lab is. A digital garden — more like a book index than a blog. No feeds, no comments, no like buttons. Just titles, dates, and words.

The stack: optimized for one thing

The tech stack for this site is almost comically simple. Astro, Markdown files in a Git repo, deployed on Cloudflare Pages. No database. No CMS. No auth. No admin panel.

Every post is a .md file with some frontmatter — title, type, date. That’s it. I chose Astro because it generates static HTML with zero JavaScript by default. The site loads instantly and I never have to think about it breaking.

But the stack isn’t the interesting part. The interesting part is what sits in front of the stack.

The publishing flow

Here’s the thing that actually matters: the distance between “I have a thought” and “it’s live on the internet.”

In every previous attempt, that distance was too long. Here’s what the old flow looked like, give or take:

Have a thought
Open the writing app
Find the right page or template
Stare at it for a while
Start writing
Edit and re-edit
Question whether it’s good enough
Close the tab
Never publish

Steps 2 through 8 are all friction. Individually, each one is small. Together, they’re enough to make “I’ll do it tomorrow” win every time.

So I designed the new flow around one question: what’s the minimum number of steps between a thought and a published page?

The answer I landed on:

Tell my AI copilot what I want to write about
Review the draft it produces
Say “publish”
It creates the Markdown file, commits to Git, pushes. The site rebuilds automatically

That’s it. The thinking is mine — the ideas, the observations, the opinions, the specific experiences. The AI handles the part I don’t care about: formatting, frontmatter, file management, deployment. The stuff that used to be the reason I gave up.

Tonight I tested this for real. I told my copilot “I want to write about why I keep failing to write consistently, and what I’m changing this time.” Five minutes later, there was a draft. I read it, made some adjustments, said publish. It was live.

The AI copilot setup

My copilot has a publishing skill — a set of instructions that tells it how this site works. It knows:

Where the content lives (src/content/garden/)
What the frontmatter schema looks like
How to name files (kebab-case)
How to commit and push
Most importantly: how I write. My voice. Short paragraphs. Direct. Honest about uncertainty. No corporate speak. No clickbait titles.

That last part took iteration. The first drafts the AI produced were competent but generic — they could have been written by anyone. So I wrote a voice guide into the skill: specific examples of what my writing sounds like versus what it shouldn’t sound like. The difference between “I decided to optimize my workflow” and “I got tired of fighting with YAML frontmatter every time I wanted to publish something.”

The skill also has a hard rule: never publish without showing me the full draft first. The AI proposes. I review. I say go. It’s a collaboration, not delegation.

Why this works (so far)

I think the reason previous attempts failed wasn’t lack of discipline. It was bad system design. Two things were missing:

Positive feedback that doesn’t depend on other people. When I publish a post and see the list on the homepage grow by one line, that’s enough. It’s the same psychology as GitHub’s green squares. You’re not doing it for the squares. But the squares make you not want to break the chain. I chose the book-index format for exactly this reason — every entry is visible, permanent, accumulating.

Low enough friction that zero-motivation days still work. On a good day, I’ll write 2,000 words with subheadings and a thesis. On a bad day, I might write 200 words and a question mark. Both are fine. The flow is short enough that “I don’t feel like it” doesn’t automatically mean “I won’t do it.” There’s a version of publishing that takes five minutes and feels like nothing.

The cross-posting experiment

Tonight I also tried something new: turning a blog post into a 小红书 image carousel. My copilot has a skill for that too — it takes an article, generates 8 slides as HTML, screenshots them to PNGs, and writes a caption.

The first version looked like a product training deck. Symmetrical cards, neat emoji headers, clean summary sentences. Technically correct, emotionally dead. It took three rounds of iterating on the skill’s instructions to get output that actually felt like a person sharing their experience instead of an AI presenting a framework.

The lesson: the pipeline works, but the voice tuning is everything. The tool can format and publish in seconds. Making it sound human — that’s the part that still needs me.

Where this is now

Three posts in the garden. A publishing flow that actually works. A cross-posting pipeline that needs more tuning.

I set myself a simple success metric: still publishing at least once a week, 8 weeks from now. Not word count. Not quality. Just consistency. If I’m still going, something is genuinely different this time. If I’m not — well, that’s data too.

The site is called One Mile Lab because the idea is simple: move forward a little bit every day. One mile. One experiment. One post that didn’t exist yesterday.

Let’s see if this time sticks.