How JAB Built a Social Media Posting AI Mastermind

Most small businesses do social media in bursts. You post four times in a week because someone finally had an hour, then nothing for eighteen days, then a burst of guilt posting. The algorithm reads that the way a customer reads a shop with irregular opening hours, and audiences quietly stop expecting anything.

We wanted the opposite for Jordan & Borden: a dependable rhythm that runs whether or not anybody is available, across Facebook, Instagram and YouTube. So we built one. This is the honest version of how it works, including two bugs that would have been embarrassing in public.

The mistake almost everybody makes is starting with content and hoping a schedule appears. We did it the other way round. Four fixed slots exist in the calendar first, and they exist whether or not anything is ready to fill them.

Monday is an image. Wednesday and Friday are short vertical videos, the kind that go to both Facebook and Instagram. Thursday at noon is YouTube. That is the whole calendar. It lives as a real table in a real database, and each slot is reserved by a rule plus a date, so the same slot can never be created twice no matter how many times the scheduler runs.

The important consequence: when nothing is ready, the slot does not quietly disappear. It holds, and it says why. A video schedule that silently turns into an image schedule is worse than an empty week, because nobody notices it happening.

Asking an AI to check its own work is theatre. It will tell you the piece is good, because it is the same model with the same blind spots, and you get a second opinion that is really the first opinion twice.

So the writer and the reviewer come from different companies. Claude writes the script. A GPT model reviews it against a written rubric and can refuse it. The reviewer is told to fail anything it is unsure about, because the costs are lopsided: a rejected script costs a few cents to rewrite, while an approved bad one costs a render and, if it says something untrue about a real person, something you cannot buy back.

The gate sits at the script, not at the finished video, because that is where it is cheap. Writing costs pennies. Reviewing costs pennies. Rendering a finished piece costs a couple of dollars and about an hour. A bad idea should die as text, long before anything expensive happens to it.

We ran the writer and the reviewer against each other forty times before trusting either one. The first round failed ten out of ten, and it was our fault: we had told the reviewer who our team was but never what our company actually sells, so it rejected our own real published offers as invented marketing claims. A reviewer that cannot tell a true claim from a made up one is not a reviewer, it is a veto.

Once it had the real product list, it started catching the thing that genuinely matters. AI writers embellish. They add no commitment, or no subscription, or invent a feature that sounds plausible sitting next to the real ones. Those are not in our approved offers, and the reviewer caught them every single time. That is the gate doing exactly the job it exists for.

It also taught us something we did not expect about comedy. The natural shape for a product sketch is a business owner discovering they have the problem the product solves. That shape is unusable when your cast is real people who work with you, because a scene where someone has a business that misses calls is a statement about their actual business. Some of our services simply cannot be dramatised that way, and the honest answer was to change the format rather than tune the prompt until the reviewer gave up.

This is the one worth stealing, whatever you are building.

We added a rule to the database saying the same video can only go to the same channel once. Same content, same destination, refuse the second one. It looked correct, it passed review, and it was completely inert.

The reason is a piece of database behaviour that catches experienced people out. In Postgres, a uniqueness rule treats every empty value as different from every other empty value. Two rows that are both blank are not duplicates as far as the database is concerned. Our duplicate check was keyed on a column that was allowed to be empty, and nothing was filling it in, so every post looked unique and the guard did nothing at all.

The fix was to make the column mandatory and then actually populate it, at which point the rule started biting. The general lesson is bigger than databases: a guard you have never seen refuse something is not a guard yet, it is a hypothesis. We now test protections by trying to break them on purpose.

Facebook and Instagram let you hand over a link and they fetch the video themselves. YouTube does not. You push the bytes yourself, and one of our episodes is around eighty megabytes.

Our first version used the obvious one line call, and it was quietly wrong. It sent the whole file in a single request, so a dropped connection near the end meant starting over from zero, and a lost reply meant not knowing whether the video existed at all. Worse, the comment in our own code claimed it was doing the safe thing when it was not.

The real version opens an upload session, writes down the session address before sending a single byte, then sends the file in chunks and records progress after each one. If the process dies at sixty percent, the next run picks up at sixty percent. If the final confirmation is lost, we can ask the session what happened instead of guessing, and every upload carries a private marker so we can find it on the channel even if we never saw the reply. That is the difference between a system that recovers and one that either gives up or publishes twice.

This is the part we are proudest of and it is the least glamorous.

Publishing a video is not one event, it is three. The file has to arrive. The platform has to process it into something playable. And it has to actually be visible to a human being. Most systems collapse those into a single tick, which is how you get a dashboard reporting that a video is live while nobody on earth can watch it.

So our tracker keeps them apart, and the word live is reserved for the last one. Uploading, processing, and not visible yet are all real states an operator can see, each with a plain sentence explaining it. If we send every byte and never get a confirmation, the status becomes outcome unknown and the system goes and asks the channel rather than assuming it worked.

The rule underneath: a claim of success is not evidence of success. Every done in this system has to be backed by reading the result back from the platform that would know.

All of this runs on a schedule rather than on somebody remembering. The Facebook and Instagram side has been posting on the rhythm; the YouTube lane went live most recently and is working through its first unattended weeks. The one human moment we deliberately kept is a veto.

When something is scheduled, the system sends a text saying what is going out and when, with a link to a single Stop button. Stopping a YouTube episode does not just hide it internally, it deletes it from the channel, because a cancel that leaves the video public is not a cancel.

That is a deliberate choice about where attention is worth spending. Approving four posts a week is a chore that gets skipped by week three. Being told what is about to happen, and being able to stop it in one tap, is a thirty second habit that survives a busy month. The default is that good work ships.

The dull answer is consistency. Three channels, four posts a week, no gaps when the week gets hard, and nobody sitting down on a Sunday night to catch up.

The more interesting answer is that the same shape works for any business that has to produce something regularly and cannot afford to publish rubbish. A fixed rhythm. A second opinion from a genuinely different source. A record that refuses to call anything finished until it can prove it. Those three ideas are not really about social media. They are how you get a machine to do repeated work without quietly lying to you about it.

That is the standard we hold our own systems to before we ever put one inside a client business.