Building a growth system driven by campaigns, content, and applied intelligence.

Lately, I’ve been thinking a lot about a recurring pain point in digital projects: many individuals and small businesses produce content, run campaigns, test ideas, and use AI tools, yet everything almost always ends up scattered.

Some of it is in spreadsheets.
Some is in task management tools.
Some is in WhatsApp conversations.
Some is in loose documents.
And when the time comes to understand what actually worked, the history is already too fragmented.

Based on this observation, I began structuring a personal project that I currently call a "growth operating system."

The idea isn't simply to create yet another editorial calendar tool. The technical goal is to model a complete workflow that connects:

• campaigns;
• objectives;
• content planning;
• brief generation;
• institutional memory and knowledge;
• metrics;
• continuous learning.

The project is still a work in progress, but it has already served as a great laboratory for decisions regarding architecture, domain modeling, and the responsible use of AI in a product.

The general idea behind the system

At a high level, the way it works is simple.

The user defines a campaign, specifies an objective, and organizes content around that strategy. Each piece of content can have a format, a platform, a status, and a scheduled date.

From there, the system helps answer questions such as:

• what needs to be produced this week?
• which content items are overdue?
• which campaigns are currently underway?
• which objectives does each piece of content address?
• which ideas still need to be turned into scripts?
• which content has already been published?
• what insights emerged from the results?

The proposal is to transform a process that is typically scattered into a more traceable workflow.

Instead of treating each post, video, or script as an isolated item, the system views everything within a context: campaign, phase, objective, platform, format, and result.

Domain modeling before the interface

An important decision was to start with domain modeling, rather than the user interface. In projects like this, it’s tempting to start by designing beautiful dashboards, calendars, and cards. However, without a well-defined domain, the interface ends up being merely a visual layer atop fragile data.

That is why the project’s foundation is being organized around entities such as:

Campaign
ContentPlan
Content
ContentObjective
FlagPost
StorySequence
StoryFrame
AiBrief
KnowledgeItem
Memory

Each one represents a part of the process.

Campaign organizes the broader context.
ContentPlan represents the editorial plan.
ContentObjective defines the reason for that content's existence.
AiBrief stores a structured request for intelligent assistance.
KnowledgeItem represents reusable knowledge.
StorySequence allows for modeling composite content, such as sequences of Stories.

This modeling helps prevent everything from turning into just a generic "tasks" table.

Editorial pipeline

Another central aspect of the project is the editorial pipeline.

Content isn't born ready-made. It typically goes through stages:

idea → planned → scripted → recorded → edited → ready → published → archived

This cycle makes it possible to understand the stage of each item and identify any bottlenecks.

In practice, this enables views such as:

• content by status;
• weekly calendar;
• items ready to publish;
• pending scripts;
• recorded but unedited content;
• published content;
• campaigns lacking sufficient content.

The goal is for the system to function as an operational layer, not just a data entry tool.

AI as a product capability, not just a loose prompt

An important part of the project is using AI to support the creation of briefs, scripts, content sequences, and suggestions for platform-specific adaptations.

However, I am trying to approach AI from an architectural perspective.

Instead of simply saving free-form prompts and calling a specific model directly, the idea is to move toward a model based on intentions and contracts. For example, instead of simply thinking:

"generate an Instagram post about this campaign"

the system can structure something closer to:

intent: generate_content_brief
campaign_context: ...
objective: ...
platform: instagram_reels
format: short_video
constraints: ...
tone: ...

This approach makes it easier to:

• switch AI providers in the future;
• test workflows without always relying on actual API calls;
• audit the context used;
• separate business logic from the prompt;
• standardize inputs and outputs;
• reduce coupling between the product and the vendor.

To me, this is an increasingly important aspect of AI-powered products: AI needs to be a capability integrated into the system, not a dependency hidden within loose text strings.

Memory and knowledge

Another interesting challenge is handling reusable knowledge.

In a growth system, not everything is content. There is information that needs to be remembered:

• tone of voice;
• communication preferences;
• target audience;
• lessons learned from previous campaigns;
• messages that worked;
• messages that didn't work;
• brand constraints;
• editorial standards;
• validated hypotheses;
• discarded ideas.

That is why the project separates operational content from knowledge items.

The idea is for the system to be able to distinguish between, for example:

• a fact;
• a preference;
• a rule;
• a hypothesis;
• a lesson learned;
• an editorial guideline.

This is essential to ensure the AI ​​doesn't receive disorganized context and that future decisions are more consistent.

Metrics and continuous learning

The next step is connecting planning and results.

Publishing content is only part of the process. Real value emerges when we understand what happened afterward.

Even if metrics are initially entered manually, the structure needs to allow for analyses such as:

• which formats performed best;
• which platforms generated the most response;
• which objectives gained the most traction;
• which campaigns yielded the most insights;
• which content is worth repurposing;
• which hypotheses were reinforced or discarded.

The point here isn't to build an advanced analytics tool right from the start. It is to create a foundation where metrics and lessons learned can be linked back to the original plan.

Without this, the process becomes nothing more than continuous production—without continuous improvement.

Technical stack

At this initial stage, I am using a modern and relatively lean stack:

Next.js
React
TypeScript
Prisma
SQLite/PostgreSQL
Zod
Vitest
Tailwind
shadcn/ui

Choosing Next.js and TypeScript allows me to work on the product, interface, and backend within a single codebase. Prisma helps formalize the domain and keep the database's evolution under better control.

Vitest is primarily used to validate business rules, status transitions, contracts, and critical behaviors.

The goal isn't just to make the system work, but to maintain a codebase that is both evolvable and testable.

Key technical challenges

Some challenges have been particularly interesting:

1. Separating the product from specific use cases The system might originate from a specific pain point, but it needs to be modeled generically enough to serve other contexts.
2. Avoiding the "everything is a task" trap Campaigns, content, scripts, learning, and metrics are distinct things. Mixing them all together simplifies things at the start but hinders future evolution.
3. Handling AI with governance Using AI is simple. Integrating AI with traceability, context, fallbacks, and human review is a different story.
4. Creating a useful memory Storing information is easy. The hard part is organizing knowledge so it remains reusable rather than turning into noise.
5. Balancing scope and delivery A system like this can quickly become bloated. That’s why I’m prioritizing a functional MVP over more sophisticated features.

Next steps

The project's next steps are:

• consolidating the campaign workflow;
• improving the editorial calendar;
• better structuring smart briefs;
• creating a reusable knowledge layer;
• adding manual metrics;
• documenting technical decisions;
• publishing a demo version;
• maintaining the repository with a README, screenshots, architecture details, and tests.

More than just creating a finished tool, this project has served as a laboratory for thinking about product, architecture, and automation in an integrated way.

Conclusion

Personal projects can go beyond CRUD apps, clones, and tutorials.

When we choose a domain involving real-world problems, even a small project can demonstrate a great deal: modeling, architecture, product design, testing, applied AI, and the ability to transform messy processes into clearer systems.

That is the goal of this laboratory. To build a system that helps plan, execute, and learn from growth campaigns, while also serving as a technical showcase of well-considered decisions.

Ultimately, the most interesting technology isn't the kind that merely automates tasks.

It is the kind that best organizes the decision-making process.