Growth Marketing Co-pilot · Technical notes

← Back to AI-native case studies

Flow & requirements

From input to output

The Miro flow maps how context and research are clarified into requirements, connected to the product workflow and converted into a concrete MVP output.

Miro flow showing input, clarification, connection and output steps
Flow and requirements map: input context, clarification, connection and output.

01 · System scope

Decision-to-publish orchestration

A technical flow that converts structured business context into one approved post, localized variants and platform-specific publishing actions.

Input contract

Business context
  • Product and audience
  • Primary market and language
  • Connected social account
  • Brand voice and constraints

Output contract

Publishable content
  • Recommended platform and format
  • Draft in the primary language
  • Approved localized variants
  • Publish action with status and error state

02 · Core flow

One controlled content pipeline

The user reviews the source-language draft once. Translation and platform adaptation happen only after approval.

Execution sequence

  1. Collect business context
  2. Recommend platform, format and language pair
  3. Generate primary-language draft
  4. Return draft for approval
  5. Translate and adapt after approval
  6. Publish and persist result

State transitions

draft → approved → localized → queued → published

Failures are persisted separately from content so a retry does not regenerate an approved draft.

03 · Architecture

Small integration surface

The MVP keeps one complete path from input to publish, with explicit boundaries between generation, translation and external APIs.

Services

  • Lovable frontend for onboarding and review
  • OpenAI API for recommendations and generation
  • DeepL API for localization
  • Supabase for users, drafts and publish jobs

External boundary

  • One social platform adapter
  • OAuth token storage and refresh
  • Webhook or polling for publish status
  • Make or Zapier only as the transport layer

04 · Content model

Content is versioned, not overwritten

Every generated or translated asset remains traceable to the approved source and its target account.

Entities

  • Workspace
  • Connected account
  • Content brief
  • Draft version
  • Locale variant
  • Publish job

Required metadata

  • Source language and target locale
  • Platform and content format
  • Approval timestamp and actor
  • External post ID and status
  • Failure code and retry count

05 · Technical constraints

Explicit MVP boundaries

The first implementation proves the orchestration loop without pretending to solve account management at scale.

Supported

  • One connected platform
  • One approved source post
  • Up to two locales
  • Manual review before publish

Deferred

  • Multi-account routing
  • Scheduling and content calendar
  • Analytics dashboard
  • Automatic brand-voice learning
  • Unreviewed autonomous publishing