FixDas
Home services · Two-sided marketplace
One job. Two sides. A lot has to work in between.
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.
- Role
- Full-Stack Product Engineer
- Ownership
- End-to-end marketplace
- Status
- Production
- Core flow
- Post → Match → Connect
[ Project snapshot ]
Problem
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.
What I built
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.
My responsibility
Product flows and UX/UI, frontend and backend, marketplace rules, authentication, realtime communication, notifications, public discovery, infrastructure, and production.
[ The challenge ]
A simple request has to become useful to the whole marketplace.
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 ]
Filter first. Rank what remains.
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 ]
Subscription state changes how a professional participates in the marketplace.
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.
Subscription state
Active or trial
- Opportunity becomes actionable
- Connection request available
- Priority in featured discovery
- Pro Website available when enabled
No active access
- Relevant opportunity stays visible
- Contact remains locked
Relevance decides whether the opportunity fits. Subscription decides how the professional can participate in the marketplace.
[ Production meant modelling more than the happy path ]
Real usage adds the states around the clean marketplace flow.
- Post
- Match
- Connect
- Work
- A job can be cancelled, reassigned, completed, or archived.
- A connection can be declined.
- Access can change when a subscription state changes.
- A payment or webhook can fail.
- A conversation can receive new activity after being removed.
- A notification can become outdated before an email is sent.
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.
[ How the system connects ]
The rules stay consistent as users move through the marketplace.
- Request
- Job
- Eligibility
- Subscription access
- Connection
- Conversation
- Work
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.
[ The outcome ]
A working marketplace, not a collection of isolated features.
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 ]
I worked across the full product.
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.
- Product & UX/UI
- Frontend
- Backend
- Marketplace logic
- Authentication
- Payments
- Realtime communication
- Notifications
- Public discovery & SEO
- Infrastructure & production
- Product & UX/UI
- Frontend
- Backend
- Marketplace logic
- Authentication
- Payments
- Realtime communication
- Notifications
- Public discovery & SEO
- Infrastructure & production
[ Built with ]
- Application
- Backend & Realtime
- Authentication & Payments
- Communication
- Location
- Analytics, Privacy & Security
[ Let’s work together ]
Building a marketplace where the hard part sits between the screens?
I can help turn the rules behind it into a product that works end to end.
