Building a home without a general contractor is one of the hardest things a person can take on. PocketBuilder connects first-time homebuilders with the subcontractors they need to get it done. But that connection only happens if both sides trust the platform from the start. Each user type gets their own onboarding flow, built to earn that trust immediately.
First-time homebuilders have no idea where to start when building without a general contractor. Subcontractors need steady work but have no reliable place to find residential jobs. Both problems exist because there's no shared space where these two groups can find each other.
I designed the complete onboarding flow for both user types — homebuilder and subcontractor — working alongside a Senior UX Designer and Senior Developer. The task wasn't just to collect information. It was to earn trust from two very different people before either of them was asked to commit to the platform.
A first-time builder taking on a project most people hire out completely. They're motivated but overwhelmed. They don't know what stage they're in, what's coming next, or if they're making the right calls. They need a system that makes them feel capable, not more confused.
A tradesperson, like a framer, plumber, or electrician, looking for residential work. They don't find jobs through ads. They find them through relationships built on the job site, over years. PocketBuilder has to earn a spot in that world fast, or they won't stick around.
The original onboarding was transactional: collect basic information, then push toward payment. For most products that's friction. For PocketBuilder it was structural. A homebuilder committing to this platform is making a decision adjacent to one of the largest purchases of their life. Asking them to pay before they've seen anything meaningful wasn't going to work. We moved to a value trigger model: collect just enough upfront, then show the user a personalized snapshot of their build journey before any payment is requested. We knew this would work because the client's team was already doing it by hand, walking prospects through the platform's value in person. We just built the version that could do it for everyone, automatically.
After onboarding, homebuilders land on their Journey page, a personalized roadmap for their build. The instinct was to give subcontractors the same treatment. That would have been the wrong call. A subcontractor doesn't need a roadmap. They need work. The moment they finish onboarding, the most valuable thing PocketBuilder can show them is real jobs in their area they can bid on. That's the entire reason they signed up. Subs don't find work through advertising; they find it through relationships built over years. The Marketplace had to function as a digital version of that introduction. Not a feature they'd discover later. The first thing they see.
During subcontractor onboarding, the question came up of when to collect business information: license numbers, insurance, trade specialization. The Senior Designer's position: it needed to be in the flow, since the platform requires it and collecting upfront sets the user up better. My concern was conversion. A sub who just finished a job site doesn't have their license number memorized. Hit a required field they can't fill in, and they don't go find the document. They close the tab. We didn't scrap the requirement. We added a skip option. The business info stays in the flow, surfaced at the right moment, but no user is blocked from finishing because they don't have a document on hand. Skip it, and features like bidding stay locked until the profile is complete. The motivation to finish is built into the product. We just stopped holding onboarding hostage to it.
Account creation opens the flow, but it's not asking for payment. It's asking for the minimum needed to save progress. Moving this to the front was driven by a technical requirement: the developer needed a user record before onboarding data could be stored cleanly, and it opened the door for Google authentication. The value trigger and paywall still come later. Commitment happens after the user has seen what they're paying for.
This is the first question that feeds the value trigger. The three options map to meaningfully different starting points that determine what the platform shows next. The sub-labels clarify without adding friction. This answer is what makes the value trigger feel personalized rather than generic.
Just the basics: project name, address, and timeline. Address is optional, so nobody gets stuck filling out something they don't have yet.
Before any payment is requested, the homebuilder sees a personalized breakdown of their build journey based on what they just told us. The headline does specific work. "With confidence" speaks directly to the homebuilder's core anxiety. The phase breakdown shows the platform is already working for them. A scalable version of a conversation the client's team was already having by hand.
Business information stays in the onboarding flow, surfaced at the right moment, in the right context. But no user is blocked from finishing because they don't have a document on hand. Skip it, and features like bidding stay locked until the profile is complete. The incentive to finish is built into the product.
Every decision in this onboarding was made in service of the same goal: get both users to trust the platform before asking them for anything significant. For the homebuilder, that meant showing them a personalized view of their build journey before the paywall. For the subcontractor, it meant landing them directly in the Marketplace — the only place that could immediately prove the platform was worth their time. The skip option existed for the same reason: a motivated user who can't finish onboarding because they don't have a document on hand isn't a failed conversion. They're a blocked one. Each of these decisions was designed to remove that kind of friction without lowering the bar for what the platform needed from its users.
The best decisions on this project came out of conversations, not solo work. Talking through the design with Changa surfaced considerations I hadn't thought of, and his experience either validated the direction or pushed it somewhere better. Working closely with the developer brought up a different set of questions entirely, around what information the onboarding actually needed to collect and why. I came in with observations that hadn't been considered yet. Those conversations turned them into real solutions.