naeema · company model

square world model

a system that extracts, catalogs, and generates marketing content for a large fintech company's website.

featprodbenctapriceteststatproduct-aproduct-bproduct-cproduct-dproduct-eproduct-f

gapsproducts × entity types × locales. empty cells are the point.

layer 2 · the dashboard's landing view (illustrative, not real data)

what it is

a content intelligence system for square's marketing site: extract what the site says, catalog it, generate new pages from verified content only.

what i did

designed and built layers 1–3 (extraction, canonical model, generation) and the gap dashboard; used ai as a query partner before designing.

what happened

a working prototype adopted as the review surface for the content team; layer 4 (personalization) is scoped. metrics under nda.

the dashboard · screens🔒 locked

these are under nda. if i have sent you the password, enter it here and the images appear. unlock

speci

roledesign + buildcompanyblock, inc. (square)year2026whatcontent intelligence system for a large fintech marketing sitearchitecture4-layer: extraction → canonical model → generation → adaptivebuilt by melayers 1–3stackllm pipeline · postgres · knowledge graph · data vizcase studymilk-droid.github.io/company-model-case-study/ ↗

the problem01

the marketing site had hundreds of pages across regions and locales. individual pages were well written, but there was no machine-readable model of what the site actually said: no documented rules for structure, no record of which entities appeared where, no consistent description of products across locales. without that, there was no way to author at the system level, and no way to generate a new page without starting from scratch.

the approach02

instead of writing pages one at a time, i built a system that extracts what the site already says, organizes it into reusable content entities (features, benefits, ctas, pricing, testimonials), and lets an llm compose new pages from those entities. content authoring becomes data-driven instead of ad hoc.

four layers03

extractioncrawl the site, use an llm to pull structured entities from each page. unstructured copy becomes machine-readable data.
canonical modela deduplicated entity database spanning pages and locales. one source of truth for what the company says about each product, feature, benefit.
generative contentan llm assembles page layouts from real entities in the database. new pages come from verified content, not invention.
adaptive layerruntime personalization by audience and context. planned, not built; the architecture supports it.

pipeline·

URLs
  │
  ▼
[ crawler + llm extractor ]
  │  structured entities
  ▼
┌──────────┐
│ postgres │
└────┬─────┘
     ├────────────────┐
     ▼                ▼
DASHBOARD (L2)   GENERATION (L3)
entity browser   scaffold(product,
heatmaps          audience, locale)
product dna           │
knowledge graph       ▼
              ┌──────┬────────┬───────┬─────┐
              │ hero │features│pricing│ cta │
              └──────┴────────┴───────┴─────┘

how i worked with ai04

query the data before designing anythingi sat with claude and wrote sql against the extracted entities to see real distributions before committing to any visualization. some ideas i had going in were wrong; cheaper to learn that from a query than a prototype.
ship the cli first, then the uithe extractor began as a command-line tool: paste a url, get entities back as json. once i could see the shape of the output, the dashboard layout followed from that shape.
write a plan before every sessioneach chunk of work started as a written plan: what exists, what changes, what done looks like. plans got shorter as the codebase got clearer, but writing context first never stopped being useful.

built-in feedback05

the dashboard prototype has a toggle-able annotation layer. on, open design questions appear in red next to the data they refer to ("should pricing be its own entity type or a property of a product?" sits right on the pricing section). off, the dashboard is clean. the prototype was both a working tool and the design-review surface, instead of keeping feedback in a separate document.

what the dashboard shows·

pages crawled   3,060
entities        8,412
products           18

building blocks
 feature 2,841 · benefit 1,209
 cta 890 · product 412
 pricing 318 · testimonial 167
 statistic 94

locale coverage  en-US en-GB fr-FR ja-JP
translation gaps es-ES fr-CA ja-JP en-AU

graph: 847 nodes · 312 contains
       94 co-occurs · 41 cross-page

design decisions06

structured views first, graph seconda force-directed graph looks impressive, but the question was "where do we have a gap?" heatmaps answer that faster, so they got the front page.

make gaps obviousmost heatmaps make empty cells invisible. here, empty cells have a visible dashed outline, so a gap is as readable as content.

wait for real data before demoing generationi held layer 3 until layer 2 had volume. generation on thin data sets the wrong expectations.

define the boundaries earlyswap the llm in layer 1 and layers 2–4 keep working. that only holds because the seams were drawn first and respected.

reflection07

understand the data first; the design follows from its shape. the part i'm most proud of is the separation between layers.

related, open source·

sitemapper ↗ — a personal project with the same approach: crawl a site, extract entities, build a queryable model. full source.

a note on what you're seeingnda

this work was done at block, inc. (square). the case study covers process and design thinking only; metrics, screenshots and proprietary details are omitted per nda. more available on request, under the right agreement.

← previoustrend spy next →gold set tool

naeema.

square world model