How to Make an App Like Zillow Digs

Building a real estate discovery platform with visual search, saved collections, and property data at scale is a well-scoped engineering problem — once you stop treating it as a simple CRUD app.

What Made Zillow Digs Different From a Standard Property App

Zillow Digs (now folded into Zillow's main product as "Zillow Home Design") was essentially a Pinterest-style inspiration board bolted onto real property data. Users could browse interior photos, save rooms they liked, and get connected to local contractors or listings that matched that aesthetic.

The technical challenge was not the listing data. It was connecting visual content to structured real estate records at scale, without that connection feeling arbitrary.

The core features were:

• Photo-driven browsing with room-type filtering (kitchen, bathroom, living room)
• Save-to-board functionality with user accounts
• Estimated cost overlays on design features
• Local contractor and product discovery tied to saved items
• Recommendation engine surfacing similar photos

Each of these is buildable. The architecture decisions are where the complexity lives.

What Does the Tech Stack Actually Look Like?

A platform like this splits into four distinct systems that need to talk to each other without becoming a monolith.

Frontend

The browsing experience needs to feel fast. Zillow Digs was image-heavy, which means you are dealing with lazy loading, infinite scroll, and image optimisation from day one.

React with Next.js 14 (App Router) is the right call here. Server-side rendering handles SEO for indexed design pages. For the image grid itself, a masonry layout library like react-masonry-css or a custom CSS grid handles variable-height cards. WebP with responsive srcSet keeps load times acceptable — you are targeting sub-2-second LCP on mobile.

State management for saved boards is local-first. Use Zustand or React Query with optimistic updates so saves feel instant, then sync to the backend.

Backend

A Node.js (Express or Fastify) API layer works well here, but the data model needs thought. You have two distinct data types:

1. Content records — photos, room type tags, associated products, contractor links
2. User records — boards, saved items, preferences, location

These can live in PostgreSQL. The relationship between a user's board and a content item is a simple join table, but the recommendation logic on top of it is not.

For media storage, S3-compatible object storage (AWS S3 or Cloudflare R2) with a CDN in front. R2 has no egress fees, which matters when you are serving millions of images.

Search and Recommendations

This is where most teams underestimate the work.

Filtering by room type and style is straightforward. Elasticsearch or Typesense handles faceted search well. Typesense is simpler to operate at early scale and has a more predictable cost model.

The recommendation engine is harder. Zillow Digs used collaborative filtering (users who saved X also saved Y) and content-based filtering (visually similar images). For collaborative filtering, a matrix factorisation model trained on implicit feedback (saves, clicks, time-on-image) gives reasonable results. Implicit factorisation via the implicit Python library or a managed service like AWS Personalize are both viable paths.

For visual similarity, you need image embeddings. CLIP (Contrastive Language-Image Pre-training) from OpenAI generates embeddings that capture visual and semantic similarity. Store those vectors in pgvector (PostgreSQL extension) and run approximate nearest-neighbour queries. At moderate scale, pgvector is sufficient. Above roughly 10 million images, you would look at Pinecone or Weaviate.

Contractor and Product Matching

This is a geo-lookup problem. A contractor saved against a kitchen tile has a service radius. When a user pins that tile, you query contractors within a configurable radius of the user's location using PostGIS's ST_DWithin. Response time here needs to be under 300ms, so index your geometry columns properly and cache popular queries in Redis.

How Much Does It Cost to Build?

Rough benchmarks, not guarantees. These assume a team of four to five engineers over six to eight months for an MVP with real recommendation capability.

Component	Complexity	Rough Dev Time
Frontend (browsing, boards, auth)	Medium	8–10 weeks
Backend API + DB schema	Medium	6–8 weeks
Image pipeline + CDN	Low	2–3 weeks
Search and faceted filtering	Medium	4–5 weeks
Recommendation engine (basic)	High	6–8 weeks
Contractor geo-matching	Medium	3–4 weeks
Admin tooling + moderation	Low	2–3 weeks

Visual similarity search adds another four to six weeks if you want CLIP-based embeddings with a vector store rather than tag-based matching.

Running costs at 100,000 monthly active users sit around $3,000–$6,000/month on AWS or GCP, depending on image volume and recommendation query frequency. The biggest variable is inference cost if you run CLIP locally rather than through an API.

What Are the Hard Problems Most Teams Skip?

Image moderation. User-submitted or contractor-submitted photos need moderation. AWS Rekognition or Google Cloud Vision can flag explicit content automatically, but you still need a human review queue for edge cases. Build this before launch, not after.

Cold start for recommendations. A new user has no save history. You need a sensible default — most popular items by region, or a brief onboarding quiz that captures style preferences. The quiz approach works better for retention because it creates an immediate sense of personalisation.

Data freshness on contractor listings. Contractors move, change service areas, and go out of business. If your matching data is stale, user trust erodes fast. A periodic re-validation job (email confirmation or API ping if contractors have their own system) is not glamorous engineering, but it matters.

Photo attribution and rights. This is a legal problem as much as a technical one. If contractors or users upload photos, your terms of service need to be clear about licensing. If you scrape or purchase photo libraries, make sure usage rights cover your display and ML training use cases.

Should You Build In-House or Bring in a Specialist Team?

The browsing frontend and standard API are straightforward for any experienced team. The recommendation system and vector search are where specialist knowledge saves time.

If your team has not trained and deployed recommendation models before, the learning curve is six to eight weeks before you get results that are actually better than "show popular items." That is a real cost. A team that has done it before can skip most of that.

The decision is not binary. Many teams build the frontend and API internally, then bring in ML specialists for the recommendation layer. That hybrid often produces better outcomes than either extreme.

Conclusion

A platform like Zillow Digs is achievable in eight to twelve months with the right team split. The browsing and board-saving product is the easy part. Invest early in the image pipeline, vector search infrastructure, and a moderation workflow — these are the components that break under load or cause compliance problems if you defer them.

The clearest next step: define your recommendation strategy before you write your data schema. The schema you need for collaborative filtering looks different from the one you need for pure content-based matching. Getting that decision wrong early costs more to fix than any frontend refactor.

---

FAQ

What database should I use for a Zillow Digs-style platform?

PostgreSQL with the pgvector extension covers most needs: relational user and content data, geospatial queries via PostGIS, and vector similarity search for image recommendations. You would only look at a dedicated vector database like Pinecone above roughly 10 million image embeddings, where approximate nearest-neighbour query latency becomes a constraint.

How long does it take to build a real estate photo discovery app?

An MVP with browsing, user boards, and basic search takes four to five months with a team of three to four engineers. Adding a functional recommendation engine extends that to seven to nine months. Visual similarity search using image embeddings adds another four to six weeks on top.

What is the hardest technical problem in building a platform like this?

The recommendation cold-start problem is consistently underestimated. A new user with no save history gets generic results, which hurts early retention. Solving it properly requires either a short onboarding flow to capture preferences, or a strong region-based popularity signal — both of which need to be designed into the system from the start.

Do I need machine learning to build this?

No, but your recommendations will be weaker without it. A tag-based system (user saves kitchens with white cabinets, show more white cabinet kitchens) is buildable without ML and works reasonably well at early scale. Collaborative filtering and CLIP-based visual similarity produce meaningfully better results but require data infrastructure and ML engineering expertise.

How do I handle contractor data going stale?

Build a scheduled job that pings contractors at a defined interval — monthly or quarterly — to confirm their service area and active status. For contractors with their own CRM or booking system, a webhook integration keeps data current in near-real-time. Stale geo-matching data is one of the fastest ways to lose user trust in a local services product.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.