Force5 Development
Back to builds

Fusedly

Room-based matching for movies, restaurants, and custom lists: users vote yes/no on shared options, get overlap notifications, then spin a narrowed room from matched results.

2/15/2026

  • Started February 13, 2026 with a browser prototype, then moved to hosted app + database.
  • Current focus is TMDB caching so reseeds can promote from local snapshot data.
  • Live on dev resources; interruptions and data resets are expected while workflows are still moving.
In developmentWebAstro
matchingmoviesrestaurantsrooms

Timeline

  • February 13, 2026: quick browser prototype, then moved to hosted site and database setup
  • February 13, 2026: initial TMDB import and basic room/match flow
  • February 14, 2026: security cleanup, rate-limit controls, and magic-link-only login
  • February 15, 2026: TMDB cache table + snapshot append flow to support broader pulls and faster reseeds

Problem as experienced

I wanted a practical way for groups to make decisions without long chat loops and tab-switching.

At the same time, this is one of my first serious Node-heavy projects, so early friction was not just product behavior. A lot of the effort went into writing scripts to streamline repeated tasks and keep deployments moving.

Why existing tools didn’t fit

I did not run an exhaustive market scan, but I did not find an exact match for the room flow I wanted:

  • shared candidate list
  • independent yes/no input from each person
  • immediate overlap visibility
  • fast narrowing into a second pass

There is also a practical constraint if commercialization enters the picture: external data providers and map APIs can move from hobby usage into license and cost negotiations quickly.

Iteration path

Current workflow is dev-server-first:

  • frequent deploys to dev resources
  • schema changes and reseeds as needed
  • local UI checks when useful, but still pointing at Azure SQL + email communication service

This keeps iteration fast, but it also means operations are not split cleanly between dev and production yet.

Platform and integration notes

Azure provisioning

Initial setup friction came from provisioning related resources in the same region. The pricing tier I picked first was too low, but Azure feedback did not make the tier/region limitation obvious immediately. Result: resources ended up split across multiple regions for now.

Email communication service

This was my first pass with the Azure email communication service. Setup was mostly straightforward.

The main issue was DNS validation formatting. I initially appended values incorrectly because Squarespace auto-appends the base domain, which caused validation failures until corrected.

What is in motion

Working now:

  • movie rooms with shared yes/no decision flow
  • magic-link authentication
  • custom content flow

Not working yet:

  • restaurant data is still placeholder seed content

Current TMDB work is focused on a larger cached snapshot so wipes/reseeds do not require full external repulls every time.

Constraints

  • potential commercialization would introduce API licensing constraints
  • hosting cost ceiling matters once usage grows
  • restaurant data quality and filtering depth will define next technical constraints

Current state

Fusedly is live, but still running on dev resources. Accounts or data can be removed during wipes.

If usage becomes consistent with real users, I will either split into proper production resources or stop destructive resets and preserve account history.

Next milestones

  1. Grow movie coverage with better filters and stronger swipe history so rooms can start from more tailored lists.
  2. Move restaurants from seed data to real location-based sources with cuisine, cost, traffic, and ratings filters.