The Problem
Rob Roy and Konfusion ran their marketing the way most small venues do: manually, across every platform, separately. Every event announcement, menu update, or photo drop meant logging into the website, then Instagram, then Twitter, rewriting copy for each context and re-uploading the same assets each time. The team were not behind on skills or effort. The system just gave them no better option.
The brief was deceptively simple: "Can we just post everything from one place?" Behind that question was a deeper need. The venue staff are operators, not content managers. Any solution had to work for people who would not, and should not, have to think about code, file formats, or platform-specific formatting. The interface had to be obvious enough that a bartender two minutes before a shift could use it without hesitation.
The Process
I started by mapping the actual publishing workflow: what information was captured at the venue level (event name, photo, description), what each platform needed that differed from the others (character limits, hashtag conventions, image ratios), and where the friction was heaviest. The core bottleneck was not volume. It was context switching. Writing an Instagram caption, a tweet, and a website description for the same event requires three different registers, and doing that four or five times a week adds up.
The architecture decision that shaped everything else was to treat the CMS as the single source of record and push outward from there via API integrations, rather than building a scheduling layer on top of the existing platforms. This meant the database schema had to be clean and opinionated from the start. I used Supabase as the backend, handling the database, file storage for high-resolution images, and authentication, with Drizzle ORM managing the data layer. Drizzle's type-safe query builder made it straightforward to enforce consistent data shapes across the content types the venues actually used: events, menu updates, and general announcements.
The first version shipped as a functional MVP. The team could log in, enter content once, and push to all connected platforms. That part worked. What I noticed in early use was that the team still stalled at the writing step. They had the mechanism but not the momentum. Platform-specific copy was still being written by hand, and the mental overhead of switching registers for each channel had simply moved inside the dashboard instead of disappearing.
The Solution
The AI agent came directly out of watching that pattern. I built it into the dashboard as an optional step in the publishing flow: the team enters a core idea or a rough note, and the agent, prompted with the Rob Roy and Konfusion brand voice, suggests three versions of the copy: a short punchy update for Twitter, a caption with relevant hashtags for Instagram, and a fuller description for the website. The team reviews, edits if needed, and publishes. The agent does not replace their judgment. It removes the blank-page problem that was slowing them down.
The interface was designed around the constraint that it needed to work for someone with no content management background. Every element is labelled plainly, the publishing flow is linear with no branching, and there are no settings or configurations visible to standard users. The admin view handles platform credentials and permissions separately, so the day-to-day experience for bar staff is as contained as possible.
The Outcome
Time spent on manual content work dropped by 82% after the AI-assisted system went live. What previously consumed an afternoon of copy-pasting, tab-switching, and rewriting now takes roughly 20 minutes. More practically, the venues post more consistently now because the barrier to publishing is low enough that it fits into an operational shift rather than requiring a dedicated block of time.
The qualitative shift matters as much as the number. The team describes the system as something that removed a task they resented rather than a tool they have to maintain. Administrative work that disappears rather than improves was the outcome the brief was really asking for.
What I Learned
The most useful feature in this project was not in the original spec. The AI agent came from watching how the team used the MVP, not from planning it upfront. That sequence, ship a working version, observe real use, respond to what you see, shaped how I now think about scope on any project with non-technical end users. The people using a system every day will show you where the real friction is faster than any requirements document will. The job is to stay close enough to notice.