Navira AI Listing-Optimization Platform

Where Navira is today

The current system is a sophisticated no-code automation (Zapier, Airtable, Asana, Claude, Google Docs): five linked Zaps, roughly 185 steps, with multi-ASIN loops and revision logic. But despite all that sophistication, it isn't yet functional enough for the team to use, so the team can't get value from it yet. Here's the bind. No-code was chosen to avoid needing a developer, but the build grew complex enough that it now needs a Zapier specialist, and Navira doesn't have one of those either. The logic (prompts, the prohibited-keyword list, character limits) is buried inside the automation steps, so staff can't see into it, adjust it, or fix it on their own. Failures are caught by hand-built branches rather than systematic retries, per-task fees scale with volume, and creative still stops at the brief: the system writes the infographic copy, then hands off to designers who build every image by hand.

Current architecture

flowchart TD
    F["Airtable intake form"] --> Z["Zapier · 5 Zaps
logic buried in steps"]
    Z --> NVR["NVR API to Snowflake"]
    Z --> DD["DataDive"]
    Z --> CL["Claude"]
    Z --> AT["Airtable data"]
    Z --> AS["Asana review"]
    AS --> GD["Google Doc deliverable"]
    GD --> DES["Asana design task →
images built by hand"]
      

The last four months weren't wasted. They're the head start

The current Zapier / Airtable build did its most important job: it produced a complete, detailed specification of exactly what Navira's listing engine needs to do. It isn't a working production system, the team can't use it today, but the logic, the prompts, and the design are all there. The new platform isn't a blank page; it's a re-implementation of a fully-mapped system, with the requirements already written.

What we found inside the build

Going through the actual automations makes the point better than we could: five linked Zaps, roughly 185 steps, with a reusable sub-routine that has its own error handling and return values, a loop that processes child ASINs, branching state machines for approval and revision, and code steps for parsing. Those are software engineering patterns, hand-built inside a no-code tool. Your team didn't misuse Zapier, they outgrew it: the system became sophisticated enough that it now needs a specialist to touch, which is exactly the interface gap this build closes.

What the prototype already gave us, and we carry forward

• The full content logic. Generation prompts, the 8-section content spec, and per-marketplace character limits (including Amazon's new 75-char title), with the correction step that keeps output in range.
• The compliance rules. The 80+-term prohibited list (6 categories) and brand blacklist, already defined and proven in production.
• The keyword pipeline. DataDive integration, ranked-keyword filtering, and the valued "Keyword Pull Only" mode.
• The workflow. The staged review and approval gates, and the multi-version (shared-output) logic for variations.
• The creative brief. The 6-infographic callout structure that now feeds the new templating pipeline.
• The data and integrations. The NVR API and Snowflake catalog, the intake fields, and the output format.

None of this has to be rediscovered. We're not writing requirements from scratch. We're rebuilding a known system the right way.

It also showed us exactly what to fix

Every weakness the prototype surfaced becomes a design requirement in the platform:

Couldn't we just keep expanding this base?

It's a fair question, and a real option, so we costed it in full as Path 2 (its own tab). In short: expanding the Zapier / Airtable base still can't give staff a real admin interface (the workflow logic stays locked in Zapier), hits a reliability and scaling ceiling, and can't be handed off as real code, which is why we recommend building instead. The full side-by-side is on the Path 2 and Costs tabs.

The recommended build: an application your team can drive

We recommend starting small and proving the creative in-house before any larger commitment. Step one is a Proof of Concept. If it passes your test, we build the full owned platform around it, with the interface your team has been missing at its center.

If the concept passes, we build the rest of the system

At the center is the piece you're missing today: one unified web app your team operates (tabbed: Intake · Admin/Config · Status), where staff run listings, edit prompts and rules, and watch status, no specialist required. Behind it, orchestration runs on owned code, catalog and state live in Navira's internal Snowflake platform, and the only outside services are the keyword engine, the AI models, and the review/output tools, each thin and swappable.

Target architecture

flowchart TD
    USER["Navira team"] --> UI
    subgraph APP["Navira-owned application"]
      UI["Unified web app, tabbed
Intake | Admin/Config | Status"]
      ORCH["Orchestration"]
      ENG["Content engine
Claude / OpenAI"]
      INT["Review intel +
competitor analysis"]
      CRE["Creative pipeline"]
      UI --> ORCH
      UI -. config .-> ENG
      UI -. brand kit .-> CRE
      ORCH --> ENG
      ORCH --> INT
      INT --> ENG
      ENG --> CRE
    end
    subgraph NAV["Navira internal data platform"]
      NVRAPI["NVR API"] --- SF[("Snowflake
catalog + state")]
    end
    DDV["DataDive · keywords"]
    ASA["Asana · review + design handoff"]
    OUT["Listing copy + creative + Google Doc"]
    NVRAPI -. catalog .-> ENG
    DDV -. keywords .-> ENG
    ENG --> ASA
    CRE --> ASA
    ASA --> OUT
      

The full path, with the gate up front

flowchart LR
    POC["Proof of Concept
creative concept"] --> GATE{"You decide:
proceed?"}
    GATE -->|yes| P0["Phase 0
own accounts +
app skeleton"]
    GATE -->|no| STOP["Stop here
only the PoC spent"]
    P0 --> P1["Phase 1
intake + admin app
+ content engine"]
    P1 --> P2["Phase 2
review intel +
competitor analysis"]
    P2 --> P3["Phase 3
creative pipeline +
localization"]
      

Because the current build isn't in active production, this is a clean build that reuses our existing platform stack, not a risky migration off a live system.

What's in each phase (preliminary)

Our current thinking on the work inside each phase. It's preliminary and firms into fixed not-to-exceed caps at detailed scoping, but it shows the build is costed from the actual work, not a round number. (Adjust the assumptions yourself on the Costs tab.)

At $100/hour, the full recommended path (Proof of Concept + Phases 0–3) totals 399–738 hours (~$40k–74k), about 2.5–4 months at ~40 focused hours/week. It starts with the Proof of Concept (15–30 hrs, $1.5k–3k, ~1 week), a gated go/no-go that credits toward the build; the Phase 0–1 foundation that follows is 184–338 hours (~$18.4k–33.8k), ~5–8 weeks.

Creative & the templating layer

This is the piece that makes owning creative work. AI image models are great at pictures and unreliable at precise text: they garble words and drift off-brand. So we never ask the AI to render text. Every infographic is split into two layers:

1. Imagery (AI): backgrounds, lifestyle scenes, product-in-context. That's what AI does well.
2. Text + brand (template): headline, bullets, logo, colors, layout, rendered programmatically with pixel precision.

flowchart LR
    B["Infographic brief
from content engine"] --> AI["AI imagery
Nano Banana Pro / GPT image"]
    BK["Brand kit
fonts / colors / logo"] --> TMPL
    AI --> TMPL["Templating layer
composites text + brand"]
    TMPL --> QA["QA check
text accuracy + compliance"]
    QA --> ASA["Asana design handoff
human approval"]
      

How the template works

A template is an HTML/CSS layout with empty slots (background, headline, bullets, logo) styled by the brand kit (fonts, colors, logo set per brand in the interface). The engine fills the slots with the exact callout text and the AI background, then a headless browser renders it to a PNG at Amazon's exact dimensions. The text is real type, not AI-drawn pixels, always spelling-perfect and on-brand. All six infographics share the brand styling, so the set is structurally consistent, not consistent by luck.

One brand kit per client

You're not styling one Navira look, you're making each client's brand shine on Amazon, so every brand you take on needs its own kit: its colors, fonts, and logo. The owned platform automates that onboarding: it scrapes the client's website and Amazon storefront, extracts the palette, fonts, and logo, drafts a brand kit, and your team confirms it in a few minutes. That kit is then reused on every image for that brand. In the Proof of Concept we build one kit by hand, for the product we choose, so you can see the on-brand output before we automate the rest.

See it before you commit: a standalone creative concept

Your team already likes what Scalable produces, so the fair question is simply whether we can match that bar in-house. The low-risk way to answer it: we build a standalone creative concept first, a real sample set (main image plus infographics) for one of your live products, on the same approach we'd automate. You see the actual quality before committing to anything else.

• If you love it, we build the full platform around a creative engine you've already approved.
• If you don't, you've risked a fraction of a single month's Scalable bill, not the full project, and Scalable stays available as a fallback.

The concept is a small standalone engagement (about 15–30 hours, $1.5k–3k) and credits toward the build if you proceed.

What the research found

The "just buy Scalable" question

Scalable is a strong creative-first SaaS, and we took the buy option seriously. It markets full listings, voice-of-customer, competitor analysis, localization, and creative, which is broad coverage. But it doesn't fit Navira's core needs: no way for staff to edit rules (only brand-voice presets), no API into Navira's catalog or workflow, no staged approval, and your data lives inside its platform.

Its creative isn't proprietary

Scalable generates images on the same commodity models available to everyone (Nano Banana Pro and GPT image), which Navira already licenses through Google, OpenAI, and Anthropic. The differentiator is the templating/brand layer, which we build once and Navira owns.

And at Navira's volume, renting is expensive

At $35 per listing for ~100 listings/month, creative runs ~$3,500/month (~$42,000/year), every year. That $35 is a list rate, not a quote, so the real number could come in lower. Even so, the same output in-house, on the same models, costs a few hundred dollars a month. At the best published rate (~$24/listing) or a 50% enterprise discount, owning still wins by a wide margin.

The alternative we weighed: Path 2

Before recommending a new build, we costed the lower-lift route in full. We call it Path 2: keep the existing Zapier / Airtable base and expand it to add the missing features. It's a legitimate option, and for some teams the right one, so here it is on the table, fairly. The catch in one line: it spends $30k–59k making the engine more capable while leaving your team just as locked out, because it still can't give them an interface.

Creative is the same on either route. Path 2 runs the same AI creative method we prove in the Proof of Concept, exactly like the owned build, so this isn't a question of creative quality. The catch is that automating that creative at scale is precisely where Zapier strains, and where the owned build is purpose-built.

How the numbers land

Like for like, since both routes run the same AI, Path 2 costs about $30k–59k to build, a bit less than the owned build (it skips the owned app and the interface). The AI itself, content, images, and keywords, costs the same on both, roughly $280–430/month. The entire monthly difference is the platform: about $285–525/month for Zapier and Airtable versus under $100 for owned infrastructure. That gap compounds, so over three years the two routes land at about the same place, roughly $50k–93k for Path 2 versus $51k–92k owned, except the owned build buys you an admin interface and automated brand onboarding, and Path 2 buys you neither. The Costs tab compares all three routes side by side, and you can flex the assumptions yourself.

Costs & investment

You commit to this one step at a time, starting small. Here's the staged path; the long-run economics (owning vs renting) are further down.

$100/hour, invoiced at milestones, not-to-exceed cap per phase. The build starts with a Proof of Concept, a gated go/no-go: if the creative concept lands you proceed, if not you stop, and the PoC credits toward the build. Timeline assumes ~40 focused hours/week (about 170 hours/month); more hours per week compress it. Phases run in sequence, so the full-path duration is the sum. Flip Best / Mid / Worst (top right) to switch this table and everything below it between scenarios.

The long-run picture: owning vs renting

Over 3–5 years, owning is dramatically cheaper than renting creative at $35/listing. Buy (renting Scalable) is the big number. Build and Path 2 land at about the same place over three years, but Path 2 runs higher month to month on Zapier and Airtable fees and never gives you the admin interface or automated brand onboarding (the Path 2 tab explains that route in full). This is a live calculator: change any assumption and the totals, chart, and tables update. Flip the Best / Mid / Worst scenario to see the costs and timelines for each case.

Showing the mid-case scenario, set by the Best / Mid / Worst control above. It drives the phased table, the one-time cost, 3-year totals, build timeline, and chart.

5-year cumulative cost. Build = own everything incl. in-house creative · Path 2 = expand Zapier/Airtable (same AI creative) · Buy = Scalable wholesale.

Monthly operating costs (edit any cell)

Exactly what goes into each option. The Scalable and Manual-creative rows are driven by the inputs above; every other cell is editable, so you can add Zapier, Airtable, a database, extra API fees, etc.

One-time build

Next steps

1. Start with a standalone creative concept. We build a real sample set for one of your products so you can see the in-house quality firsthand, before committing to anything further.
2. If the concept lands, confirm phase scope and set the Phase 0–1 not-to-exceed cap.
3. Begin Phase 0: ownership transfer and foundation mapping.

Leading with the concept means you only commit to the full build once you've seen the creative work for yourself. The risk on the first step is a fraction of a single month's Scalable bill.

What we'd need to start the concept

• A brand kit (fonts, colors, logo).
• One or two live products to build the sample set around.

For the full build that follows: access to coordinate the account/ownership transfer, and a quick confirmation from Justin on the Snowflake/NVR data integration.

Evan Foster · Evans List · hello@evanslist.tech