An internal system for a real portfolio
Trinx Content Studio is the internal creative and growth system for Trinx products. It is not a public SaaS offer. Its job starts with a product and an objective, then connects the campaign material to publishing and outcomes. That is a different problem from generating a nice image. Each product has its own audience, visual language and claims that can be supported. A pet-care campaign should not inherit the tone or imagery of an exam-preparation app simply because both belong to the same company.
Intent and execution have different owners
The project uses a simple boundary: agents decide intent; deterministic software executes it. The architecture includes creative production, publishing, analytics and a control plane. This keeps flexible planning separate from operations that need predictable inputs and results. A campaign can propose a direction, while the renderer and publishing adapters still work with explicit asset versions. That distinction is particularly useful when a creative brief changes halfway through production: the plan can change without making the accepted output ambiguous.
Approval should identify the actual material
The latest work connects AI-assisted creative production with exact approvals and editable templates. Approval should refer to the material someone reviewed, rather than to a broad promise that the campaign will look good. That gives the operator a useful question before publication: is this still the accepted asset and copy? The system also supports manual templates, so an operator can deliberately build a campaign rather than accept whatever an automated run happens to return.
The campaign continues after export
Publishing and analytics belong in the same operational picture as creative production. An exported file is only one milestone. Provider acceptance, the public post and the resulting product activity are separate events. Trinx Content Studio includes publishing and analytics components to connect those events. I want to compare what was produced with what actually reached an audience, then with the action that mattered for the product. That is more useful than reporting only the number of generated assets.
The stack and the current boundary
The workspace combines Python and TypeScript services with PostgreSQL, Redis, Docker and media-rendering workers. Services are running on Hetzner, but the local working tree and the deployed release remain separate facts. Some operational checks still require real provider resources, physical devices, licensed rendering software or an off-host restore drill. This is an internal system under active development. The article describes its direction and implemented architecture without claiming that every production integration has been accepted.
Continue reading
The current portfolio, server-side AI architecture and my development workflow. Browse all projects or follow the newsletter.