What Does It Actually Take to Build an AI Marketing Platform From Scratch?

Skipper is a Gen AI marketing platform that reads a brand’s real customer reviews straight from a live product URL and turns that raw feedback into persona insight, ad briefs, and finished creative, no manual data upload required. We designed and built it from a blank repository over eight months. This isn’t the polished case study version of that build. It’s the list of things that turned out differently than the pitch deck’s assumptions, the kind of detail that’s actually useful if you’re evaluating whether to build something similar.

  MERN Stack       Python       GPT API       Claude API       GPT Image       Nano Banana (early iteration)  

01  The Research Automation Was the Hard Part, Not the AI

The pitch for a product like Skipper sounds like it’s about generation: type a URL, get an ad. 

The actual engineering weight sits upstream of that, in reliably scraping and structuring real customer reviews from arbitrary product pages that were never built to be machine-read consistently. 

Every e-commerce platform structures reviews a little differently. Every brand’s page has different markup, different pagination, and different edge cases. Getting that pipeline to work reliably across a wide range of real product URLs, not just the handful used in early demos, took more than eight months, and the AI generation layer built on top of it.

That’s a useful corrective for anyone assuming a Gen AI product is mostly a prompt-engineering problem. The prompt is often the easy 20 percent. The other 80 percent is getting clean, structured, trustworthy input into that prompt in the first place, and that part looks nothing like AI work. It looks like conventional, unglamorous data engineering.

It also means the parts of the roadmap that felt least exciting to build, error handling for malformed pages, retry logic for sites that rate-limit scraping, and fallback behavior when a review section simply isn’t there, ended up being the parts that determined whether the product worked reliably for a real customer’s product URL versus just the tidy examples used in a demo. 

Skipping that work, or under-scoping it early, is the single most common way products in this category ship something that looks impressive in a sales call and breaks on the first real-world URL a prospect tries.

02  We Switched Image Models Mid-Build, on Purpose

Skipper’s image generation started on the Nano Banana model, then moved to GPT Image as the product matured and better options became available. 

That’s worth naming because it’s the opposite of how a lot of AI product roadmaps get planned, locking a single model into the architecture early and treating a swap as a last resort. 

The Gen AI tooling landscape moves fast enough that building the image-generation layer as a replaceable component, rather than a hardcoded dependency, turned out to matter more than picking the “right” model on day one. 

There wasn’t a right model on day one. There was a good-enough model and an architecture flexible enough to upgrade it later without a rebuild.

03  Marketers Didn’t Want More Options, They Wanted Fewer Decisions

An early version of the concept leaned toward giving users more control: more sliders, more configuration, more ways to steer the output. What the actual research-to-brief-to-creative pipeline needed to prove out instead was the opposite: taking the PAMs, personas, angles, and motivators extracted from real reviews, and turning them directly into a usable creative direction without asking the user to make a dozen small decisions along the way. 

The value wasn’t in giving marketers more knobs to turn. It was in doing the research and the synthesis well enough that they didn’t have to.

This ran against the instinct that more configurability signals more product depth. In practice, every extra decision point in that pipeline was a place where a user without deep marketing research experience had to guess, and a guess in the middle of an automated pipeline undermines the entire premise of automating it. 

The stronger product decision was to make good defaults do the work and expose configuration only where a marketer’s judgment genuinely adds something a model can’t infer from the reviews alone, brand voice preferences, for instance, rather than deciding which persona matters most, a lesson that generalizes well past marketing tools into how we think about any custom software decision: fewer decisions the user has to make correctly is usually the better design, not more control.

04  Staying On-Brand Required Deterministic Engineering, Not Just Better Prompts

Getting generated creative to consistently match a brand’s actual visual identity, colors, fonts, style, isn’t a problem you fully solve by asking a model nicely. It required building a dedicated brand-detection layer that reads a brand’s guidelines directly from its product URL, structured, rules-based work sitting alongside the generative pieces, not replaced by them. The lesson generalizes past this one feature: the parts of a Gen AI product that need to be reliable every single time tend to need conventional software discipline underneath the AI layer, not instead of it.

This is where a lot of “AI-native” products quietly fall back on the same engineering practices that predate generative AI entirely, because reliability at scale has never really been solved by a better prompt. 

A model can be told a brand’s primary color is a specific hex value and still drift from it across a batch of generated images unless something deterministic is checking and correcting the output. 

Building that verification layer took real engineering time that had nothing to do with prompting, the same underlying point we’ve made about AI accelerating existing problems rather than replacing the need for good architecture, and skipping it would have meant shipping a product that looked impressive in a single demo and inconsistent across real, repeated use.

05 This Is a Full Pipeline Product, Not a Thin Wrapper

AI wrapper is a common, often dismissive way to describe products like this, implying a thin layer over an existing model API. Skipper’s actual scope, review scraping, PAMs analysis, brief and concept generation, multi-style image generation, AI-assisted editing, automated brand-guide detection, and ongoing concept recommendations, is a full pipeline product, not a thin layer over anything. 

Treating it like a simple wrapper is exactly how a build gets under-scoped from day one, and under-scoping compounds fast once real users start hitting the parts of the pipeline nobody budgeted real engineering time for.

The pressure to describe, or scope, a product like this as simple usually comes from comparing it to a weekend hackathon demo built on the same underlying APIs. Both are real, they’re just not the same thing. 

A demo proves a model can do something once, under ideal conditions, with a prompt tuned by the person presenting it. A product has to do the same thing reliably, for users who didn’t write the prompt, across inputs nobody hand-picked in advance. 

Closing that gap, not the model call itself, is most of what a build like this actually goes toward, and it’s the same gap a real technical assessment is built to measure on any platform, not just a newly built one.

What It Adds Up To

~60% — less research time per ad concept

~20% — lower cost to produce ad creative

Those numbers are the outcome. The five lessons above are the actual shape of the engagement that produced them, and none of the five were visible from the outside when the project started. 

That’s fairly typical of product builds in this category: the parts that turn out to matter most rarely match the parts that got the most attention in the original pitch, which is exactly why a retrospective like this one is more useful than a highlight reel.

If you’re evaluating a similar build, the same build-vs-buy discipline that decides whether a custom platform succeeds applies whether the product is a marketing tool or something else entirely: the real question isn’t whether AI makes this easier, it’s whether your team already understands the workflow well enough to encode it.

And once something like this is live, keeping it that way is its own discipline, not a one-time achievement. If you’re weighing a similar build for your own product, we’re happy to talk through what that looks like.

Read out the whole story here: Skipper Case Study