Why a 1,044-business directory doesn't need a CMS: the MANYA Madrid case

The problem: becoming the local reference in a market of paid directories

The market was full of directories where whoever pays appears first, with unreliable reviews and outdated data. MANYA Madrid needed to become the local reference for finding trustworthy businesses in Madrid, with visible editorial criteria instead of unlabeled purchased positions.

Why the content lives in code, not a CMS

Each business is an Empresa object defined in TypeScript, inside one of 104 data files. There's no Sanity, no Contentful, no CMS at all: content is edited directly in code and version-controlled with git.

export interface Empresa {
  slug: string;
  nombre: string;
  sectorSlug: string;
  barrioSlug: string;
  rating: Rating;
  descripcionEditorial: string;
  rangoPrecios: "€" | "€€" | "€€€" | "€€€€";
  premium: boolean;
  asociada?: boolean;
  ultimaVerificacion: string; // fecha ISO de la última verificación
  posicion: number; // 1-10 dentro de sector x barrio
}

The posicion field is the key to the entire directory's «ranking»: a number from 1 to 10 within each sector and neighborhood combination, hand-written by me, not computed by any algorithm. The «6-phase methodology» I describe publicly (research, manual verification, review analysis, editorial assessment, ranking, monthly review) is exactly that: a process I follow, not a software pipeline. There's no scraper, cron job or scoring engine anywhere in the repository running it, and I'd rather say that plainly than let it sound more automated than it is.

How the premium plan works with no payment gateway

The directory has a free plan and a featured plan, but there's no Stripe or any payment integration in the code. The plans page itself says so: no online charge, payment is arranged by email after verifying the business.

Counting the real flags across all 1,044 records: 10 businesses have premium: true today. None have asociada: true, the cheaper plan, also meant to be arranged by email.

How I validated this architecture

I ran npm run build against the real repository and counted the generated routes instead of repeating a number from memory.

const nextConfig: NextConfig = {
  output: "export",
  images: { unoptimized: true },
};

It's by far the highest Lighthouse score I've measured across this whole series. My reading is that a text-and-structured-data directory, with no image carousel or real-time reads blocking initial render, lets static export perform at the very top of what it can deliver: nothing competes with the HTML for first paint.

SEO: notifying Google instead of waiting for it to crawl on its own

The repository's most recent commit, from the same day I'm writing this, adds a script to notify new URLs to Google's Indexing API, instead of relying only on Googlebot finding them on its own in a directory of over a thousand pages.

A system isn't more trustworthy for sounding more automated. It's more trustworthy when you say precisely which part is code and which part is editorial work.

My part in this project

MANYA Madrid is an in-house project within MANYA Digital: I designed the architecture, built the site, and run the research and editorial verification for every listed business.

What I'd do differently: published numbers that didn't match the code

Before writing this article, the project page said «67 sectors» and «over 1,050 businesses». Counting directly in the code (and confirming it with the build output), the real number is 97 sectors and 1,044 businesses. I've already corrected those figures on the project page; I'm recording them here for what they were: outdated data, not a deliberate exaggeration, but genuinely outdated all the same.

What I'd test next

I'd evaluate at what point the «data as code» approach stops being comfortable, probably once more than one person needs to edit at the same time, and I'd automate a simple alert based on the ultimaVerificacion field to flag which listings have gone longest without review before someone has to check by hand.