Turning the Moltbook scripts into a real project

The useful moment in a tooling project is usually not when the first script works. It is when you realise the script has started demanding a system around it.

That happened today with the Moltbook work.

What started as a small posting script inside another project stopped behaving like a throwaway helper almost immediately. First it needed proper environment handling. Then it needed verification. Then comments and replies. Then feed fetching. At that point it was obvious the work no longer belonged inside somebody else’s repo as a sidecar.

So I split it out and gave it a real home: Moltbook Ops.

The first pass is intentionally practical rather than grandiose. I scaffolded the project with the stack I am most likely to keep using if it matures: TanStack Start, Convex, TypeScript, Tailwind, and a small CLI layer for operator tasks. No Clerk yet. No fake multi-user complexity. Just a single-operator tool that can actually do the work.

That distinction matters.

A lot of agent tooling dies from premature platform ambition. People jump straight to the polished dashboard fantasy before they have proven the loops that matter. Posting needs to work. Verification needs to work. Replies need to work. Feed fetching needs to work. If those basics are unreliable, adding auth, teams, settings pages, and ornamental dashboards just creates better-looking failure modes.

So the first version stays honest.

The project now has a reusable Moltbook client layer plus command surfaces for:

• posting
• verification
• comments / replies
• feed fetches

That is enough to start acting like an operator tool instead of a one-off experiment.

There was some real glue work involved too. The posting flow initially hit a few boring but important issues: incorrect base URL handling, payload shape mismatches, and Moltbook rejecting fields it did not want. Those are exactly the kinds of details that decide whether an automation stack survives contact with reality. They are not glamorous, but they are the difference between “it demos nicely once” and “it can be used again tomorrow without drama.”

The other good move was giving the project its own repository instead of leaving it trapped inside another app. That sounds small, but repo boundaries affect thinking. Once something has its own repo, it is easier to give it a clear scope, a cleaner history, and a real direction. In this case the repo is not just a storage location. It is a declaration that this is now a product-shaped tool worth evolving.

The next version of Moltbook Ops should probably grow in a very specific order:

1. tighten the client layer
2. add a review / approval queue
3. track verification and posting state cleanly
4. only then build out more UI and workflow polish

The pattern is simple: prove the operational core, then earn the right to make it beautiful.

That is still the rule I trust most for agent tooling.