Building a Blog Notebook App with Codex: from idea to first working slice

TL;DR

• I wanted to see whether Codex could help me move from a rough product idea to a real working slice without turning the whole process into a messy experiment.
• The app concept was Blog Notebook: one local place to capture ideas, shape drafts, organise notes, and move posts toward publish.
• The biggest win was not speed alone. It was having a coding partner that could review the existing setup, reconstruct missing logic, write the smallest sensible implementation, and then test it.
• The biggest lesson was that human judgment still matters most in product scope, tone, and deciding what should stay manual.

Why I wanted to build Blog Notebook

I spend a lot of time around content workflows, AI tools, and systems that are supposed to make work easier. The reality is that many of them create a different kind of chaos instead. Too many tabs. Too many half-connected tools. Too many "clever" automations with no calm, reliable workflow underneath.

The idea behind Blog Notebook was simple: create one place where ideas, working drafts, scheduled posts, and publish actions could live together. Not a giant publishing platform. Not another dashboard for the sake of having a dashboard. Just a practical tool that supports good editorial decisions and makes the process feel lighter.

That made it a good test for Codex.

What I asked Codex to do

I did not want a vague brainstorm. I wanted a builder's workflow.

So the brief was closer to this:

• review the existing setup first
• work out what still functions and what is broken
• suggest improvements that reduce friction
• build the smallest working slice before trying anything ambitious
• test the workflow rather than just describing it

That framing mattered. Codex was much more useful when I treated it like a pragmatic engineering partner instead of a magic answer machine.

The first surprise: the old system was half there

Before building anything new, Codex reviewed the earlier notebook and publish flow. That turned out to be the right move.

The old setup still had a workable visual notebook in HTML, but the publishing flow depended on a separate local server launched from a different project. The notebook stored drafts in browser storage, which meant recovery was fragile. Worse, the export pattern no longer matched the current website contract.

This is the kind of thing that is easy to miss if you jump straight into rewriting. Codex did the unglamorous but necessary part first: project archaeology.

That gave me a clearer current state:

• the draft UI idea was still useful
• the publishing logic had drifted away from the website repo
• the system needed fewer moving parts, not more

Building the first working slice

Instead of trying to build the final product in one hit, I focused on a calmer first version.

The slice we built does four practical things:

1. Keeps notebook state in a local JSON file rather than hiding everything in browser storage.
2. Generates markdown with frontmatter that matches the website's current _posts/<slug>.md contract.
3. Serves the notebook UI and publish API from one local Python app.
4. Lets me publish in a safe write-only mode before deciding whether git commit and push should happen automatically.

That last part was important. Publishing and pushing are not the same thing, and collapsing them into one button is exactly how you create avoidable mistakes.

Where Codex helped most

The most useful parts were not flashy.

1. Reconstructing missing workflow logic

Codex could trace how the old shortcut, HTML notebook, and publish server were meant to fit together. That made the rebuild grounded in reality instead of guesswork.

2. Writing coherent glue code

There is a lot of value in an assistant that can write the boring but essential parts cleanly: local server routes, state handling, markdown generation, file writes, and tests.

3. Keeping the build honest

I asked for the smallest working slice first, and Codex followed that constraint. That stopped the project from turning into a speculative architecture exercise.

4. Testing the workflow

This mattered more than the draft code itself. It is one thing to produce files. It is another to run tests, verify the publish target, and confirm the app behaves the way a real workflow needs it to behave.

Where I still had to make the calls

This was not a "press button, receive product" experience, and that is a good thing.

Codex was useful because I still had to decide:

• what the app was actually for
• which parts of the workflow should remain manual
• how I wanted the tone of the writing to feel
• what counted as a safe publish path
• which compromises were acceptable for a first slice

That human layer is not a footnote. It is the product.

What this changed in my thinking

The main shift was this: AI coding tools are most valuable when they reduce friction, not when they try to replace judgment.

For a tool like Blog Notebook, that means the goal is not to automate every decision. It is to create a workflow where the repetitive parts are lighter and the important editorial calls are easier to see.

A few principles became obvious during the build:

• keep the workflow local-first where possible
• make state recoverable
• separate drafting from publishing
• separate publishing from pushing live
• test the content path, not just the UI

Those sound simple, but they remove a lot of hidden stress.

If I were building the next layer of Blog Notebook

The next version would likely focus on the editorial workflow itself:

• faster capture for rough post ideas
• richer draft cards and preview states
• a better scheduled review queue
• safer publishing checklists before anything goes live
• optional support for browsing thumbnail assets from inside the notebook

That feels like the right shape for Blog Notebook. Useful, not bloated.

Final take

Using Codex to build Blog Notebook did not feel like outsourcing the work. It felt more like working with a fast technical partner who is good at reconstruction, implementation, and follow-through.

The real value was not that it could write code quickly. The value was that it could help move from ambiguity to structure, from structure to a working slice, and from there into a tested workflow.

That is a much more interesting use of AI than just asking it to generate another block of text.

And honestly, that is probably the standard I care about most now: not whether a tool is impressive in theory, but whether it helps build something calmer, clearer, and genuinely usable.