AppLive2025

Playlists — Vibe Search

Playlists is a consumer app for finding restaurants, cafés, bars and parks. Its differentiator is Vibe Search: a vector-embedding search that lets someone type a feeling rather than a filter, ranked by semantic similarity and blended with location and recency. Built in React Native and Expo against a Python search service on AWS using pgvector and OpenAI embeddings.

Playlists had good design and real depth, and people were not coming back. The brief was one feature that would change how the product was understood, shippable in weeks rather than months. That feature was Vibe Search: type "boozy bar" or "quiet park to read in" and get places ranked by what the words mean, not the words themselves. It shipped three weeks from kickoff, and AI-driven searches rose about 200% in the first week.

Role: React Native developer
Timeline: Mar 2025 — Jul 2025
Team: Three to four engineers, at Inseed
Status: Live

3 weeks

Kickoff to shipped

~200%

Increase in AI searches, first week

10x

Reduction in steady-state embedding cost

The problem

The app worked. People found places, and then did not come back. That is a harder problem than a broken product, because nothing is obviously wrong to fix — the experience is fine and forgettable.

What was missing was a reason to reach for this app rather than a map or a friend. The founder was clear about the shape of the answer: one feature that changed how people thought about the product, and it had to ship in weeks.

What was built

Vibe Search. Instead of filtering by category and rating, you type the way you would describe it to someone — "cozy café", "boozy bar", "quiet park to read in", "Gen-Z brunch spot" — and results come back ranked by semantic similarity, blended with how close and how recent they are.

Underneath, place descriptions are embedded with OpenAI's text-embedding-3-small and stored in pgvector on PostgreSQL, queried by a Python service on AWS that sits beside the existing Node API rather than replacing it. A saved-collections library and personalised home recommendations followed.

What I owned

I worked on Playlists as a React Native developer at Inseed, on a team of three to four engineers — two of us on mobile, one on the Python search service and one on the API.

My work was the app: the search surface where a typed phrase becomes results, the saved-collections library, and the personalised home feed. The embedding service behind it was the Python engineer's; the caching decision below was the team's.

Key decisions

Cache on the phrase, not the result. Every vibe query costs an embedding call, and the phrases people type are not unique — a great many users search "cozy café". An application-level cache keyed on the phrase means the first person to ask pays for the embedding and everyone after them does not, which cut steady-state embedding cost by an order of magnitude.

It is worth noticing what makes that work: the cache key is the human phrase, before any personalisation. Location and recency are blended in afterwards, so two people searching the same words still get different results while sharing the expensive part.

A search service beside the API, not inside it. The vector search runs as its own Python service rather than being folded into the existing Node backend. That kept the AI work isolated enough to iterate on quickly, with no third-party lock-in beyond the embedding API itself.

What the team would do differently

Push harder on positioning. The build outpaced the go-to-market story. A feature that changes how a product is understood only does that if the way it is described changes too.

Ship a web companion. Organising and sharing collections is desktop work, and staying mobile-only left value unclaimed.