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 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.