CleverSocials: SaaS-platform van prototype naar productie

De herbouw volgde de volgorde die we ook bij klantprojecten aanhouden bij SaaS-ontwikkeling: eerst de datalaag en de verwerkingslaag, dan de integraties, dan het werkoppervlak.

1. SaaS-architectuur: van prototype naar productie#

De backend draait op Python met FastAPI, met PostgreSQL als primaire database en Redis voor caching en wachtrijen. Alles wat te lang duurt voor een request — batch-generatie, publicatie-jobs, analyses — loopt via Celery als achtergrondtaak.

Het datamodel staat in SQLAlchemy, schemawijzigingen gaan uitsluitend via Alembic-migraties, en inkomend en uitgaand verkeer wordt gevalideerd met Pydantic.

Dat lijstje is niet spectaculair, en dat is het punt. Het verschil tussen een prototype en een productie-SaaS zit zelden in de zichtbare functies; het zit in de vraag of je een schemawijziging kunt terugdraaien, of zwaar werk de gebruiker blokkeert, en of iemand anders dan de bouwer de codebase kan overnemen.

“

Ontwerpdoel van de herbouw: een codebase waarop jaren doorontwikkeld kan worden, met migraties, tests en achtergrondverwerking als fundament in plaats van als bijzaak. Dit is het gestelde doel van de herbouw — geen na oplevering gemeten uitkomst.

2. Brand-voice-learning: merkstem als datamodel#

Het onderscheidende onderdeel is brand-voice-learning: een merk legt niet één toon vast, maar meerdere stemprofielen — bijvoorbeeld een zakelijk profiel voor LinkedIn en een losser profiel voor Instagram.

Gegenereerde content krijgt een consistency-score ten opzichte van het gekozen profiel, zodat afwijkingen zichtbaar worden voordat er iets gepubliceerd wordt.

Daarvoor is een aparte opslaglaag nodig: Qdrant, een vector-database voor embeddings, draait naast PostgreSQL. Taalverwerking loopt via spaCy. De generatie zelf is LLM-gestuurd en verwerkt een hele batch in één ronde: 30 of meer posts, als achtergrondtaak, met de stemprofielen als kader.

3. API-integraties met LinkedIn en Meta#

Publiceren gebeurt rechtstreeks vanuit het platform naar LinkedIn, Instagram en Facebook, met per platform een eigen preview zodat je ziet wat er daadwerkelijk verschijnt. Elke koppeling heeft een eigen OAuth-autorisatiestroom en een eigen set publicatieregels; die verschillen zijn in de integratielaag geabsorbeerd in plaats van doorgegeven aan de gebruiker.

Deze koppelingen zijn geen demo: er wordt dagelijks mee gepubliceerd. Daarnaast zijn er integraties met Hootsuite, Buffer en Canva voor teams die daar al in werken.

4. De contentkalender als werkoppervlak#

De frontend is React met TypeScript (via Vite), met MUI als componentenbibliotheek, TanStack Query voor server-state, Zustand voor client-state en Recharts voor de rapportagegrafieken. Het hart is een contentkalender met maand- en weekweergave, drag-and-drop-planning, bulk-acties, gap-detectie (welke dagen zijn nog leeg) en AI-tijdsuggesties voor het inplannen.

In de repository staat daarnaast een Swift/iOS-client; die is onderdeel van de codebase en wordt niet gepresenteerd als een opgeleverde, publiek uitgebrachte app.

5. Kwaliteitsstack en uitrol#

De testlaag loopt langs beide kanten van de stack: pytest voor de Python-backend, Jest met React Testing Library voor de frontend, en Playwright voor end-to-end-tests door de echte interface heen.

Statische kwaliteit wordt afgedwongen met Black, Ruff en mypy aan de Python-kant en ESLint aan de TypeScript-kant; uitrol gebeurt via Docker Compose achter Nginx.

Dogfooding: we draaien er zelf op#

CleverTech AI publiceert de eigen sociale kanalen via CleverSocials, met een eigen integratie op de API van het platform. Dat is het strengste testregime dat je een eigen product kunt geven: elke ruwe rand is meteen je eigen probleem, en elke ontbrekende functie merk je op de dag dat je hem nodig hebt — niet uit een supportticket.