PROJECT / WGTAKT CHATBOT

WGTakt chatbot

The first version of WGTakt lived where the house already lived: WhatsApp. The magic was not chat. The magic was that every casual reply could become durable household state.

The first proof that WG coordination was not a calendar problem. It was a household-state problem hiding inside chat.

2026-02 -> 2026-04WhatsApp bot repo, Weiden WG story, Baileys/GPT/Postgres archive5 dated moments
Baileys WhatsApp transportGPT intent routingExpress/Postgres backenddone / later / unavailable / skip / rescue flowshousehold event memory

ACTUAL PROMPT / THREAD TRACE

I am the founder of the app WGTakt, Varun, living in a WG in Weiden since 2023...

WHY IT MATTERS

This is where the product learned its real shape: availability, rescues, reminders, done states, money, and fairness had to be owned by the backend, not by a roommate's memory.

HOW TO READ THIS

Each entry is a dated design decision: the pain point, the response, the proof source, and the visual artifact when the archive had one.

DATED JOURNEY

DATE INDEX

The calendar stopped being enough

A calendar can tell you a task exists. It cannot negotiate who is home, who is away, who forgot, and who can rescue the house before resentment builds.

The original WGTakt problem was not abstract product strategy. It came from a real Weiden WG where chores, vacations, events, and shared money kept leaking out of static tools.

That is why the first useful product question was not 'how do we make a chore app?' It was 'how do we make the house answer back?'

Reconstructed from the user-provided WGTakt story and local app archive.

The interface became a roommate reply

The most natural UI was not a screen. It was a reply: done, later, unavailable, skip, rescue.

The WhatsApp bot let Varun test the hardest behavior first. Could a house run through natural replies without becoming chaotic?

The bot needed guard rails because a casual message was now a mutation. A vague reply had to become a typed action, and typed actions had to stay fair.

Local WGTakt chatbot history and the later mobile logic both preserve this action vocabulary.

The backend became the product

The product was not the message. The product was the event log behind the message.

Once replies changed household state, WGTakt needed assignments, due windows, availability, reminders, finance records, and rescues to be durable.

That shifted the project from novelty bot to operating system. Chat was only the input layer.

Postgres-backed household state appears again in the mobile app schema and scheduler docs.

WhatsApp was right for proof and wrong for launch

The channel proved the behavior, then became the bottleneck.

Meta approval and WhatsApp platform constraints made the bot a risky primary product path for a small shared-home tool.

The insight was not thrown away. It was moved: reminders, natural actions, rescue logic, and house memory became app-native surfaces.

WGTakt mobile repo and project story show the same action system reappearing in app UI.

From reply bot to house OS

The chatbot did its job when it made the app inevitable.

The bot exposed which parts had to be fast, which parts had to be visible, and which parts had to survive a roommate being away.

That is the WGTakt pattern: prototype in the messy real channel, then rebuild the proven logic where the UX can be stronger.

The current WGTakt app screenshots show Today, House, Money, and Chat as separated surfaces.

WGTakt house chat activity receipts
01Chat became evidence, not just conversation.