Across the last few home-services marketplace builds I've been part of (cleaning, repairs, salon-at-home type booking flows), the same three things kept eating more time than expected, in this order:

1. Provider trust/verification document checks, ratings, and dispute handling needed to be right from day one. Bolting it on after a few bad-actor incidents was way more expensive than building it in up front.

2. Payment splits and payout timing getting the wallet logic right between customer and provider (holds, refunds, payout schedule) caused more support tickets early on than any missing feature did.

3. Scheduling conflicts double-bookings and no-shows quietly killed early retention more than discovery or search ever did.

What surprised me is that none of these three were the thing founders originally worried about most going in most people spend their early planning time on discovery/search UX, and the actual pain shows up somewhere else entirely once real bookings start happening.

Curious if others building in this space saw the same pattern, or if something else entirely turned out to be the real bottleneck for you onboarding the supply side, pricing/commission structure, something else?

Most startup advice says: don t go solo.

It s practically gospel, especially if you want to raise money.

But I ve met plenty of founders who started solo and stayed that way. Some thrived. Some flamed out. Some figured out how to build a support system around them without giving away half the company.

What is a tool you use everyday but cringe when you have to open them? For me, Excel and Adobe PDF. Replacement recs?

Many of us enter tech with years of experience in another field, bringing valuable skills to the pivot. But that transition is rarely smooth or easy. Speaking to other founders who have made a tech pivot has been tremendously valuable.

I come from the entertainment and dating space, mostly working B2C as a service provider. The shift to a B2B SaaS start-up meant changing my approach to business development and adapting my marketing know-how to a very different audience and new clientele (brands/employers). The hardest part is realizing that some of my skills aren t transferable 1:1, so I have to adapt my B2C go-to strategies for B2B. It s a different animal.

For example, in B2C, articulating the problem and helping your customer see themselves in your solution requires a different skill. It s about meeting your customer emotionally and connecting with their desired outcome, which is very different from B2B. With B2B, you re building longer-term relationships and discussing ROI. It s less emotional and more about efficiency. The pain points are different, but in many respects the conversation is the same. I can help you, and here s how.

What learnings, challenges, or obstacles have you had to overcome to succeed in tech? What advice do you have for newcomers launching a product or service in this space?

Retention dashboards usually tell us who came back. They rarely tell us whether the product helped someone return after falling behind.

For learning, fitness, finance, and any habit-shaped product, recovery deserves its own measurement: time from interruption to meaningful return, the smallest successful comeback action, and whether the product reduces guilt or adds to it.

A system that only works for perfect streaks is optimized for the users who need it least.

What does a good recovery path look like in your product?

Automation demos end at the click. Real operations begin when the click partially succeeds.

If an agent creates a record, sends a request, updates permissions, or starts a job and then loses context, who owns the next step? A human needs an exact action log, current external state, safe retry behavior, and a clear answer to whether repeating the action will duplicate anything.

Agent failed is not a handoff.

What information would you need before taking over a failed automated task?

Would you use this? creates optimistic answers. What did you do the last time this happened? gives you a workflow, cost, workaround, and competing priority.

The follow-up I like is: what did you do instead when the product was unavailable, confusing, or not worth paying for?

That answer reveals the real competitor. Sometimes it is another tool. Often it is a spreadsheet, a friend, a search tab, or doing nothing. A beta is more useful when it reconstructs behavior than when it collects feature wishes.

What substitution surprised you most in user research?

Launch retrospectives often become traffic summaries: rank, views, signups, comments. Useful, but none of those says what the team learned.

I think every postmortem should name one belief the launch disproved. Maybe the audience misunderstood the promise, setup friction mattered more than price, or the users who converted were not the segment you expected.

If nothing could have changed your mind, the launch was distribution, not an experiment.

What belief did your last launch force you to update?

Personalization gets dangerous when the system treats its inference as more authoritative than the person using it.

If a user says this is too easy, changes a goal, removes a topic, or asks the system to forget a preference, that correction should take effect immediately. It should not become one more weak signal waiting to be averaged against weeks of behavior.

I think the hierarchy should be explicit:

1. direct user correction