CasaFixx needed a WordPress-based service marketplace connecting homeowners with verified home-repair professionals, built as a custom plugin instead of a generic marketplace theme. ConicPlex delivered it in six weeks: job listings, a proposal system, partner accounts, task tracking, and Stripe payments for handling money between homeowners and providers. The build treated the partner dashboard as a first-class product from day one, not a screen bolted onto the booking flow after the fact, which is usually where marketplace builds like this start to wobble.
A marketplace brief that sounded simple on the call
CasaFixx came to us describing themselves as “like Airbnb, but for home repairs.” Homeowners post a job, verified professionals bid on it, the job gets done, everyone gets paid. Said out loud in a discovery call, it takes thirty seconds.
Built, it’s two products that happen to share a database. One side is a browse-and-post experience for homeowners: simple, fast, low-commitment. The other is a working tool for tradespeople who need to see open jobs, submit proposals, track what they’ve already committed to, and get paid without chasing anyone. Most of the actual engineering effort on this project went into the second half, because the first half is the part every marketplace demo already gets right.
Why a plugin, not a theme or a SaaS builder
CasaFixx wanted a foundation that could grow past its first service category without a rebuild. A marketplace theme or a hosted no-code marketplace builder gets a demo out the door fast, but the moment the brief includes a real approval workflow, a proposal system, and Stripe payouts tied to job state, most of those tools run out of road. Custom WordPress plugin development gave CasaFixx a data model built around how their business actually works: jobs, proposals, partner accounts, and payment state as first-class objects, not fields stretched to fit a booking plugin’s schema.
That decision also kept the door open for the thing most early-stage marketplaces underestimate: adding a second service category later without touching the core system. A rebuild six months post-launch tends to cost more than the extra planning did up front.
Building the partner dashboard first
The homeowner side of a service marketplace gets designed first and tested last, if it’s tested at all. On CasaFixx, we flipped that order deliberately. The partner dashboard is where a professional logs in between jobs, often from a phone or a mounted dashboard mount in the van, to see what’s open nearby, submit a proposal, and check whether yesterday’s completed job has actually been paid out.
That’s a different design problem than the homeowner-facing side. A homeowner opens the site once, posts a job, and leaves. A professional opens the dashboard daily, sometimes several times a day, often between appointments and without a great connection. So the dashboard prioritizes speed over polish in places a marketing site never would: fewer taps to submit a proposal, a task list that doesn’t require a page reload to update, and payout status that’s visible without digging through a menu.
What “verified” actually requires
CasaFixx’s brief used the word “verified” for its professionals, and it’s worth being precise about what that actually requires, because it’s easy to picture it as a checkmark icon and treat it as a design detail. In practice it’s an admin workflow: a new provider has to be reviewed before they can bid on jobs, there needs to be a real state machine for pending, approved, and flagged accounts, and the public listing has to reflect that state without exposing the review process itself to homeowners browsing the site. Skip that plumbing and “verified” is just a word on the page. A homeowner who gets burned by a “verified” provider stops trusting the whole platform, not just that one listing.
What actually happens when the job is done
Payment timing is the decision that gets skipped in early specs and then argued about three weeks after launch. Does a professional get paid the moment a homeowner accepts their bid, on job completion, or held back for a dispute window? Each answer changes what the Stripe integration has to do. Stripe handles the mechanics of moving money between accounts, but it doesn’t decide when that money should move. That’s a business rule the platform has to state explicitly, encode into the job’s state machine, and surface to both sides so nobody is guessing. On CasaFixx, payouts release on job completion with a short hold for disputes, a decision made before a single line of the payment logic got written, not discovered while debugging it.
Marketplace payment infrastructure has become the default rather than the exception for platforms like this. Stripe reports that roughly three out of four of the world’s largest marketplaces now run their provider onboarding, payment splits, and payouts through Stripe Connect, and Stripe itself has been pushing newer platforms toward its Accounts v2 model for exactly this kind of two-sided setup. CasaFixx’s build sits squarely in that pattern: a marketplace operator handling the trust and workflow layer, with the money-movement plumbing handled by infrastructure built for it.
Six weeks, start to finish
The full build shipped in six weeks on a job-and-booking-style workflow, working in WordPress alongside PHP, JavaScript, and the Stripe API. What shipped:
- A job posting and browsing system for homeowners
- A proposal and bidding system for professionals
- Partner account management with a verification state machine
- Task tracking from accepted proposal through completed job
- Stripe payment integration handling provider payouts
None of that is exotic individually. What made the timeline work was building it as one connected system from the start, rather than a booking plugin with a payment plugin and a user-role plugin stapled to it after the fact. That’s usually where the six-week estimate turns into a twelve-week one.
What this means if you’re scoping something similar
The lesson from CasaFixx isn’t “build a marketplace in six weeks,” because that number depends entirely on how much of the provider-side workflow gets designed before development starts, not just how fast the code gets written. The actual lesson is where the effort needs to go: the provider dashboard, the verification state machine, and the payment timing decision are the parts that determine whether a two-sided marketplace holds up once real transaction volume shows up, not the parts that make it into the demo.
We’ve written more broadly about where marketplace platforms tend to get underbuilt if you want the wider pattern beyond this one project. For a look at other WordPress plugin builds we’ve shipped, our plugin development portfolio has the full list, and if a marketplace project needs a dashboard, portal, or internal tool layered on top of it, that’s what our web application development team handles alongside the plugin work.
Sources
Stripe Connect for marketplaces, cited for provider onboarding and Connect adoption figures among major marketplace platforms.
