De beste tech stack voor directory- en marketplace-websites

De meeste "beste tech stack"-artikelen zien eruit alsof iemand een middag op Product Hunt heeft rondgekeken en zijn bevindingen heeft opgeschreven. Ze vertellen je om React en misschien Postgres te gebruiken, voegen Stripe toe en noemen het een dag. Dat is niet nuttig wanneer je een directorywebsite probeert te bouwen met 137.000 vermeldingspagina's die snel moeten weergeven, geogeografische zoekopdrachten binnen een straal van 80 kilometer moeten ondersteunen, en gebruikers moeten kunnen zoeken met behulp van natuurlijke taalquery's.

Ik heb de afgelopen twee jaar precies dit soort websites gebouwd. Geen speelgoedprojecten -- productiegerichte directory- en marketplaceplatforms die honderdduizenden records verwerken, betalingsverwerking in meerdere landen (inclusief de leuke randgevallen zoals valuta's zonder decimalen), en zoeksystemen die gelijktijdig fulltext-, semantische AI- en geografische query's combineren. Dit artikel loopt door elke laag van de stack die we bij Social Animal gebruiken, waarom we elk onderdeel hebben gekozen, en de productiegegevens die deze beslissingen ondersteunen.

Inhoudsopgave

Best Tech Stack for Directory & Marketplace Websites in 2026

Waarom directory- en marketplace-websites architecturaal uniek zijn

Directory- en marketplace-websites zien er aan de oppervlakte eenvoudig uit. Vermeld wat dingen, laat mensen zoeken, misschien verwerk een betaling. Maar zodra je begint met het bouwen met echte gegevens, kom je problemen tegen waarvoor standaard SaaS-architecturen je niet voorbereiding.

Ten eerste is er het probleem van het aantal pagina's. Een directory met 100.000+ vermeldingen heeft 100.000+ pagina's nodig. Je kunt ze niet allemaal per aanvraag server-renderen, en je kunt ze niet allemaal statisch genereren op buildtijd (je builds zouden uren duren). Je hebt iets slimmers nodig -- Incremental Static Regeneration (ISR) of on-demand revalidation.

Ten tweede is zoeken multidimensionaal. Gebruikers willen zoeken op tekst ("familietherapeut"), op betekenis ("iemand die helpt met relatiespanning"), en op locatie ("binnen 32 kilometer van Amsterdam"). De meeste stacks verwerken één hiervan. Het tegelijkertijd verwerken van alle drie vereist een specifieke databasearchitectuur.

Ten derde hebben marketplaces betalingscompelexiteit die veel verder gaat dan een eenvoudige checkout. Je hebt te maken met platformcommissies, abonnementslagen, meervalutaprijzen en regelgeving verschillen tussen landen. Krijg hier iets fout en je verliest geld of breekt de wet.

Deze beperkingen hebben elk besluit in onze stack bepaald. Laten we door elke laag lopen.

Het 10-laags stack-overzicht

Voordat we diep ingaan, hier is het volledige overzicht:

Laag Tool Waarom
Frontend Next.js 15 (App Router) ISR voor 100K+ pagina's, Server Components
Database Supabase PostgreSQL pgvector + PostGIS + fulltext in één DB
Auth Supabase Auth Row-Level Security, op rollen gebaseerde toegang
Betalingen Stripe Connect Marketplace-commissies, meervaluta
Zoeken Triple pattern (tsvector + pgvector + PostGIS) Tekst + semantisch + geo gelijktijdig
Media Supabase Storage + Next.js Image Geoptimaliseerde levering, eenvoudige uploads
Hosting Vercel Edge-implementatie, ISR-ondersteuning, preview-URL's
E-mail Brevo API Transactioneel + marketing vanuit API-routes
AI Claude API Semantisch zoeken, content-verrijking, chatbots
Monitoring Vercel Analytics + PostHog Verkeer + gedragsgeving gebruiker volgen

Elke laag hier draait in productie op meerdere projecten. Laten we je laten zien hoe dat er werkelijk uitziet.

Laag 1: Frontend -- Next.js 15

We hebben directory-sites gebouwd met zowel Next.js als Astro. Beide zijn uitstekend. Maar voor directories en marketplaces in het bijzonder wint Next.js 15 met de App Router vanwege één functie: Incremental Static Regeneration.

Hier is het echte scenario. Één van onze directoryprojecten geeft 137.000 vermeldingspagina's weer. Een ander verwerkt 91.000. Je kunt al deze niet statisch genereren op buildtijd -- de build zou eeuwig duren en je zou Vercel's functie-uitvoeringslimieten overschrijden. En je kunt ze niet allemaal op elke aanvraag server-renderen omdat je serverkosten absurd zouden zijn en je Time to First Byte zou lijden.

ISR geeft je het beste van beide werelden. De eerste bezoeker aan een pagina triggert een server-render, die in de cache wordt opgeslagen aan de rand. Volgende bezoekers krijgen de statische versie. Je stelt een revalidatie-interval in (we gebruiken meestal 3600 seconden voor vermeldingspagina's), en de cache wordt op de achtergrond ververst.

// app/listings/[slug]/page.tsx
export const revalidate = 3600; // Elke uur opnieuw valideren

export async function generateStaticParams() {
  // Genereer alleen de top 1000 meest bezochte vermeldingen
  const { data } = await supabase
    .from('listings')
    .select('slug')
    .order('view_count', { ascending: false })
    .limit(1000);
  
  return data?.map((listing) => ({ slug: listing.slug })) ?? [];
}

export default async function ListingPage({ params }: { params: { slug: string } }) {
  const { data: listing } = await supabase
    .from('listings')
    .select('*, categories(*), reviews(*)')
    .eq('slug', params.slug)
    .single();
    
  // Server Component -- geen client-side JS voor dit verzonden
  return <ListingDetail listing={listing} />;
}

Server Components zijn de andere grote overwinning. Vermeldingsdetailpagina's zijn meestal statische content -- naam, beschrijving, foto's, recensies. Er is geen reden om React's runtime naar de client te sturen voor dat. Server Components worden op de server weergegeven en sturen pure HTML. Je vermeldingspagina's laden snel en je JavaScript-bundel blijft klein.

We gebruiken Client Components spaarzaam: de zoekbalk, interactieve kaarten, boeking formulieren, en alles wat gebruikersinteractie nodig heeft. Al het andere blijft op de server.

Waarom niet Astro?

Astro is fantastisch voor content-zware directories waar interactiviteit minimaal is. We hebben het gebruikt voor documentatie-sites en content-gerichte projecten. Maar marketplace-sites hebben geverifieerde statussen, real-time functies en complexe formulieren nodig. Next.js verwerkt deze natuurlijker. Als je directory meestal alleen-lezen is (denk aan: een statische bedrijfsgids), is Astro het overwegen waard -- bekijk onze Astro-ontwikkelingsmogelijkheden.

Best Tech Stack for Directory & Marketplace Websites in 2026 - architecture

Laag 2: Database -- Supabase PostgreSQL

Dit is de meest kleurrijke keuze in de stack, en degene waar ik het zelfverzekerdste over ben. Supabase geeft je PostgreSQL met al zijn extensies -- en voor directory/marketplace-sites zijn drie extensies enorm belangrijk: pgvector, PostGIS, en PostgreSQL's ingebouwde fulltext-zoeken.

In onze directoryprojecten beheren we 253.000+ records in Supabase. Dat omvat vermeldingen, gebruikersprofielen, recensies, boekingen en abonnementsgegevens. PostgreSQL verwerkt dit zonder zweet -- het is ontworpen voor datasets orders of magnitude groter.

Het echte inzicht is dit: door fulltext-zoeken, vector-inbedding en geografische gegevens in dezelfde database te houden, vermijd je de architecturale complexiteit van het synchroniseren van gegevens over meerdere services. Je hebt niet Elasticsearch nodig voor tekstzoeken. Je hebt niet Pinecone nodig voor vectorzoeken. Je hebt geen aparte geo-service nodig. Één database. Één bron van waarheid.

-- Een enkele query die tekstzoeken, vector-overeenkomst en geowijkheid combineert
SELECT 
  l.id,
  l.name,
  l.description,
  ts_rank(l.search_vector, plainto_tsquery('english', 'family therapist')) AS text_rank,
  1 - (l.embedding <=> $1::vector) AS semantic_similarity,
  ST_Distance(
    l.location::geography, 
    ST_MakePoint(-97.7431, 30.2672)::geography
  ) / 1609.34 AS distance_miles
FROM listings l
WHERE 
  l.search_vector @@ plainto_tsquery('english', 'family therapist')
  AND ST_DWithin(
    l.location::geography, 
    ST_MakePoint(-97.7431, 30.2672)::geography, 
    80467  -- 50 mijlen in meters
  )
ORDER BY 
  (text_rank * 0.3) + (semantic_similarity * 0.5) + ((1 - distance_miles/50) * 0.2) DESC
LIMIT 20;

Dat is één query. Fulltext-ranking, semantische gelijkenisscore en geografische afstandsfiltering -- allemaal gebeurd in PostgreSQL. Probeer dat over drie aparte services te doen en hou de resultaten coherent.

Voor een diepere duik in databaseopties voor directories, bekijk onze headless CMS en databasevergelijking.

Supabase Row-Level Security

RLS verdient een eigen vermelding omdat het een probleem oplost dat marketplace-backends teistert: datavergaande controle op databaseniveau. In plaats van autorisatiechecks in elk API-eindpunt te schrijven, definieer je beleid op de database zelf.

-- Therapeuten kunnen alleen hun eigen clientrecords zien
CREATE POLICY "therapeuten_eigen_clients" ON client_records
  FOR SELECT USING (
    auth.uid() = therapist_id
    OR auth.jwt() ->> 'role' = 'admin'
  );

Zelfs als je een fout in je API-code hebt die per ongeluk een query blootstelt, voorkomt RLS ongeautoriseerde gegevenstoegang. Voor marketplace-sites die gevoelige gebruikersgegevens verwerken, is dit niet onderhandelbaar.

Laag 3: Authenticatie -- Supabase Auth

Omdat we al in het Supabase-ecosysteem zijn voor de database, is het gebruik van Supabase Auth een natuurlijke pasvorm. Maar de echte reden dat we het voor marketplaces gebruiken is op rollen gebaseerde toegang die rechtstreeks met RLS integreert.

Één van onze marketplace-projecten voert op rollen gebaseerde auth uit over drie verschillende gebruikerstypen: beheerders, serviceleveranciers en clients. Elke rol ziet andere gegevens, heeft andere machtigingen en krijgt toegang tot andere functies. Een ander project voert een 4-laags lidmaatschapssysteem uit waarbij elke laag progressief meer functies ontgrendelt.

De implementatie slaat de rol van de gebruiker op in hun JWT-metagegevens, wat betekent dat RLS-beleid ernaar kan verwijzen zonder extra databasequery's:

// Rol toewijzen tijdens aanmelding
const { data, error } = await supabase.auth.signUp({
  email,
  password,
  options: {
    data: {
      role: 'therapist',
      tier: 'professional'
    }
  }
});

Supabase Auth ondersteunt OAuth-providers (Google, Apple, enz.), magische links en email/wachtwoord -- allemaal out-of-the-box. Voor B2C-marketplaces is sociale inlog praktisch vereist. We hebben omzettingspercentages voor aanmelden zien stijgen met 30-40% toen Google OAuth naast email/wachtwoord beschikbaar werd.

Laag 4: Betalingen -- Stripe Connect

Betalingsverwerking is waar marketplace-projecten echt ingewikkeld worden. Er is een groot verschil tussen "een betaling accepteren" en "een betaling accepteren, een platformcommissie nemen, terugbetalingen afhandelen, abonnementen over 30 landen beheren en deal met valuta's zonder decimalen."

Stripe Connect verwerkt de marketplace-betalingsstroom -- de verdeling tussen platform en serviceleverancier. Één van onze projecten verwerkt commissies op elke transactie, automatisch routerend naar het platformtarief en de snede van de provider.

Maar de abonnementskant is waar het interessant wordt. We voeren een 4-laags abonnementsysteem uit met regionale prijzen over 30+ landen. Dit betekent dat we aparte Stripe Price-objecten voor verschillende valutaregio's moeten onderhouden.

De zero-decimale valuta-bug

Dit is een verhaal dat ik deel omdat het ons (en onze client) echt geld heeft bespaard. Stripe verwerkt de meeste valuta's in hun kleinste eenheid -- dus $10,00 USD is 1000 (cents). Maar sommige valuta's zoals Japanse Yen (JPY) en Koreaanse Won (KRW) hebben geen decimale eenheden. ¥1000 is gewoon 1000, niet 100000.

Als je code blind met 100 vermenigvuldigt om naar de kleinste eenheid om te zetten, zul je Japanse gebruikers 100x het bedoeld bedrag in rekening brengen. We hebben dit bij het testen opgemerkt, maar ik heb productie-marketplaces gezien die dat niet deden.

const ZERO_DECIMAL_CURRENCIES = [
  'BIF', 'CLP', 'DJF', 'GNF', 'JPY', 'KMF', 'KRW', 
  'MGA', 'PYG', 'RWF', 'UGX', 'VND', 'VUV', 'XAF', 'XOF', 'XPF'
];

function formatAmountForStripe(amount: number, currency: string): number {
  if (ZERO_DECIMAL_CURRENCIES.includes(currency.toUpperCase())) {
    return Math.round(amount);
  }
  return Math.round(amount * 100);
}

Regionale proefperiode-uitsluitingen

Nog een valstrik: we moesten bepaalde Zuidoost-Aziatische landen uitsluiten van gratis proefperiodeasluitingen omdat fraudepercentages proefperioden economisch onhaalbaar maakten in die regio's. Stripe's API stelt je in staat dit in te stellen met klantenbelastinglocatiecontroles, maar je moet eerst weten dat het een probleem is. Dit is het soort dingen dat je alleen leert door een multi-country marketplace in productie te bedienen.

Laag 5: Zoeken -- Het triple search pattern

Dit is waarschijnlijk het meest waardevolle architectuurpatroon in dit artikel. De meeste directory-sites bieden basis-tekstzoeken. Goede voegen locatiefiltering toe. We voeren alle drie zoekopdrachttypes gelijktijdig uit en mengen de resultaten.

Fulltext-zoeken (PostgreSQL tsvector): Verwerkt exacte en ontstoken overeenkomsten. Wanneer iemand "loodgieter" zoekt, komt het ook overeen met "loodgieterswerk". Snel, goed begrepen, ingebouwd in Postgres.

Semantisch zoeken (pgvector + Claude-inbeddingen): Verwerkt op betekenis gebaseerde query's. "Iemand die me minder bezorgd kan voelen over mijn relatie" bevat niet het woord "therapeut," maar semantisch zoeken begrijpt de bedoeling. We genereren inbeddingen voor elke vermelding met behulp van Claude's API en slaan ze op als vectoren in pgvector.

Geografisch zoeken (PostGIS): Verwerkt nabijheidsquery's. "Binnen 25 kilometer van het centrum van Amsterdam" wordt een ruimtelijke query die geïndexeerd en snel is.

De menging is waar het interessant wordt. We wegen elk zoekopdracttype anders, afhankelijk van de query:

interface SearchWeights {
  textWeight: number;
  semanticWeight: number;
  geoWeight: number;
}

function calculateWeights(query: string, hasLocation: boolean): SearchWeights {
  const isNaturalLanguage = query.split(' ').length > 4;
  
  if (hasLocation && isNaturalLanguage) {
    return { textWeight: 0.2, semanticWeight: 0.5, geoWeight: 0.3 };
  } else if (hasLocation) {
    return { textWeight: 0.4, semanticWeight: 0.2, geoWeight: 0.4 };
  } else if (isNaturalLanguage) {
    return { textWeight: 0.2, semanticWeight: 0.7, geoWeight: 0.1 };
  }
  return { textWeight: 0.7, semanticWeight: 0.2, geoWeight: 0.1 };
}

Korte trefwoordquery's vertrouwen op fulltext-zoeken. Langere natuurlijke taalquery's vertrouwen op semantisch zoeken. Query's met een locatiecomponent verhogen het geogewicht. Één van onze directory-sites voert dit triple-patroon uit over 137.000+ vermeldingen, en zoekresultaten zijn merkbaar beter dan concurrenten die basis-tekstovereenkomsten gebruiken.

Laag 6: Media -- Supabase Storage + Next.js Image

Directory-sites zijn afbeeldingszwaar. Vermeldingsfoto's, profielfoto's, logo's -- het opteert op. We gebruiken Supabase Storage voor uploads en de Next.js <Image> component voor geoptimaliseerde levering.

De sleutelconfiguratie is het instellen van Supabase Storage-buckets met passend toegangsbeleid (openbaar voor vermeldingsfoto's, privé voor gebruikersdocumenten) en vervolgens het gebruik van Next.js Image-optimalisatie voor het serveren van WebP/AVIF-formaten in de juiste dimensies:

<Image
  src={`${process.env.NEXT_PUBLIC_SUPABASE_URL}/storage/v1/object/public/listings/${listing.image_path}`}
  alt={listing.name}
  width={800}
  height={600}
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
  loading="lazy"
/>

Next.js verwerkt formaatconversie, herziening en caching automatisch wanneer geïmplementeerd op Vercel. We hebben afbeeldingsnutttastreducties van 60-70% gezien in vergelijking met het direct serveren van originele uploads.

Laag 7: Hosting -- Vercel

Al onze productieverrichtingen en marketplace-sites draaien op Vercel. De reden is eenvoudig: Vercel is waar Next.js het best draait. ISR, Server Components, edge-middleware, preview-implementaties -- alles werkt zonder configuratie.

Voor directory-sites in het bijzonder doet het edge-netwerk ertoe. Een gebruiker in Tokio die een directory doorzoekt moet pagina's uit cache ophalen uit een nabijgelegen edge-knooppunt, niet van een server in Virginia. Vercel's edge-caching maakt dit automatisch voor ISR-pagina's.

Preview-implementaties zijn ook enorm voor marketplace-projecten met meerdere stakeholders. Elke pull-aanvraag krijgt zijn eigen URL. De client kan de nieuwe zoek-UI op een echte URL met echte gegevens beoordelen voordat alles naar productie gaat.

Vercel's Pro-plan van $20/maand per teamlid dekt meeste directory-projecten. Grotere sites (100K+ pagina's) kunnen het Enterprise-plan nodig hebben voor hogere ISR-limieten en toegewijde ondersteuning.

Laag 8: E-mail -- Brevo API

E-mail in marketplace-projecten valt in twee categorieën: transactioneel (boeking-bevestigingen, wachtwoordversets, betalingsontvangsten) en marketing (nieuwsbrieven, functieaankondigingen, herengagement).

We gebruiken Brevo (voorheen Sendinblue) voor beide, aangeroepen van Next.js API-routes:

// app/api/send-booking-confirmation/route.ts
import { NextResponse } from 'next/server';

export async function POST(request: Request) {
  const { to, bookingDetails } = await request.json();
  
  const response = await fetch('https://api.brevo.com/v3/smtp/email', {
    method: 'POST',
    headers: {
      'api-key': process.env.BREVO_API_KEY!,
      'content-type': 'application/json',
    },
    body: JSON.stringify({
      to: [{ email: to }],
      templateId: 12, // Boeking bevestigingssjabloon
      params: bookingDetails,
    }),
  });
  
  return NextResponse.json({ success: response.ok });
}

Brevo's gratis tier verwerkt 300 e-mails/dag, wat genoeg is voor vroege-fase-marketplaces. Hun betaalde plannen beginnen bij $9/maand voor 5.000 e-mails. Vergeleken met SendGrid of Mailgun hebben we vastgesteld dat Brevo's afleveringspercentages vergelijkbaar zijn en de prijzen voorspelbaarder voor groeiende projecten.

Laag 9: AI -- Claude API

AI is geen truuk in onze directory-stack -- het is een kerninfrastructuurcomponent die drie afzonderlijke taken verwerkt.

Semantische zoek-inbeddingen: Elke vermelding krijgt een inbedding gegenereerd door Claude die zijn betekenis vastlegt. Dit macht het semantische zoekenlaag beschreven hierboven.

Content-verrijking: Voor directories met door gebruikers ingediende vermeldingen varieert de kwaliteit enorm. We gebruiken Claude om beschrijvingen te normaliseren, gestructureerde gegevens (uren, specialiteiten, servicegebieden) uit te trekken en SEO-vriendelijke samenvattingen te genereren.

Interactieve functies: Één van onze projecten voert uit wat we een "Oracle Council" noemen -- vijf afzonderlijke AI-personen waarraadplegende gebruikers kunnen raadplegen voor verschillende soorten begeleiding. Elke persoon heeft zijn eigen systeemprompt, persoonlijkheid en deskundigheidsgebied. Het klinkt grappig, maar het stimuleert aanzienlijke betrokkenheid en is een van de populairste functies van de site.

Claude API-prijzen tot 2025-2026: Claude 3.5 Sonnet kost $3 per miljoen invoertokens en $15 per miljoen uitvoertokens. Voor inbeddingsgeneratie op een 100K-vermeldingsdirectory bedragen de eenmalige kosten ongeveer $50-80. Lopende kosten voor zoekquery's en chatbot-interacties bedragen meestal $100-300/maand afhankelijk van verkeer.

Laag 10: Monitoring -- Vercel Analytics + PostHog

Je hebt twee soorten monitoring nodig voor directory-sites: prestatiematen en analytische gebruikersgedrag.

Vercel Analytics geeft je Web Vitals (LCP, CLS, INP), real-user-monitoring en verkeersgegevens. Het is ingebouwd in het Vercel-dashboard en vereist nul configuratie. Voor directory-sites controleren we LCP nauwkeurig op vermeldingspagina's -- als het boven 2.5 seconden stijgt, weten we dat er iets mis is met onze ISR-configuratie of afbeeldingsoptimalisatie.

PostHog verwerkt productanalytica: welke zoekopdrachten retourneren nulresultaten (dus we weten welke content-gaten we kunnen vullen), welke vermeldingscategorieën krijgen de meeste weergaven, waar gebruikers afvallen in de boeking of aanmeldingsstroom. PostHog's gratis tier dekt tot 1 miljoen evenementen per maand, wat meeste vroege-fase-marketplaces verwerkt.

De combinatie geeft je zowel "is de site snel?" als "vinden gebruikers wat ze nodig hebben?" -- twee zeer verschillende maar even belangrijke vragen.

Volledig stack-vergelijkingstabel

Laag Onze keuze Alternatief Waarom we de onze hebben gekozen
Frontend Next.js 15 Astro, Remix ISR voor 100K+ pagina's
Database Supabase PostgreSQL PlanetScale, Neon pgvector + PostGIS in één DB
Auth Supabase Auth Clerk, Auth.js Inheemse RLS-integratie
Betalingen Stripe Connect Paddle, LemonSqueezy Marketplace-splitsingen, meervaluta
Zoeken Triple pattern (in-DB) Algolia, Elasticsearch Geen externe sync, lagere kosten
Media Supabase Storage Cloudinary, S3 Zelfde ecosysteem, eenvoudiger facturering
Hosting Vercel Netlify, AWS Amplify Beste Next.js ISR-ondersteuning
E-mail Brevo API SendGrid, Resend Prijs/afleveringspercentage-verhouding
AI Claude API OpenAI, Gemini Beste redenering voor inhoudsopgaven
Monitoring Vercel + PostHog Datadog, Mixpanel Gratis rijen dekken vroege groei

Wat deze stack in productie kost

Laten we werkelijke getallen bespreken voor een directory-site met ~50.000 vermeldingen en matig verkeer (50.000 maandelijkse bezoekers):

Service Plan Maandelijkse kosten
Vercel Pro $20
Supabase Pro $25
Stripe Pay-as-you-go 2.9% + 30¢ per transactie
Brevo Starter $9
Claude API Gebruiksgebaseerd ~$150
PostHog Gratis tier $0
Totale vaste kosten ~$204/maand

Dat is opmerkelijk betaalbaar voor een productie-marketplaceplatform. Het Supabase Pro-plan geeft je 8GB databasemüschte, 250GB bandbreedte en 100GB opslag -- meer dan genoeg voor een directory met 50.000 vermeldingen.

Naarmate je voorbij 100.000 vermeldingen schaalt en in hoger verkeer komt, verwacht kosten naar ruwweg $500-800/maand. Nog steeds dramatisch goedkoper dan de oude benadering van het uitvoeren van toegewijde servers, beheerde Elasticsearch-clusters en aparte vectordatabases.

Als je een directory- of marketplace-project plant en de prijzen meer gedetailleerd wilt begrijpen, bekijk onze prijspagina of neem contact op voor een projectspecifieke schatting.

Veelgestelde vragen

Wat is de beste database voor een directory-website in 2026? PostgreSQL via Supabase is onze topadvies. De combinatie van pgvector voor semantisch zoeken, PostGIS voor geografische query's en ingebouwde fulltext-zoeken betekent dat je alle drie zoekopdrachten zonder externe services kunt uitvoeren. Met 253K+ records in onze productieprojecten verwerkt het directoryschaalgegevens zonder problemen. Alternatieven zoals PlanetScale (MySQL-gebaseerd) missen PostGIS-ondersteuning, waardoor geo-zoeken aanzienlijk moeilijker wordt.

Kan Next.js 100.000+ pagina's voor een directory-site verwerken? Ja, maar je hebt ISR (Incremental Static Regeneration) nodig. Je genereert niet alle 100K pagina's op buildtijd. In plaats daarvan genereer je je meest trafficiëde pagina's (misschien de top 1.000-5.000) en laat ISR de rest on-demand genereren. We hebben dit gedaan met 137K pagina's in productie. De sleutel is het stellen van passende revalidatie-intervallen -- we gebruiken 3600 seconden (1 uur) voor vermeldingspagina's en kortere intervallen voor categorie/zoekpagina's.

Hoe werkt semantisch zoeken in een directory-website? Elke vermelding wordt omgezet in een numerieke vector (een "inbedding") die zijn betekenis vastlegt met behulp van een AI-model zoals Claude. Wanneer een gebruiker met natuurlijke taal zoekt -- "iemand die kinderen met ADHD helpt" -- wordt die query ook geconverteerd naar een vector. De database vindt vermeldingen waarvan de vectoren wiskundig dicht bij de queryvector liggen met behulp van pgvector's cosinusovereenkomstoperator. Dit werkt zelfs wanneer de vermelding niet de exacte woorden uit de zoekquery bevat.

Is Stripe Connect nodig voor een marketplace, of kan ik normale Stripe gebruiken? Als je marketplace betalingen tussen kopers en verkopers (of clients en serviceleveranciers) omvat, heb je Stripe Connect nodig. Normale Stripe stelt je alleen in staat betalingen naar je eigen account te accepteren. Connect verwerkt de splitsing -- het nemen van een platformcommissie en routering van de rest naar de serviceleverancier. Het verwerkt ook 1099-rapportage voor US-gebaseerde verkopers, wat een nalevingsvereiste is die je niet zelf wilt bouwen.

Hoeveel kost het om een directory-website helemaal opnieuw te bouwen? Met behulp van de hier geschetste stack bedragen je lopende infrastructuurkosten ongeveer $200/maand voor een middelgrote directory. Ontwikkelings-kosten variëren enorm afhankelijk van functies, maar een productie-gereedheid directory met zoeken, gebruikersaccounts en vermeldingsbeheer vergt meestal 8-16 weken om te bouwen. Een volledige marketplace met betalingen, boekingen en abonnementen voegt nog eens 4-8 weken toe. Je kunt onze directory- en marketplace-ontwikkelings-mogelijkheden verkennen voor meer specificaties.

Zou ik Algolia of Elasticsearch moeten gebruiken in plaats van in-database-zoeken? Voor de meeste directory-sites, nee. De complexiteit van het synchroniseren van gegevens tussen je primaire database en een aparte zoekservice creëert bugs, voegt vertraging toe en verhoogt kosten. Algolia berekent op basis van zoekopdrachten -- op schaal wordt dit snel duur (hun prijzen beginnen bij $1/1.000 zoekopdrachten op het Build-plan). PostgreSQL's ingebouwde zoekcapaciteiten, vooral gecombineerd met pgvector, verwerken directory-schaalzoekopdrachten goed. De uitzondering: als je typo-tolerantie en gefacetteerde filtering met sub-10ms-reactietijden nodig hebt op miljoenen records, is Algolia het overwegen waard.

Wat is het verschil tussen het bouwen van een directory versus een marketplace? Een directory vermeldt dingen en laat gebruikers ze vinden. Een marketplace voegt transacties toe -- betalingen, boekingen, commissies en vaak tweerichtings-interacties tussen providers en consumenten. De tech-stack is grotendeels hetzelfde, maar marketplaces voegen Stripe Connect toe (of gelijkwaardig), meer complexe auth-rollen en transactionale e-mailstromen. Het databaseschema wordt ook meer complex met orders-, factuur- en uitkeringsvolgingstabellen.

Kan ik AI-functies aan een bestaande directory-site toevoegen? Absoluut. De AI-laag in onze stack is additief, niet fundamenteel. Je kunt semantisch zoeken toevoegen door inbeddingen voor je bestaande vermeldingen te genereren (een eenmalige batchtaak), ze in een pgvector-kolom op te slaan en een semantisch zoek-eindpunt naast je bestaande tekstzoeken toe te voegen. Content-verrijking en chatbot-functies kunnen als onafhankelijke API-routes worden toegevoegd. Het moeilijkste deel is meestal de inbeddingsgeneratie voor een groot bestaand dataset -- budget een paar uur verwerkingstijd en $50-100 in API-kosten voor 100K vermeldingen.