Less searching. Less messaging. Just get it sorted.
I have a problem with how much work it takes to get simple things done.
Need a birthday cake? Find businesses, check whether they can make exactly what you want, message several of them, explain yourself repeatedly, wait, compare replies and somehow remember who said what.
And that's for a cake.
Fyn is my attempt to remove that admin: tell it what you need, let it find suitable options, contact providers and bring the useful answers back.
At a glance
The problem
Finding small businesses isn't really the problem anymore. Instagram, Google and directories are full of them.
The work starts after you find them.
Availability isn't clear. Services aren't standardised. Pricing often needs a conversation. Your request might be completely normal but not something that fits neatly into an 'add to cart' flow.
The opportunity wasn't another directory. It was reducing the coordination.
The first idea wasn't the final product
Fyn has changed as I've built it, which is exactly what I wanted.
Instead of protecting the first concept, I've treated the live product as a way to test where people actually need help. Some ideas survived. Others got removed when they added choice without reducing effort.
That has affected navigation, discovery, service categories, chat flows and how much of the provider-contact process should happen automatically.
Designing around a job, not a feature
The core job is simple:
That became the filter for product decisions.
If a feature made the user organise more, browse more or understand more of Fyn's internal process, it needed a very good reason to exist.
The AI has a job to do
I didn't want to add a chatbot because every product apparently needs a chatbot now.
The AI sits inside an actual workflow. It needs to understand what the user wants, identify suitable providers, communicate the request, interpret responses and return something useful enough for the user to act on.
I've built the workflow around automation with deliberate human approval points while the product is still learning. The aim is useful autonomy, not impressive-looking autonomy.
Building it changes how I manage it
Fyn is also where my product and technical work meet most directly.
I can move from user problem to product decision to implementation without throwing the idea over a wall. I work hands-on with AI coding tools, the database, workflows and integrations, which means technical constraints enter the product conversation early rather than arriving as a surprise at the end.
That doesn't remove the need for product discipline. It makes bad prioritisation even more dangerous because AI makes it very easy to build things you never needed.
What I'm learning
The biggest lesson so far is that convenience is a product feature.
People don't necessarily need more providers, more filters or more discovery. Sometimes the better product is the one that asks fewer questions and does more of the annoying bit for them.
Fyn is live, so this case study isn't finished. That's the point.
What comes next
The next stage is about learning where automation genuinely improves the experience, where users still want control and how the model works when the provider side grows.
I'll keep updating this case study as the answers change.