CreatorZone

Inspiration

India's creator economy is exploding, but the tooling around it hasn't kept up. Talk to anyone running influencer marketing — a startup founder, a small agency, even a solo brand manager — and you hear the same story: they find creators by scrolling Instagram, screenshotting profiles into a spreadsheet, and DM'ing people cold. There's no searchable, structured way to answer a simple question like "show me mid-sized lifestyle creators in Mumbai with engaged audiences."

We also noticed that most of the internal creator databases people do build live in Notion — it's flexible, non-technical teammates can maintain it, and it's already part of everyone's workflow. But Notion isn't built for search at scale, filtering, or semantic queries. That gap — a great data-entry tool with no discovery layer on top of it — is where CreatorZone started.

We wanted to build something that respects how teams already work (Notion as the source of truth) while giving them the search experience of a real product.

What it does

CreatorZone is a creator-discovery app for Indian influencer workflows. A team maintains their creator roster in Notion; CreatorZone syncs that data into a proper database and makes it instantly searchable and filterable through a clean web UI — no more scrolling through spreadsheets or DMs to find the right creator for a campaign.

How we built it

We split the system into four pieces that could be built and tested independently:

Frontend — Next.js (App Router) with TypeScript, Tailwind, and TanStack Query, backed by Supabase Postgres on the free tier.
Backend — FastAPI with Celery for background jobs, so ingestion and sync work never blocks the request/response cycle.
Ingestion — a Notion sync module that pulls from Notion's /databases/query endpoint, respects Notion's 3 requests/sec rate limit, retries 429s with backoff, maps Notion property types onto our schema, and upserts rows by notion_page_id so re-syncs stay idempotent.
Search infrastructure — Meilisearch for fast keyword search today, with Qdrant wired into the architecture for semantic/vector search next, all orchestrated locally through Docker Compose alongside Redis for queuing.

Because this was a hackathon build on free-tier infrastructure, we treated "free-tier guardrails" as a first-class design constraint rather than an afterthought: CI runs entirely against mocked API responses (no live calls to Notion, Instagram, OpenAI, Supabase, Meilisearch, or Qdrant), the frontend never pulls the full creator dataset at once — everything goes through paginated queries — and PII (creator contact info) is encrypted or stripped before it ever reaches an indexable row.

We built it in chunks with clear scope boundaries: first a backend/ingestion/infra skeleton with CI, then the Alembic migration, Notion sync module, and PII-safe mocked test suite, while keeping the existing Supabase-backed discovery frontend intact and building the new backend underneath it.

Challenges we ran into

Rate limits meet real data. Notion's API caps out at 3 requests/second, which sounds generous until you're syncing a growing creator database. We had to build retry-with-backoff handling for 429s and make the sync idempotent (notion_page_id upserts) so a partial or repeated sync never duplicates or corrupts records.

Privacy without slowing down search. Creator profiles include contact details — exactly the kind of PII you don't want leaking into a search index or a client-side payload. We had to design the pipeline so sensitive fields are encrypted or excluded before data reaches Meilisearch or the frontend, without breaking the shape of the data the discovery UI expects.

Staying inside free-tier limits. Supabase's free Postgres tier, mocked-only CI, and local Docker infrastructure meant every architectural decision had a budget attached. We couldn't assume unlimited API calls to OpenAI for embeddings or unlimited database connections, so we scoped the semantic search (Qdrant + text-embedding-3-small) as configured-but-not-yet-invoked, rather than half-implementing it against a quota we'd blow through during the demo.

Integrating four moving parts under time pressure. Frontend, FastAPI backend, Notion ingestion, and local search infra all had to agree on the same data contract. Getting the Alembic migration, the sync module, and the existing Supabase-backed UI to actually talk to each other — instead of just working in isolation — was the real integration challenge of the weekend.

What we learned

How to design a sync pipeline around a third-party API's actual constraints (rate limits, pagination, idempotency) instead of assuming happy-path behavior.
That privacy-by-design is much easier to bolt on before your search index exists than after — retrofitting PII handling onto a live index is a much harder problem.
How to make free-tier infrastructure a deliberate design constraint that shapes architecture decisions early, rather than a limitation you discover during deployment.
The value of scoping work into explicit "implemented" vs. "not yet implemented" chunks — it kept the team honest about what was actually working versus aspirational, especially under hackathon time pressure.

What's next for CreatorZone

Wiring Meilisearch indexing to fire automatically after every Notion upsert, so search stays live without a manual re-index step.
Turning on Qdrant + OpenAI embeddings for real semantic search — finding creators by vibe and niche, not just keyword match.
Pulling in Instagram Graph API metrics so discovery can be ranked by real engagement data, not just profile metadata.
Hardening the deployment path from local Docker Compose to real production infrastructure.