Work

Client platform · real estate + MLS data

Keys With Tammy

Build-time MLS ingestion for buyers; edge-backed tools for the business behind it.

Astro 6RESO / MLS PipelineCloudflare Workers
View live site
The prerendered homepage combines an optimized AVIF hero, property search, synced agent statistics, and featured listings.
The prerendered homepage combines an optimized AVIF hero, property search, synced agent statistics, and featured listings.
Buyers search and filter 300+ generated MLS listings by price, beds, property type, acreage, and location.
Buyers search and filter 300+ generated MLS listings by price, beds, property type, acreage, and location.
Each generated detail page includes MLS media, structured property data, nearby homes, a deferred map, disclosures, and a mortgage calculator.
Each generated detail page includes MLS media, structured property data, nearby homes, a deferred map, disclosures, and a mortgage calculator.
The private dashboard brings traffic, inquiries, listing inventory, and recent activity into one operational view.
The private dashboard brings traffic, inquiries, listing inventory, and recent activity into one operational view.
Featured-property choices persist in D1 and flow into the homepage through a deferred server component.
Featured-property choices persist in D1 and flow into the homepage through a deferred server component.
Allow-listed feature and theme settings are validated through authenticated Astro actions and persisted in D1.
Allow-listed feature and theme settings are validated through authenticated Astro actions and persisted in D1.
300+ listings Generated from RESO data
3x/day Automated sync and deploy
99 tests Across six Vitest files
$0/mo Hosting and automation at current usage

Build overview

Problem

Changing MLS inventory had to become fast, crawlable, compliant listing pages. The client also needed secure control of inquiries, featured homes, analytics, and settings.

Implementation

A scheduled RESO pipeline generates Zod-validated MDX three times daily. Public pages are prerendered; the authenticated admin runs on Workers with D1, KV, and Analytics Engine.

Result

Buyers get 300+ searchable listings with no request-time MLS calls. The client gets one operations dashboard, while hosting and automation remain $0 per month beyond the domain and MLS access.

Engineering decisions

Alternative Engineering decision Why it matters
  • AlternativeQuery the MLS API on every visitor request.
    Engineering decisionTake a scheduled RESO snapshot, generate content, and prerender the public catalog.
    Why it mattersPage delivery is independent of vendor latency, outages, and request-time rate limits.
  • AlternativePass a loose vendor response directly through templates.
    Engineering decisionNormalize RESO fields into a typed Astro collection and fail the build when required content is invalid.
    Why it mattersData problems are caught before deployment instead of leaking into hundreds of listing pages.
  • AlternativeRender the entire application dynamically because part of it needs a database.
    Engineering decisionPrerender buyer routes while keeping the admin, actions, analytics, and image endpoints on Workers.
    Why it mattersEach route uses the delivery model that fits it instead of forcing one architecture across the whole product.
  • AlternativeAdd a separate CMS or admin product beside the public site.
    Engineering decisionBuild authenticated operations into the same Astro application with typed actions and Cloudflare bindings.
    Why it mattersThe client gets one deployable system for listings, inquiries, analytics, settings, and audit history.
  • AlternativeStack paid IDX, CMS, analytics, image, and hosting services together.
    Engineering decisionBuild the ingestion, search, admin, analytics, and media paths on Astro, GitHub Actions, and Cloudflare primitives.
    Why it mattersThe platform avoids new SaaS subscriptions and operates at $0 per month at its current traffic and storage levels.

Implementation

RESO → MDX ingestion

GitHub Actions fetches active, pending, and recently sold listings three times daily, deduplicates by listing key, generates stable SEO slugs and MDX, refreshes agent statistics, then builds and deploys.

IDX rules in the content model

The Zod collection models required UPMLS listing and office fields, while reusable components render attribution, brokerage disclosures, and office contact details consistently.

Selective rendering

Listing, search, map-data, and marketing routes are prerendered. Admin pages, form actions, analytics, and image endpoints stay dynamic on Cloudflare Workers.

Production image debugging

An allow-listed proxy stabilizes third-party MLS photos, while a custom Astro image endpoint uses env.ASSETS.fetch() to avoid Cloudflare's same-zone error 1014.

Search and performance

Build-time Pagefind search, AVIF hero assets, lazy galleries, and viewport-loaded self-hosted MapLibre keep search and maps available without putting them on the critical path.

Free-tier operations by design

GitHub Actions handles synchronization and deployment; Workers, D1, KV, Analytics Engine, and cached media stay within Cloudflare's free tiers at current usage. The result avoids added IDX, CMS, analytics, and hosting subscriptions rather than hiding them behind another vendor.

The private operations layer

The public catalog is only half the system. The private side turns the same Astro deployment into a focused operations tool without exposing MLS credentials or introducing a separate CMS stack.

  • KV-backed sessions, middleware route protection, timing-safe password checks, and D1 login rate limiting.
  • Zod-validated Astro actions require an authenticated session before every database mutation.
  • Inquiry workflows include search, pagination, read state, archive, delete, bulk actions, and audit logging.
  • Featured-property selections persist in D1 and are rendered on the prerendered homepage through a server island.
  • Page views write to Analytics Engine, keeping event traffic separate from the operational D1 database.
The private operations layer