build.allanninal.dev

Part 1 of 7 · Content repurposer series ~5 min read

A content repurposer on AWS for a few dollars a month

A small business writes one good thing a week and then lets it die. The blog post nobody links to twice. The hour-long webinar that had three lines worth quoting and zero that ever left the recording. The founder’s podcast answer that would have made a great short post if anyone had pulled it out. The work to make a long piece is real; the work to turn it into a week of short posts is small but nobody has time for it. This post walks through the design of a small system that reads one long piece, pulls the strongest points, and drafts short posts in your voice — and never posts a single one without you approving it first.

Key takeaways

  • Three sources for one long piece: a Drive folder, a transcript forwarding lane, and a paste-a-link lane.
  • Every short post is grounded in the original — it ships with the exact passage it came from.
  • One long piece fans out into a thread, a few short posts, and a quote-card caption, all in your voice.
  • Nothing posts on its own. You approve, edit, or skip each draft. Approved ones can drip out over the week.
  • Designed on AWS for about $3/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Source pieces" — a Google Drive folder you drop blog posts and docs into, plus a transcript forwarding lane and a paste-a-link lane that add new long pieces to repurpose. Centre, "Voice and rules" — a Drive folder with a voice doc that captures how you write and a rules doc covering which platforms to draft for and how long each one should be. Far right, "Channels" — where approved drafts go; either your post scheduler or a review channel for a person to send by hand. Each connects via an arrow to the AWS account container below. Source pieces have an outgoing arrow into AWS. Voice and rules feed in to ground every draft and keep it sounding like you. Channels receive only drafts a human has approved. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Source intake — receives a piece from each source, cleans it to plain text, and stores it for the drafter. In the middle, the Drafter — reads the piece; pulls the strongest points; writes platform-sized short posts in your voice, each tied to the passage it came from. On the right, the Review desk — shows each draft with its source passage and three buttons: approve, edit, or skip. Internal arrows flow left to right. A note at the bottom reads: every draft is traceable — the drafter never posts a line it can't tie to the source. Source pieces drive, transcript, link Voice and rules voice, platforms, lengths Channels where approved go piece in grounds approved drafts only AWS account Source intake clean, store, split into passages Drafter pulls points, writes: thread, posts, caption Review desk approve, edit, skip, shows source passage text drafts Every draft is traceable — the drafter never posts a line it can’t tie to the source.
Fig 1. Three sources outside, three pieces inside AWS. Long pieces flow in from a Drive folder, a transcript forwarding lane, and a paste-a-link lane. The Drafter pulls the strongest points and writes short posts. The Review desk shows each one for a human to approve, edit, or skip.

What you set up once (the outside)

  • Source pieces. A Google Drive folder where you drop the long thing you want to reuse — a blog post as a doc, a webinar transcript, a case study. New pieces can also enter via two other lanes covered in Part 2 — a forwarding lane (forward a recording transcript to a dedicated address and the system cleans it and queues it) and a paste-a-link lane (drop a URL to a published post and the system fetches it and strips it down to plain text). You give the system one long piece; it gives you back a week of short ones.
  • A voice-and-rules folder. Two short Google Docs in a Drive folder. The voice doc captures how you write — a few real examples of your own short posts, the words you use and the ones you don’t, whether you use emoji, how you open and close. The rules doc covers which platforms to draft for and how long each one should be: a thread of five-to-eight short posts, three standalone short posts, and one quote-card caption, for example. Change a rule in the doc and the next piece drafts to the new shape — no deploy.
  • Channels. Where an approved draft goes. The simplest setup sends approved drafts to a review channel where a person copies them out to each platform by hand. A fuller setup hands approved drafts to a post scheduler that drips them out over the week. Either way, only drafts a human approved ever reach a channel.

What runs when you give it a piece (the inside)

  • The source intake. Three sources feed one store. A piece arrives, the intake cleans it to plain text (strips the page furniture from a fetched URL, drops the timestamps and speaker labels from a transcript), writes it to S3, and splits it into passages — small chunks of a few sentences each — so the drafter can point at the exact part a draft came from. The Drive folder stays the place you control the source.
  • The drafter. The work happens here. First it pulls the strongest points: it reads the passages and picks the handful actually worth posting (a sharp claim, a surprising number, a clean before-and-after). Each chosen point carries the passage it came from. Then, for each point, it writes platform-sized drafts in your voice — the thread, the short posts, the caption — using the voice doc as a guide. Before any draft leaves the drafter, it’s checked against the source: if a sentence can’t be traced back to a passage, it’s dropped. Bedrock does the reading and the writing; the grounding check keeps it honest.
  • The review desk. Every draft lands here, never on a channel. Each one shows the draft, the platform it’s for, and the source passage it came from, with three buttons: approve, edit, skip. Approve sends it on (to the scheduler or the review channel). Edit opens a box pre-filled with the draft. Skip drops it. Every choice is logged, so next month you can see what got used and what got cut.

In plain words

You publish a 1,800-word blog post on Monday about why your shop switched suppliers. By Monday afternoon the system has read it and drafted a week of short posts: a six-part thread that walks through the switch, three standalone posts (one with the cost number, one with the quality comparison, one with the customer reaction), and a quote-card caption pulling your sharpest line. Each draft sits on the review desk next to the exact sentence from the post it came from. You read through them over coffee — approve four, edit one to sharpen the hook, skip one that feels thin. The four approved ones drip out across the week. Nothing went out that you didn’t see, and the post you spent two hours writing did a week of work instead of one day’s.

The cost of running this is about $3 a month at SMB volume. The cost of not running it is every long piece that did one day of work and then sat in an archive nobody opens.

Design rules that shaped every decision

  • Every draft is grounded — it ships with the source passage it came from. No passage, no draft.
  • Nothing posts on its own. Approve, edit, or skip. There is no fourth move.
  • One long piece, one batch of drafts. The system runs when you feed it, not on a clock you can’t see.
  • Your voice lives in a doc. Change how it sounds without touching code.
  • Platforms and lengths live in a doc too. Add a platform without a deploy.
  • Every choice is logged. Look back next month and see what got approved, edited, or skipped.

Why this shape

Most teams repurpose content in one of three ways: they don’t, they pay a freelancer to do it by hand, or they paste the whole post into a chatbot and hope. The first leaves money on the table — the long piece was the expensive part, and the short posts are the cheap multiplier nobody collects. The freelancer works but costs more than the system and is slow on a busy week. And the paste-into-a-chatbot approach is where things go wrong: with no grounding, the model happily invents a statistic that was never in your post, and now you’ve posted something you can’t back up.

The setup above keeps the human where the human matters — deciding what’s good and what ships — and gives the machine the parts it’s reliably good at: reading a long thing, finding the quotable bits, and rewriting them to length. The grounding rule is the whole game. A short post is only allowed to say something the source said. That one constraint is the difference between a tool you trust and a tool that gets you in trouble.

The next four posts walk through each piece in turn: how a long post gets loaded, how the strongest points get pulled, how a clip gets drafted in your voice, and how a repurposed draft gets approved. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts