Studio Lab — Step 3 & Step 4a input fixes

Per-project data source, AI-picked location, and a visible template on the generate step

Master summary — the gist in 30 seconds

TL;DRTwo blind spots in the Studio build flow get fixed: the search-data source stops leaking between clients, an AI now picks the right location automatically, and the page template finally shows up where you actually build the page.

Input: what you flagged testing the deployed Studio app — the data-source switch changes every project at once, and Step 4a hides the template. Output: a plan where each project remembers its own data source, Gemini reads the scraped site and sets the right location by itself, and the template is visible + editable right on the generate step.

Why this mattersThese are exactly the kind of silent cross-client bugs that erode trust in the numbers you show a prospect — a search-volume number that's secretly using the wrong region, or a page generated from a template you can't even see, both fail quietly instead of loudly.

flowchart LR
  A["1 · Start<br/>enter URL"] --> B["2 · Scrape"]
  B --> C{"AI reads the<br/>scraped site"}
  C -->|"place-tied business"| D["picks the county"]
  C -->|"not place-tied"| E["whole Hungary"]
  D --> F["3 · Keywords + volumes<br/>(per-project data source)"]
  E --> F
  F --> G["4a · Generate<br/>(template now visible + editable)"]

1 · The data-source switch was leaking between clients

TL;DRChoosing Google Ads or DataForSEO for one project was silently changing it for every project.

Input: you flip the data-source switch while working on Client A. Output today: Client B's next run quietly uses that same switch — nobody told you. Output after the fix: each project remembers its own choice, others stay untouched.

Why it mattersIt's the same mistake as sharing one thermostat across every apartment in a building — you adjust your room, and three other tenants get a surprise draft. A prospect's numbers should never depend on what the last project you touched happened to be set to.

flowchart TD
  subgraph today["Today"]
    S1["one global switch"] --> P1["Project A"]
    S1 --> P2["Project B"]
    S1 --> P3["Project C"]
  end
  subgraph after["After the fix"]
    Q1["Project A's own switch"]
    Q2["Project B's own switch"]
    Q3["Project C's own switch"]
  end

2 · Gemini picks the location for you

TL;DRRight after scraping, an AI reads the site and decides whether search numbers should be filtered to one county or all of Hungary.

Input: the freshly scraped site content (what the business does, where it's based, who it serves). Output: either a specific county pre-filled as the location filter (for a local plumber, a regional clinic, a shop with one address) or 'whole Hungary' (for an online store, a SaaS product, a nationwide brand) — applied automatically, shown to you, and always overridable by hand.

Why it mattersSearch-volume numbers are only honest if they're measured where the business actually competes — a hairdresser in Szeged doesn't care about Budapest search volume. Today a rep has to remember to set this by hand every time; this makes the right default happen on its own, without hiding the choice from you.

flowchart LR
  A["scraped site data"] --> B{"Gemini:<br/>tied to a place?"}
  B -->|"yes"| C["picks the matching
county"]
  B -->|"no"| D["whole Hungary"]
  C --> E["shown to you +
still editable"]
  D --> E
  F["you already picked
one manually?"] -.->|"always wins"| E

3 · The page template was invisible on the build step

TL;DRThe HTML template that seeds every generated page lived on a totally separate, disconnected tab — Step 4a showed nothing about it.

Input: today, picking or editing a template means leaving the build flow entirely and finding the separate 'Building' tab. Output: Step 4a itself shows which template is active and lets you edit it inline, right where you're already working.

Why it mattersA tool you can't see feels like a tool that doesn't exist — this is exactly why the template felt 'missing' even though the backend for it was fully built. Surfacing it in the flow you actually use saves a context-switch every single build.

flowchart TD
  subgraph before["Before"]
    A1["Step 4a — Generate"] -."no link".-> B1["separate Building tab\n(template picker)"]
  end
  subgraph afterFix["After"]
    A2["Step 4a — Generate"] --> B2["template visible +
inline-editable, right here"]
  end

4 · One important guardrail

TL;DREditing the template from Step 4a saves a copy just for that project — it never rewrites the shared template everyone else uses.

Input: you tweak the template's HTML while building Client A's page. Output: only Client A's future builds use your edit; the shared library template stays exactly as it was for every other project.

Why it mattersThis is the same leak as callout 1, just for templates instead of data sources — without this guardrail, a quick edit for one client would quietly change what every other client gets next time.

flowchart LR
  T["shared template\n(Building tab)"] --> P["Project A picks it"]
  P --> E["edit inline on 4a"]
  E --> O["Project A's own copy"]
  T -."untouched".-> Others["every other project"]

5 · Build order

TL;DRSmallest, fastest win first — then the AI feature, then the template fix (can run in parallel, it's a separate card).

Input: three fixes, none blocking the others technically. Output: per-project data-source switch ships first (quick, demoable same day), then AI location detection, then Step 4a template visibility — which can actually build alongside the other two since it's a different card entirely.

Why it mattersShipping the smallest real fix first means something is already better today instead of waiting for the whole thing — momentum over a single big-bang release.

timeline
  title Build order
  Step 1 : per-project data-source switch
  Step 2 : AI location detection
  Step 3 : Step 4a template visibility (parallel)

Full technical plan (HANDOFF.md) →Copy-paste prompt for the next planning step →