Swiffy

Home services apps bleed providers dry with commissions and pay-per-lead. Swiffy doesn't. Clients describe a job in chat, our AI matches nearby providers, they talk directly. Flat subscription.

Comment

Inspiration

I started Swiffy because I lived the problem.

While studying, I was tired of working shifts in shops for other people, so I started my own small business. I live on the Portuguese coast, where salt, sand and dust are constantly in the air — beach-front windows are never clean for long. So I started a window cleaning business. The work was there, the money was decent, and for the first time my schedule was mine: I could fit clients around classes.

Then I noticed something that stayed with me: I was spending more time looking for clients than actually doing the work.

So I looked at the platforms that were supposed to solve exactly that, and found a market that has barely moved in a decade:

  • They run on rigid forms. A client with a problem is asked to pick a category, then a sub-category, then answer a fixed questionnaire written for the average job — not theirs. Most people don't know which box their problem belongs in, and a large share simply abandon the flow. Client churn is enormous.
  • They hide the supply. Many of them won't even show you which providers exist in your area until you've filled everything in and handed over your contact details.
  • They charge providers to survive. Heavy commissions on every job, or pay-per-lead — you pay for the contact whether or not it ever becomes work. So providers churn too, and for a very rational reason: those fees don't come out of profit, they come out of the margin that makes the whole thing worth doing.

Swiffy is the app I wanted back then: describe your problem in plain language, or just browse the providers around you — and on the other side, a flat subscription with no commissions and no pay-per-lead — plus business and visibility metrics, profile optimization tools, and a platform built for providers to thrive. I understand this market because I've been on the provider side of it. I know what providers look for, how they price, and what makes them quit a platform.

What it does

Swiffy connects clients who need a service with the providers who can do it — and it gives the client two ways in, instead of one funnel.

1. An assistant instead of a form. The client opens the chat and says what's wrong — a leaking tap, dirty windows, a broken lock. The assistant asks whatever it needs to, then finds providers. No category tree, no questionnaire. As far as we know, Swiffy is the only services marketplace where an AI assistant guides the client instead of a fixed form.

  • Provider cards in the chat. When the assistant has matches, they're rendered as rich provider cards inside the conversation, not as a wall of text. The client can tap a card, open the full profile and contact that provider directly — the shortest path there is from "I have a problem" to talking to the right person.
  • Or send a request and let proposals come to you. Sending a service request is the complementary path, for clients who want more options rather than one direct contact: the assistant assembles the request and presents it as a card to confirm and complete, and interested providers come back with real proposals.

2. A directory that's open from the start. A client who'd rather look around never has to talk to the assistant at all. They can open the directory, immediately see every available provider in their region, browse full profiles, and contact them directly.

And in both paths, the conversation is between client and provider. Swiffy doesn't sit in the middle of the relationship — clients and providers message each other directly in the app.

A fair model for providers: flat subscription, no commission on jobs, no charge per lead.

How we built it

The client app is built in Flutter, with FlutterFlow for rapid UI iteration, and a backend server that hosts the agent logic and talks to Google Vertex AI. Swiffy was built from scratch for this hackathon: an earlier, unrelated app of ours — no AI, commission-based — contributed only two generic UI pieces to the chat screen, a text input field and the message bubbles, and both were redesigned along the way. Everything else here is new.

Swiffy has used Google models from day one — there was never another provider for the assistant, and every piece of AI logic in the product runs on Google.

The stack

  • Gemini 2.5 Pro on Vertex AI — the main assistant the client talks to
  • Google embedding models — used both for indexing providers and for embedding queries at search time
  • A vector database of providers — semantic and hybrid retrieval
  • Google Maps and location APIs — proximity and geographic context

The agent and its tools

The main assistant runs a tool-calling loop. Its most important tool is semantic search over the provider vector store: the client's need is embedded and matched against indexed providers by similarity,

$$\text{sim}(q, p) = \frac{\mathbf{q} \cdot \mathbf{p}}{\lVert \mathbf{q} \rVert \, \lVert \mathbf{p} \rVert}$$

and the strongest matches are surfaced. It can also run hybrid searches, combining vector similarity with non-vector filters — for example, providers within 5 km who clean windows.

No fixed categories. This is the design decision the whole product rests on. Swiffy has no category tree at all. A provider describes the services they offer in their own words; that description is embedded and indexed. Onboarding becomes far simpler, and a new type of service doesn't require anyone to create a new category — it just becomes searchable. The taxonomy problem that usually slows a marketplace down disappears into the vector store, and the client never has to guess which box their problem belongs in.

Structured output for rich UI. The assistant is prompted to emit its results in a specific parseable format. When it wants to show providers, it returns a structured provider list; when it wants to submit a service request, it returns a structured request. The frontend parses that output and renders pre-designed cards inside the chat. The result feels like a native interface rather than a chatbot, while the whole flow stays conversational.

Challenges we ran into

Getting one model to hold several jobs at once. Our assistant is not a single-purpose bot. It has to guide users through the app, explain how Swiffy works, find the right providers, and assemble and submit service requests — and know which of those it's doing at any given moment. We started on Gemini 2.5 Flash and spent real time trying to optimise it: prompt structure, tool descriptions, tighter instructions. It kept blurring the boundaries between those modes.

Eventually we made a deliberate trade: reliability over latency, and moved the assistant to Gemini 2.5 Pro. That single change let us hand the assistant more tools rather than fewer, and we gained consistency in structured output and noticeably better handling of European Portuguese — including the small conversational details that make an assistant feel local rather than translated.

Making semantic search actually precise. A category-free marketplace only works if retrieval is right, and "roughly related" isn't good enough: a client looking for an electrician must not be shown plumbers. A large share of our engineering time went into tuning that — the match threshold, how provider data is stored and structured for indexing, and how queries are built before they're embedded. And it had to hold in both languages the app runs in, Portuguese and English, so that the same need expressed in either one lands on the same providers.

The cold-start problem, in the middle of app review. Swiffy is a two-sided marketplace, which collided badly with the Google Play Console requirement for a 14-day closed test with 12 testers. Testers on one side of a marketplace have very little to actually do without the other side present. After the full 14 days we were rejected for insufficient in-app activity. The path forward was to incorporate a company and open an organisation Play Console account, which removes that requirement — but the process cost us weeks and pushed the Android launch past our target.

Verifying provider identity without becoming a data liability. A services marketplace lives or dies on trust, so providers have to be verified. Our first approach was to do it ourselves: providers submitted their identity documents, we stored them, and we reviewed them manually — which eventually meant building a second, back-office application just to run those checks. It worked, but it put us in a position we didn't want to be in: holding highly sensitive personal documents, with all the legal and security responsibility that carries, as a one-person company. Late in development we found Didit, an identity verification platform with a Flutter SDK, and the integration turned out to be straightforward. Verification is now handled entirely by our partner — we no longer keep provider identity documents at all. It simplified the flow, removed a whole class of legal risk, and solved the problem properly rather than manually.

Two apps in one, from a reviewer's chair. Swiffy is effectively two products sharing one binary — the client experience and the provider experience — separated by conditional visibility depending on who's signed in. That's the right design for users, but it was repeatedly rejected during Apple's App Store review, because a reviewer landing on one side of the app couldn't see how the other half worked or how the two connect. Getting through took several rounds of clarifying and demonstrating the full flow to reviewers who were, understandably, only ever seeing part of it.

Shipping solo. Swiffy is built by one person, under a company account. Every decision — agent design, retrieval, UI, store compliance, incorporation — landed on the same desk.

Accomplishments that we're proud of

  • It's live. Swiffy is published on iOS in Portugal, built from scratch for this challenge.
  • A category-free marketplace that actually works. Removing fixed categories in favour of vector-native matching is a bet, and it holds up: providers onboard by describing themselves, and clients find them by describing a problem.
  • A conversational interface that doesn't feel like a chatbot — structured output driving real, designed UI components inside the chat — with an open directory alongside it for clients who'd rather browse.
  • Most of all, building something that takes the provider's side. Service providers create enormous value for a country and for the people around them, and their work should be rewarded for what it is. Swiffy exists to empower them, not to reach into their wallet.

What we learned

  • Model selection is a product decision, not a cost decision. We tried to make a cheaper model carry a complex, multi-role agent. Moving to Gemini 2.5 Pro didn't just fix output consistency — it changed what we were willing to let the assistant do, because we could finally trust it with more tools.
  • Embeddings can replace a taxonomy. We expected semantic search to improve discovery. What we didn't expect was that it would delete an entire category of product work — maintaining a service tree, mapping providers onto it, and onboarding around it.
  • Language quality is a feature. For a Portuguese-first product, handling European Portuguese naturally is not a nice-to-have; it's the difference between an assistant users trust and one they abandon.
  • Distribution is part of building. The hardest weeks of this project weren't model or architecture problems. They were store policies designed for single-sided apps, applied to a marketplace.

What's next for Swiffy

What's live today is an MVP, and our immediate priority is not new features — it's making the existing ones excellent. Sharpening the assistant, the matching quality and the directory experience comes before anything we add on top.

  • Launch on Android, now that the organisation Play Console account clears the closed-testing requirement.
  • Refine the MVP: better retrieval, a smarter assistant, a smoother path from "I have a problem" to "someone is coming".
  • Refine the UI and UX. Tightening the interface of both sides of the app — fewer steps, clearer profiles, a more polished feel throughout. High on that list: streaming the assistant's responses, so the reply appears as it's generated instead of arriving all at once. That's the direct answer to the latency we accepted when we moved to Gemini 2.5 Pro — the model stays, the waiting goes away.
  • Bring Swiffy to the web. A client-facing web app is planned, so people can describe a problem, browse the providers around them and send a request straight from the browser — no install required, and a far shorter path from a link or a search result to a real service request.
  • Focus hard on marketing and on the supply side. A marketplace is only as good as the providers in it, and our pitch to them is simple: keep your margin. Winning this prize would be a genuine accelerator here — for a solo-founded marketplace, distribution is the hardest part of the problem, not the technology.
  • Grow deliberately. We believe Swiffy can be the platform this market has been missing: clients find the right provider in seconds, and providers get the tools to grow a real business — backed by a team that's invested in their success and there when they need it. It will take time to build density. Slowly but surely.

Built With

Share this project:

Updates