AI Zuzi: taking a client’s social-media platform from prototype to production
An AI social-media management and content platform that I engineer for a client company through NeuralTake. Django, React and PostgreSQL, with seven third-party integrations, generation, payments and multi-factor sign-in. About 50 business users.
AI Zuzi is a client’s product. I engineer it for a client company through NeuralTake, my consultancy. The product name and its address are public; the company and its users are not named here, the repository is private, and this page describes the platform at the level of what it does rather than how its internals are arranged.
The problem
A small business that markets itself on social media does the same job many times over: write the post, resize the image, publish it to each channel, do it again tomorrow. AI Zuzi puts that in one place. A business composes a post once, optionally with generated text, images or video, schedules it, and the platform publishes it to each connected channel and reports what happened.
The engineering problem is less tidy. Every channel has its own sign-in flow, its own media rules, its own idea of what a post is and its own way of failing. On top of that sit payments, a metered generation studio, five interface languages, and the security a product needs before strangers are given accounts on it.
When I took it on it was a prototype on SQLite whose publishing path was unreliable. The job was to make it a product.
What I did
- Rebuilt publishing to Meta, so that a business can post to Facebook and Instagram in every format the platforms take: image, carousel, reel and stories. Added direct Instagram Business Login, so an Instagram account with no Facebook Page behind it can be connected as well.
- Added publishing to YouTube, TikTok, Pinterest, Threads, LinkedIn and Google Business Profile, and blog publishing to WordPress with scheduling, categories, authors, media and AI-drafted articles.
- Built Creative Studio, image and video generation priced in tokens that are bought through Stripe Checkout, with webhooks and invoices.
- Added multi-factor authentication by emailed code or authenticator app, and made sure it cannot be walked around.
- Moved media to Cloudflare R2 and the database from SQLite to PostgreSQL, as a live migration with zero data loss.
- Did the security work a production system needs: a security audit, encryption at rest for stored credentials, rate limiting, guards against server-side request forgery, log redaction, and GDPR-aligned account deletion.
- Wrote the privacy policy and data-deletion pages that Meta’s App Review asks for, and took the app through Meta’s configuration for Facebook Login and the Instagram API.
- Set up the automated tests, continuous integration and deployment, error monitoring and an audit log.
- Rebuilt the interface: a composer with a live phone preview, a schedule calendar, a media library, statistics with a printable PDF report, an assistant with a prompt library, a command palette, a system-status page and a five-language translations editor.
How it is layered
| Layer | Component | What it does |
|---|---|---|
| Interface | React, Vite, Tailwind CSSfive interface languages | Composer with a live phone preview, schedule calendar, media library, Creative Studio, assistant, statistics with a printable PDF report, a command palette and a system-status page. English, Polish, German, Dutch and Czech. |
| API | Django, Django REST FrameworkJWT authentication with roles | One REST surface for the single-page app, with rate limits on the sign-in, second-factor and generation routes. |
| Identity | Multi-factor sign-inemail one-time code or authenticator app | A second factor on every route in, enrolled by emailed code or by an authenticator app. |
| Publishing | Meta Graph API, Instagram Business LoginYouTube, TikTok, Pinterest, Threads, LinkedIn, Google Business Profile, WordPress | A post is composed once, scheduled, and published to each connected channel by that channel’s own service. Facebook and Instagram in every format the platforms take; blog publishing to WordPress. |
| Generation | Text, image and video generation APIsan assistant with a prompt library | Post text from parameters, from an image or from a link; blog drafts; image and video generation in Creative Studio, each priced in tokens. |
| Payments | Stripe Checkoutwebhooks and invoices | Token packages are bought through hosted checkout, credited once per purchase and invoiced automatically. |
| Media | Cloudflare R2 object storage | Uploads, generated media and brand assets live in object storage under public URLs that the platforms can fetch. Images are converted on the way in to the format the platforms take. |
| Data | PostgreSQLmigrated live from SQLite | A zero-data-loss live migration from SQLite to PostgreSQL, so that the scheduler and the web workers can write at the same time. |
| Security | Encryption at rest for stored credentialsrate limiting, request-forgery guards, log redaction, GDPR-aligned deletion | The security audit’s findings, applied: provider tokens and other credentials are encrypted in the database, user-supplied URLs are checked before they are fetched, and account deletion is real and scheduled. |
| Operations | GitHub Actions, automated testserror monitoring, an audit log | A push deploys only when the tests and the front-end build pass. Errors from both sides are reported. An audit log records sign-in, publishing, generation, payment and media events. |
The publishing pipeline
Publishing is the part of the product that has to work every time, and the part where most of the engineering went.
From the composer to a live post
Three parts. A post is composed once and saved with its targets. A scheduler walks each due post through registering its media, waiting for the platform and publishing. Each channel has its own service, chosen by how the account was connected.
Each channel has its own service, chosen by how the account was connected. An Instagram account reached through a Facebook Page and one connected by direct login take different routes to the same result, and the choice is made once, when the post is saved, so nothing downstream has to guess. Media is stored in object storage under a public URL, because the platforms fetch media rather than accept it, and images are converted on the way in to the format the platforms take.
Decisions that mattered
- Make it publish, then make it elegant
- The publishing path I inherited failed in ways that were slow to diagnose. I replaced it with a plain synchronous path first, so a user pressing publish got a post or an error, then repaired the scheduled path properly and moved the newer platforms onto it.
- “Not ready yet” is not “no”
- A platform that is still processing a video answers a publish call with an error that means wait. The prototype marked such posts failed. Now the scheduler waits and tries again, within a limit, and only a real refusal fails the post.
- A second way into Instagram
- Many small businesses have an Instagram account that was never linked to a Facebook Page. Direct login opened the product to users the Page-only route could not onboard.
- Migrate live, and keep the way back
- SQLite allows one writer, and scheduled posts were blocking on it. The move to PostgreSQL was rehearsed and then run live with zero data loss, with the schema widened first so that nothing could overflow during the load, and the previous database kept so the whole thing could be undone.
- A second factor that cannot be skipped
- Multi-factor sign-in is only worth having if every route in requires it. A later security pass found the framework’s stock password-only route still reachable, so it was closed.
- Write for the reviewer
- Meta will not grant publishing permissions to an app without a privacy policy and working data-deletion instructions. I wrote both as public pages, GDPR-aligned, and made deletion real: a request revokes the account’s provider tokens, stops its scheduled posts and removes the account and its media after a grace period.
Evidence that it worked
- About 50
- business usersOf the production platform. My statement, September 2026; approximate, and not a count of paying customers.
- Seven
- third-party integrationsMeta (Facebook and Instagram), YouTube, TikTok, Pinterest, Threads, LinkedIn and Google Business Profile, plus WordPress blog publishing.
- Zero
- data lost in the live migrationFrom SQLite to PostgreSQL, run on the live deployment with the previous database kept for rollback.
The platform was live at socials.aizuzi.com when checked on 15 September 2026. The figures describe reach and the care taken. They say nothing about how often a post publishes successfully, which I have not measured in a form I would publish.
Limitations and status
This is a client’s product, so there is a great deal I cannot show: no screenshots from inside the application, no code, no user data, and no names. The user figure is my own approximate statement.
Built is not the same as live. Each platform grants publishing access through its own review, and some of the newer integrations wait on that. The Meta routes are the mature ones. For the other platforms this page claims that the integrations exist and what they do, not that every one is switched on for every user.
What I learned
Most of production engineering is deciding what an error means.
“Not ready yet”, a locked database, a rejected image format and a link that leads nowhere all looked like the same thing to a user: the post failed. Each had a different cause and a different right answer. I also learned to respect the unglamorous half of a migration. The load took seconds. The work was in the fields that would overflow, the sessions that would break, and the copy kept so the whole thing could be undone.
Where to look
socials.aizuzi.com (opens in a new tab) is the live product, behind sign-in. The repository is private. The consultancy that delivers it is described in the NeuralTake case study.