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 worked
Working in the hosted version:
- movie rooms with shared yes/no decision flow
- magic-link authentication
- custom content flow
Still incomplete when I stopped:
- restaurant data is still placeholder seed content
The core idea worked. The open question was never whether I could get the basic flow running. The open question was whether it was worth continuing to host and operationalize.
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 unhosted and archived.
It did what I wanted it to do. It proved the matching flow, it was fun to build, and people I know actually tried it. That is enough for this one.
Keeping it online would mean continuing to pay for hosting and related services, and I do not see a real reason anyone would pay for the product itself. Once that became clear, unhosting it was the practical call.
Final wrap-up
Fusedly worked. It was fun. People I know used it enough to show the idea made sense in practice.
That said, it would keep costing money to host, and I do not think there is a real business case behind it. I do not see a reason anyone would pay for it, so this is the end state: a finished experiment, a useful learning project, and an archived build thread rather than an active service.