conteudo.ia

01

The problem isn't just making a post

Content creation for Instagram is not one task. It is a chain of decisions.

For service providers — therapists, lawyers, nutritionists, coaches, small studio owners — producing content consistently for Instagram means navigating a sequence that rarely feels manageable: What do I post about? What format? How do I say it in a way that reflects my brand? How do I make it look good without a designer?

Each of those questions blocks progress at a different stage. The visual is hard without design skills. The planning is hard without a clear editorial strategy. The writing is hard when there is no starting point. And the results can feel inconsistent even when someone manages to produce content regularly.

AI tools exist for parts of this process, but they tend to address each part in isolation. A text generator does not know anything about the brand. A design tool does not know what the post is trying to say. A scheduling tool does not generate ideas.

The friction I wanted to address was not the difficulty of any single step. It was the effort required to move between them — and the inconsistency that tends to appear when each step has to be started from scratch.

02

From an AI generator to a content system

The starting point was a carousel generator. The insight was that it was never just that.

The original concept was simpler: a tool that would take a topic and generate Instagram carousel slides, pre-formatted and ready to download. That would already be useful on its own.

But building it surfaced a recurring problem. The output was only as useful as the input, and the input required knowing what to say. A user who could not decide what to post that week could not use a generator effectively, regardless of how well the slides looked.

That observation led to an expansion of the scope. Planning — deciding what to post and when — had to come before production. Brand identity had to inform both. And different formats (carousels, stories) required tools that understood the structure of each.

What emerged was a product built around four tools connected through a shared brand layer: a carousel generator, an editorial calendar, a stories generator, and a brand panel that informed all three.

The shift from generator to system changed what the product needed to do. The tools would produce content. The brand panel would make that content consistent. The calendar would make it intentional.

03

Brand first

Every tool in the system reads from the same source.

The brand panel is not optional configuration. It is the foundation the rest of the product depends on.

Before using any tool, the user fills in their identity: handle or brand name, niche, target audience, the problem they solve for clients, their main service or product, and what differentiates them. These fields are not for display. They are the inputs that allow the AI to produce content that sounds like this person, speaking to their specific audience, rather than generic output that could belong to anyone.

Visual configuration follows: primary color, dark color, background color, title font, and body font. These parameters feed directly into the slide generation — the carousels and stories produced by the system reflect the palette and typography the user has defined.

Tone of voice is also configured here: informal and warm, inspirational and motivational, educational and didactic, formal and professional, or direct and objective.

The design decision to front-load this configuration is intentional. A user who spends a few minutes completing the brand panel unlocks a system that no longer asks the same questions at every step. The friction moves to the beginning, once, rather than recurring throughout every session.

Prototype: brand setup panel — identity, visual style, tone of voice, and access code fields.

04

Planning before producing

The editorial calendar exists to answer the question that blocks the generator.

Many people can produce a piece of content once they know what they want to say. The harder problem is deciding what to post this week, next week, and the week after — repeatedly, without running out of ideas, without repeating yourself, and without drifting away from what the brand is supposed to communicate.

The editorial calendar tool generates a full month of content ideas organized by funnel stage: awareness, consideration, and conversion. The output includes eighteen topics distributed across the user's chosen posting frequency, along with format suggestions for each.

The tool begins with a brainstorm step — an open moment to explore ideas before the calendar is structured. From there, the configuration step asks for niche, month, posting frequency, and handle. The final step generates the calendar itself.

The three-step flow was a deliberate choice. Moving directly from niche input to a generated calendar would produce results faster, but would also encourage users to accept whatever the AI produced without engaging with it. The brainstorm step creates a moment to contribute before the system generates. The configuration step makes the output parameters explicit.

Planning and production are separate activities in the product. A user who plans their month first has something to bring to the generator. The calendar becomes a brief; the generator executes it.

Prototype: editorial calendar — three-step flow from brainstorm through configuration to generated calendar.

05

Connecting planning and production

The value of the system is that its parts reinforce each other.

Brand identity, editorial calendar, and content generators are often treated as separate problems — brand strategy belongs to one domain, content planning to another, production to a third. Products that address only one of these tend to create new gaps elsewhere.

The central proposition of conteudo.ia is that connecting them within a single workflow produces something that none of the parts could achieve independently.

When a user runs the carousel generator, it is not starting from zero. The generator knows the brand's niche, audience, differentiator, and visual identity. When the editorial calendar generates topics, it is drawing on the same profile. The brand panel does not have to be reconfigured for each tool.

The user experience that results from this is not just more convenient. It is more coherent. The output of one tool can become the starting point for another. A calendar topic can feed the carousel generator. A story series can support the same week's educational carousel. The system produces content that speaks consistently because it is grounded in the same identity throughout.

Whether that coherence is actually what users needed — and whether the workflow felt natural rather than prescribed — remained something to validate with real users. The design was built around the hypothesis that it would. But the hypothesis was not confirmed.

06

Designing the generators

Each format has its own logic.

The carousel and stories generators share a common architecture — a form panel on the left, a live preview on the right — but the content they handle differs in structure, length, and purpose.

Carousels

A carousel generator that does not account for structure tends to produce uniform slides that feel mechanical.

The carousel tool organizes slides into named positions: cover, supporting points (up to nine), and a CTA. Each position has its own function and its own fields. The cover uses a provocative question. The content slides carry one idea each. The CTA closes the series with an action.

The live-trend feature allows users to search for current topics on Google via AI rather than starting with a blank field. This addresses one of the most common blockers in content production: the uncertainty about what is actually relevant at a given moment.

Six layout options — minimal, split, dark, gradient, editorial, and bold — offer different visual registers while staying within the user's defined palette and typography. The choice is not about replacing brand identity, but about selecting a tone within it.

AI image generation was included as an optional feature, powered by an external model. The inclusion reflects a real need: illustrative images are one of the elements that typically require design skills or a stock library, and adding an option to generate them from within the tool reduces the number of places a user needs to go.

Prototype: carousel generator — slide structure, live trend search, layout selection, and image generation option.

Stories

Stories require a different approach because the format is not primarily about arguments. It is about moments.

The stories tool organizes content into typed positions: phrase, tip, poll, CTA, and backstage. Each type carries different expectations. A poll slide needs a question and two options. A backstage slide invites informality. A phrase slide is about reduction — a single idea expressed as cleanly as possible.

The typed structure means the AI can apply the right generation logic to each slide rather than treating all of them the same way. It also gives users a clear way to vary the experience within a single series.

Background options — light, dark, pink, cream — extend the visual vocabulary without requiring the user to manage color choices directly. The brand palette sets the foundation; the backgrounds let individual slides feel distinct.

Prototype: stories generator — typed slide positions, background options, and series structure.

07

The product as a connected workflow

Four tools, one starting point, one export.

The product is designed as a hub that the user enters after completing the brand panel. From there, any of the four tools is accessible, and each one brings the same brand context into its generation logic.

The workflow the product proposes is not prescriptive. A user might open the editorial calendar first, generate a month of topics, then use those topics to feed the carousel generator one at a time. Another might start with a live trend search and work from what appears relevant that week.

What the product enforces is consistency: the brand is always present. What it does not enforce is the sequence in which the tools are used.

The output at every stage is practical and immediate: PNG exports from the carousel and stories generators, a structured calendar that can be used directly or adapted. There are no dashboards for tracking content performance, no content libraries, no scheduling integrations. The product ends at generation, not at publishing.

That boundary was a deliberate choice — not because publishing is unimportant, but because the first version of a product needs a clear edge. Extending into scheduling would have added substantial complexity without resolving the core problem: most users were not blocked by scheduling. They were blocked by not knowing what to produce.

08

Implementation and technical decisions

A standalone application, built to run without infrastructure overhead.

conteudo.ia was built as a self-contained HTML application. This was a practical choice for the prototype and early commercial versions: the product could be distributed as a single file or hosted on a static page without requiring a backend beyond the AI API calls.

AI generation is handled by external models, accessed through an API. The brand panel injects the user's configuration as context into each prompt. Slide content, editorial calendar topics, and story text are generated on request and returned to the interface for preview and export.

Access is managed through an access code. Users receive their code after purchase; the code is validated against the API before any AI call is made. This kept the distribution model simple — there was no account system to build, no login infrastructure to maintain, and no email verification flow to support for the initial version.

The live trend feature routes a query through an AI model with real-time web access, allowing the tool to surface currently relevant topics for a given niche. This was one of the more distinctive technical choices in the product: content tools typically require the user to do external research first, and bringing that step inside the tool reduces a recurring context switch.

PNG export from the canvas-rendered slides was another practical decision. The target user needed files they could post directly to Instagram, without additional editing. The export format had to be the final artifact, not an intermediate step.

09

Constraints and trade-offs

Not every limitation was a problem to solve.

The access code model was functional but fragile. It simplified the early distribution, but a more robust product would need account management, the ability to reset access, and a more reliable way to handle users who lost their codes or switched devices.

AI generation quality was uneven. The same prompt could produce strong output one session and generic output the next. The brand panel reduced this variance by providing consistent context, but could not eliminate it. The product relied on AI models whose behavior it could not fully control.

The slide rendering used a canvas-based approach that worked well for the defined layouts but was rigid when a user wanted to make adjustments. If the generated text was slightly too long for a layout, there was no easy way to tweak the result without regenerating. The output was practical but inflexible.

Font rendering in the canvas introduced subtle inconsistencies that were difficult to control across different devices and browsers. The exported PNG occasionally looked slightly different from the on-screen preview.

The single-file architecture that made distribution simple also constrained future development. Adding a proper account system, persistent storage, or collaborative features would require migrating to a different architecture. The early convenience carried a structural cost.

These were not all failures of planning. Some were acceptable trade-offs for an early commercial version. Others were limitations I recognized and did not have the capacity to address given where the project was at that point.

10

What still needs to be validated

The product worked technically. That is not the same as the product working.

The core workflow hypothesis — that connecting brand setup, planning, and generation in a single product would produce meaningfully more consistent and efficient content — was not validated with actual users.

Did users actually complete the brand panel, or did they skip it and treat the tool as a simple generator? Did the editorial calendar change how they thought about their content, or did it produce a list they ignored? Did the consistency the system promised translate into output they felt confident posting?

These questions require observing real use. The product reached a small number of paying users, but I did not conduct structured research with them. I gathered some informal feedback and made incremental adjustments, but nothing that constituted a rigorous evaluation of the core workflow.

There is also a broader assumption the product made: that the target user wanted a coherent system, not just a useful tool. Some users might benefit more from a single excellent generator than from a connected workflow that requires learning a larger product. The integration might be a feature for some people and unnecessary complexity for others.

I do not know the answer to that. It is the most important question the product never investigated properly.

11

What I would improve

The most significant missing piece is structured user research. The product was built around a clear hypothesis but never tested against it in any formal way.

Beyond that, a proper account system would replace the access code model. Users would gain the ability to save configurations, edit generated content, maintain a library of past outputs, and access the product across sessions without re-entering their brand setup.

Editable slide output was a recurring limitation. Users who wanted to adjust a single word, move a line, or change a color on a generated slide had no way to do so. A light editing layer on top of the generated output — not a full design tool, but something between generation and export — would substantially improve the experience.

The live trend feature was technically interesting but underused. Making it more central to the planning flow, or connecting it more directly to the calendar generation, could have increased its practical value.

The architecture would need to change to support any of these improvements. The standalone file model was the right choice for the early version. It would not be the right choice for a more capable product.

12

Why I decided to move on

The decision was not about the product failing. It was about where my attention should go.

conteudo.ia reached a functional state and attracted a small number of paying users. That was meaningful — it meant the core idea had real value for at least some people.

But growing it into a sustainable product would have required a significant investment of time and resources: a migration to a more robust architecture, structured user research, a more systematic approach to distribution and support, and ongoing iteration on the AI generation quality.

I was also not deeply excited about the problem space. The product addressed a real need, but it was not a need I personally felt. I was not its target user. That matters when deciding whether to keep investing in something, because the kind of continued engagement required to take a product further is easier to sustain when you have a direct stake in the problem.

NEXUS — a product I built for myself — occupies a different position. I use it. I encounter the limitations firsthand. The motivation to improve it comes from a place that does not require the same kind of discipline.

Deciding to stop actively working on conteudo.ia was not a failure. It was a recognition that continuing would have meant investing significant effort in a direction that was not the one I actually wanted to pursue.

13

What remains valuable

Building conteudo.ia taught me things I would not have learned by designing only for myself.

Designing for a clearly defined user who is not you forces different decisions. The brand panel is a good example: I would not have thought to front-load configuration so deliberately if I had been building for my own needs. The insight came from thinking about a user who needed a consistent starting point across every session, not just someone exploring a tool once.

The workflow integration — building something that connected multiple tools through a shared layer rather than producing one standalone utility — was the most significant design challenge. Getting it right (or close enough) required thinking about the product as a system, not as a collection of features.

The commercial dimension was also instructive. Distributing a product, handling access codes, receiving payments, and dealing with the practical realities of supporting real users all added constraints that pure design work does not encounter. The product was imperfect in ways that mattered to real people, and that is a different experience from identifying design problems in a prototype review.

I came out of it with a clearer picture of the gap between a functioning product and a validated one. conteudo.ia worked. Whether it worked for the right reasons, and whether its integrated approach was actually what users needed, I was never able to confirm.

That gap — between a product that functions and a product whose core proposition has been tested — is one of the most important things I took from this project.