FixDas
Home services · Two-sided marketplace
I designed and built FixDas as a two-sided marketplace for clients who need work done and local professionals deciding which jobs are worth taking on.
[ Project snapshot ]
Clients need a simple way to explain what needs doing. Professionals need enough context to decide whether a job fits their trade, services, location and availability.
[ Let’s work together ]
I can help turn the rules behind it into a product that works end to end.
A marketplace that turns client requests into structured jobs, finds relevant local professionals, and connects subscription state to lead access, communication, professional discovery, public profiles, and guided onboarding tour.
Product flows and UX/UI, frontend and backend, marketplace rules, authentication, realtime communication, notifications, public discovery, infrastructure, and production.
[ The challenge ]
The client-facing side of FixDas needs to feel straightforward: describe the work, add the practical details, and publish the request. The professional side needs much more context before that same request becomes useful.
Job creation therefore could not be treated as an isolated form. Information captured at the beginning had to support decisions later: whether a professional is relevant, whether the job is within their service area, whether the timing fits, and whether there is enough context to respond.
[ From a request to a relevant opportunity ]
I structured job data so it could be reused beyond the posting flow. Services support matching, location supports distance filtering, timing and availability rule out poor fits, and budget and project details give professionals useful context before a conversation begins.
FixDas first checks whether an opportunity can be relevant at all. Only after those eligibility checks does ranking become useful.
[ The business model became product behaviour ]
Matching and subscription solve different problems in FixDas. A professional can be a strong match for a job regardless of whether they currently have a paid subscription, so I kept relevance independent from billing.
Subscription state instead changes what happens after that match. A professional with active or trial access receives an actionable opportunity and can contact the client, while a professional without the required access can still see that a relevant opportunity exists without being able to act on it.
The same billing state reaches beyond leads and messaging. Active or trial professionals receive priority in featured-professional discovery, and the public FixDas Pro Website is available only to subscribed professionals who have chosen to enable it.
A first contact also starts as a connection request. The recipient can accept or decline it before the exchange becomes a normal two-way conversation.
Relevance decides whether the opportunity fits. Subscription decides how the professional can participate in the marketplace.
[ Production meant modelling more than the happy path ]
[ How the system connects ]
[ The outcome ]
FixDas connects structured job creation, relevant professional matching, subscription-driven access, communication, job progression, and public discovery in one product.
Matching remains based on relevance rather than payment. Subscription state changes whether a lead is actionable, whether a professional can contact a client, how professionals are prioritised in discovery, and whether their Pro Website can be published. Connection and job states then control what happens as the relationship progresses.
The business rules carry across the marketplace instead of being reimplemented screen by screen.
[ What I owned ]
From shaping marketplace flows and designing the UX/UI to implementing the frontend, backend, data model, business rules, integrations, infrastructure, and production.
I also built a guided onboarding tour for first-time users, helping them understand the dashboard and the main actions without having to explore the product on their own.
[ Built with ]
I modelled those states across jobs, conversations, subscriptions, payments, notifications, and external integrations instead of leaving individual screens to guess what should happen.
Public professional profiles use the same state-driven approach. A professional must explicitly enable the Pro Website and have active or trial access before the public page is available. Content quality is evaluated separately: incomplete profiles remain noindex until they contain enough useful, distinct information.
Publication and sitemap eligibility use shared rules, while canonical URLs, structured data, and indexing metadata are generated from the same profile state. That keeps public discovery aligned with what the product actually allows.
Authentication, subscription state, notifications, job lifecycle rules, and public discovery sit around that flow. They do not operate as separate feature checks: they read the same underlying product state so the rules stay consistent as users move through the marketplace.
Subscription state
Active or trial
No active access