I thought I needed to build a content application

How an idea for a TypeScript content factory turned into a collection of files, an AGENTS.md, and a real Instagram post in one morning.

I had let the account go quiet

Rooibos Italia is a small business we run on the side. We import BOS Rooibos from South Africa and sell it in Italy.

We also have an Instagram account that I had left mostly untouched for a couple of years.

Marketing is its own skill and it takes time to do well. Images and videos need to be made, the copy needs to be written, and someone has to keep doing it after the first burst of enthusiasm wears off. BOS supplies us with some content, but not everything we need for the Italian account.

Eventually the account went quiet through a combination of limited time and a lack of enthusiasm.

One evening I was sitting at a table listening to other people talk about how they keep posting to their social accounts regardless. They had simply stuck with it. I felt a little guilty about leaving ours alone for so long.

I had already wondered whether AI could help me revive it. Not with the expectation of gaining thousands of followers. I mainly wanted the account to look alive again. If I could look back after a year and see more than 40 useful posts, that would feel like a real effort.

That night I started imagining the system I could build.

Naturally, I imagined an application

In my head it was a proper content factory.

An idea would enter one side. A Node.js and TypeScript application would expand it into content, store everything in PostgreSQL or SQLite, let me review the result, and eventually publish it automatically.

The proposed pipeline covered articles, Instagram posts, Reels, carousels, Facebook, Pinterest, emails, and image prompts.

It was quite a lot for an Instagram account I had not posted to in years.

I was already hesitant. I build software professionally, so I know that creating an application also means creating something to maintain. There would be dependencies, database migrations, integrations, credentials, and all the other things that arrive after the fun first version.

My recent experience with file-based AI systems had also made me question whether an application was necessary. I had already used an AGENTS.md, a ledger, and some templates to manage my English Expressions project. It could respond to natural-language instructions and move work through a defined process without a custom interface.

Instead of asking Codex to build my proposed application, I asked it to interview me first.

I let the assistant question the requirement

When I plan software at work, the requirement normally develops through discussion with several people. Someone asks a question, someone else spots an assumption, and the shape changes before we build it.

That discussion is missing when I work alone.

I had found one-question-at-a-time AI interviews useful while setting up this blog, so I tried the same method here. I gave the assistant the broad idea and asked it to quiz me for the context it needed.

The questions were simple:

• What do we actually sell in Italy?
• What should Instagram achieve?
• How often could I realistically post?
• Did I want to appear in videos?
• What images and brand material did I already have?
• Where should a customer go if they wanted to buy something?

My answers quickly made the original design look silly.

I was not trying to operate a multi-channel media company. I wanted to publish an Instagram image every week or two without each post becoming a small marketing project. I did not want to appear in Reels. I already had a useful collection of product and lifestyle images. Publication volume was low, and I was happy to approve everything manually.

The huge content factory in my head became a much smaller requirement:

Help me produce one good Instagram post with as little friction as possible.

Once we said it that plainly, most of the application disappeared.

The files became the application

The finished first version is a Git repository containing Markdown, YAML, images, templates, and a detailed AGENTS.md.

There is no Node.js application, database server, Docker container, scheduler, chatbot interface, Instagram API, or automated publishing.

The basic structure looks like this:

AGENTS.md
assets/
data/
docs/
drafts/
ready/
published/
templates/

The important files are:

• a product catalogue containing what Rooibos Italia actually sells
• a register of sources
• controlled factual claims and approved wording
• a ledger containing 100 possible content ideas
• a template for Instagram posts
• a working brand guide
• rules for handling and approving images

The workflow is still the same one I had wanted from the application:

idea -> verified claims -> draft -> human approval -> ready -> published

I can use natural instructions such as:

Create a Rooibos Italia post about homemade iced rooibos.

The assistant selects an idea, follows its linked claims and sources, inspects the available assets, creates the post bundle, and moves it through the lifecycle only when I approve it.

It is less deterministic than a compiled application. It depends on a capable assistant correctly following the instructions. In exchange, there is almost no application code to maintain, and I can change the process while I am still learning what it needs to be.

I originally put it in a separate repository because it is commercial and asset-heavy. Now that it consists mostly of plain files, I am not entirely convinced it needs to remain separate from my Obsidian vault. I have left it where it is for now.

One fact can support many posts

I initially remembered the idea as building a database of 100 rooibos facts.

What we built was slightly different:

sources -> controlled claims -> editorial ideas -> posts

That separation matters. One supported fact, such as rooibos being naturally caffeine-free, can lead to several posts: an evening drink, an alternative coffee break, an after-dinner cup, or an explanation of what caffeine-free means.

The system currently contains:

• 100 content ideas
• 39 controlled claims
• 13 source records
• 85 curated images

The number 100 is not magic. It was simply large enough to remove the blank page and force some variety. The links between sources, claims, ideas, and finished posts are more useful than the number itself.

The product catalogue also stops the assistant from blindly following global BOS material. Rooibos Italia currently sells the original rooibos tin and cardboard pack. We do not stock every flavoured product shown by the global brand, and we do not sell the iced-tea cans that appear in some assets.

That is ordinary business context, but the assistant needs it written down if it is going to act on my behalf.

We had to correct each other

The assistant kept warning me about health claims in existing promotional images supplied by BOS marketing. It became irritating quite quickly.

I understood what it was trying to prevent, but I did not need the same warning every time it encountered approved parent-company creative. I explained that context and changed the rules. Existing BOS promotional material can be treated as approved brand creative without repeated warnings.

That does not give the AI permission to invent new health claims, strengthen the wording, or detach a claim from its original context.

The correction also went the other way.

For a summer post, I suggested that prepared rooibos keeps well because it does not oxidise. I had heard that explanation, but I could not defend it at a scientific level.

The assistant found support for the useful part: rooibos can be prepared, refrigerated, and enjoyed later. It did not find support for the absolute oxidation claim, so we removed it.

I was fine with that. I wanted to tell people they could make the drink in advance. I did not need a questionable chemistry explanation to do it.

The relationship worked because neither side was automatically right. I had business context the assistant lacked. It checked a claim I had accepted without really verifying.

The first post found the real problems

Once the system existed, I gave it a real command:

Create a Rooibos Italia post. I'd like to lean on the make your own ice idea.

The assistant chose an existing summer photograph from the asset library. It showed two glasses of rooibos with lemon and mint, a jug, and a yellow BOS tin.

I had expected it to generate a new image, or at least use an existing image as a reference to create something different. The selected photo already looked good, so there was no reason to manufacture something new merely because AI could.

There was one problem. The photograph contained an old 50-tea-bag package, while the current Italian product contains 40 tea bags.

The assistant used the lifestyle image as the scene and a current product cutout as the reference. It replaced the old package while leaving the rest of the photograph largely intact, then prepared the result as a 1080 by 1350 pixel Instagram image.

The Italian caption explained that rooibos is not only a hot drink and suggested serving it cold with ice, lemon, and mint. I added a few emojis because the first version looked too plain for Instagram.

Walking the post all the way to publication exposed one more piece of friction. The Markdown production record separated the caption, call to action, hashtags, alt text, sources, and review notes. That was useful for managing the post, but not for publishing it.

I wanted the final physical process to be:

1. Choose the image.
2. Copy all the text.
3. Post.

We added a plain-text caption file to every ready post bundle. It contains only the final copy in publishing order.

That small improvement only became obvious when I was sitting in front of Instagram ready to use the system. Planning the entire workflow in advance probably would not have found it.

A morning to build, two minutes to publish

The complete first run took about three hours. I had the idea the previous night, spent a morning building the system with Codex, and ended with a finished Instagram post.

I should qualify that. I already had Codex, VS Code, and Git set up, and I am very familiar with this kind of workflow. This is not a promise that anyone can reproduce the system in three hours.

Once the post was ready, publishing it through Instagram on the same PC took about two minutes. The assistant had already checked that the selected image was Instagram-friendly, so it sat neatly in the finished post without any unexpected cropping.

That made the decision not to automate publishing look even more sensible. I could build a Meta integration, handle authentication and tokens, host the image somewhere accessible, and maintain the API. Or I could spend two minutes posting it myself every week or two.

For now, I will take the two minutes.

The first post went live on 8 July 2026.

What this has and has not proved

The first caption sounds more professional and more like conventional marketing than my older posts. I am fine with that for now. What matters most is that something useful is there. The Rooibos Italia voice can develop through use.

The likely weak link is imagery. Ideas are not the problem. The first post benefited from a good lifestyle image already being in the library. I do not yet know what will happen when a worthwhile idea has no matching asset and we need to create something from nothing.

Most importantly, one post is not consistency.

The system has completed its whole designed lifecycle, from an idea in the ledger to a real public post. That proves it can produce something usable. It does not prove that I will keep using it for three months, never mind a year.

I plan to revisit that honestly after three months. By then I should know whether it reduced enough friction to keep the account active, whether the images became a bottleneck, and which parts of the workflow survived contact with repeated use.

The pattern I would reuse

This is not a universal replacement for building software. It fits a low-volume system operated by one person who is already comfortable working with files, Git, and AI assistants.

Still, there is a pattern here that I expect to use again:

1. Give the assistant durable instructions rather than one enormous prompt.
2. Put domain truth into small source files.
3. Define clear draft, ready, and published states.
4. Let the assistant interview me before deciding what to build.
5. Build only enough structure to produce one real item.
6. Take that item all the way to the external action.
7. Fix the friction found at the end.

I do not see this as a prototype waiting to become a Node.js application. The files, instructions, Git history, and assistant are the system I want to maintain.

The main thing that could change that is cost. I currently have a Codex Pro account and the usage is sustainable. If pricing or token usage made this approach unreasonable, I would have to reconsider it. Supporting several social networks might also change the calculation, although that is not currently on my radar.

For now, I have one new post, a backlog of ideas, and a process that can make the next one.

That is further than the application in my head ever got.