Campaory: a campaign tool that refuses to invent your event details

Sumit S Chawla — Sat, 17 Oct 2026 18:33:52 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

I organise PyData Indore. Every event I run turns into the same chore: the same handful of facts, retyped for LinkedIn, Instagram, WhatsApp and X, and retyped again whenever something changes.

The mistakes are small, and they are mine. A venue post went out with the wrong location and the wrong year (2025, in 2026). I once sent people to the event info page when I meant the registration page, and had to correct it. For our Hack Day on 4 October, registration filled at 150, I raised the cap to 160, and that meant another round of posts on every platform. Afterwards I was a few days late with the recap, and while writing it I kept tripping over numbers that didn't agree: 154 registered, 94 checked in, "about 50 teams", 38 projects. Each platform got a slightly different version.

We run on zero cash, with no social media person. It's me, copying a time from one tab to another and hoping I got it right.

Campaory is the tool I wanted for the next event. It turns one event brief into a whole promotion campaign for LinkedIn, Instagram, WhatsApp and X.

You paste a link or the event text. Campaory pulls out the facts (name, date, time, venue, registration link, speakers, price, seats) and shows each one next to the sentence it came from. You confirm them. Only then does it plan the campaign (announcement, speaker intros, reminders, day-of, thank-you) and write each post in the right shape for each platform.

The rule the whole app is built around:

You confirm the facts. Code enforces them. The model only writes the copy.

Who would pay: community organisers, college clubs, meetup hosts and small event agencies that promote several events a month and can't afford a wrong date reaching a few thousand people. Everything works as a guest with no sign-up. Signing in only matters if you want to save campaigns, and saving is where a paid plan would sit (the free plan keeps one saved campaign).

I'd start at ₹499 per event, or ₹999 a month for someone running several. That is a guess I haven't tested. My own community runs on zero cash, so I'm not the buyer. The people who would pay are agencies and clubs running paid or sponsor-backed events.

Demo

Try it, no login needed: https://campaory.onrender.com, then click "Try a sample event".

Code

SamChawla / campaory

One verified event brief to a campaign for LinkedIn, Instagram, WhatsApp and X. Facts confirmed by you, enforced by code; Gemma writes the copy.

Campaory

Facts first. Then posts.

Campaory turns one verified event brief into a coordinated campaign for LinkedIn, Instagram, WhatsApp and X. You confirm the facts; code checks every date, time and link; a Gemma model writes the copy. Try it without an account. Sign in only to save.

Status: documentation pack only. No application code yet.

Start here

docs/HANDOFF.md: setup, accounts, decisions, risks
docs/IMPLEMENTATION_PLAN.md: task list with acceptance criteria
CLAUDE.md: rules for Claude Code in this repo

Documents

Document	Purpose
`docs/Campaory_Business_Requirements_Document_v1.1.docx`	Business requirements (current). `docs/Campaory_BRD_v1.0_original.docx` is the earlier version
`docs/PRD.md`	Product requirements, stories, acceptance
`docs/DESIGN.md`	Design overview and scope cut
`docs/UI_SPEC.md`, `docs/mockups/`	Visual design, tokens, mockup sources, unmocked screens
`docs/ARCHITECTURE.md`	Diagrams (Mermaid)
`docs/HLD.md`, `docs/LLD.md`	High-level and low-level design, API, schema, algorithms
`docs/adr/`	Eight architecture decision records
`docs/TEST_PLAN.md`, `docs/DEPLOYMENT.md`	Testing and Render setup
`docs/SUBMISSION.md`	DEV submission kit

Planned stack

FastAPI, React (Vite), PostgreSQL on Render…

View on GitHub

MIT licensed. FastAPI + React, one Docker service on Render. 539 backend tests, 75 frontend tests, and Playwright end-to-end runs at phone and desktop widths.

How I Built It

Model: Gemma 4 (google/gemma-4-26B-A4B-it), an open-weight model, served through Euri's OpenAI-compatible API.

Gemma does two jobs and nothing else:

Extraction: read a messy event page and return candidate facts, each with an exact quote from the source.
Writing: turn confirmed facts and a plan item into one post per platform.

Everything that can be wrong in a way that hurts is decided by plain Python, not the model:

Every extracted fact must quote its source. If the quote isn't in the page text, the fact is thrown away and marked missing. A made-up fact can't sneak in.
The plan and the dates are computed, not generated. Reminder timing, "registration closes" posts and the day-of post come from the confirmed dates.
Every generated post goes through a guard. Each URL, date, time, amount, handle and count in the text must match a confirmed fact. Here is real guard output for a post about the sample event that got the details wrong:

UNKNOWN_DATE    '25 October'
UNKNOWN_TIME    '9:30 AM'
UNKNOWN_COUNT   '50 seats'
UNKNOWN_AMOUNT  'Rs 199'
UNKNOWN_URL     'https://example.org/riverside-hackday/rsvp'

The correct version of the same post comes back with zero flags. A flagged post can't be approved until you fix it.

Platform rules are code too: X's 280 characters, Instagram's hashtag limit, WhatsApp's readable length.
Change impact: change the time after posts exist and Campaory lists exactly which posts mention it and proposes a redraft for each. Posts you've already marked published are never touched. It suggests a correction post instead. This is the feature I wanted most, because it is the 150-to-160 problem solved.

What Gemma was like to work with:

It wraps JSON in a ``json fence instead of returning it raw, so the app strips fences and repairs the output before validating it. - It invented key names (mentor_asha_verma_specialty`) until the prompt listed the allowed keys. - It was very good at the "copy an exact quote" rule. Snippets matched the source. - Latency is uneven. Extraction took 15 s on one try and over 45 s on two others. In production a call times out at 25 s and falls back to clearly labelled Demo model output instead of an error. Generating posts for two plan items across four platforms took about 22 s on the live site.

The part that wasn't the model: my first interface looked like every AI tool: mono labels, hairline tables, one highlight colour. I threw it away and redesigned it twice before it looked like a product for organisers rather than a prompt box.

Stack: Python 3.12, FastAPI, Pydantic v2, SQLAlchemy, Alembic · React 18, Vite, TypeScript, Zustand · Postgres on Render · one Docker image. Guest campaigns live only in the browser. The server never stores them.

Why Does Open Innovation Matter?

On 4 October I handed out a Best Use of Gemma 4 prize at our Hack Day. A week later I was building on Gemma 4 myself. I could do that because the model was cheap enough to use in a tool for a community with no budget.

That is why open models matter to me. It isn't a benchmark. It is whether someone like me can afford to build the thing at all.

The weights are open, so I'm not renting the core of the product. Today Gemma runs through a hosted API. A college club or agency that doesn't want event data leaving its own machines can run the same model on its own hardware without rewriting the app.
Cost decides whether this is a side hustle at all. Organisers will pay a few hundred rupees a month, not a few thousand. A small open model (26B total, about 4B active per token) keeps the cost per campaign low enough for that to work.
The design doesn't depend on the model being smart. Facts, dates and links are

DEV Community: Sumit S Chawla