Fixli

Venture Formation

Turning Home Repair Uncertainty Into Product Strategy: why existing home service platforms still leave both sides with unanswered questions.

+

Fixli began with a structural question: why do homeowners still call three contractors and wait a week for quotes when the platforms to find them already exist?

The home services market is large and fragmented. Platforms have made discovery easier, but discovery alone does not remove the hesitation that appears before booking. Homeowners still need confidence in the person they contact. Pros still need confidence that a request is worth their time.

When a homeowner finds a pro, they still have to explain the problem, wait for follow-up, and judge whether the response feels fair. When a pro receives a request, they still have to decide whether the job seems real, clear, and workable before investing time in it.

Emerging AI tools make it possible to reduce some of that ambiguity. My design work focuses on how a homeowner can describe a repair need naturally while the product helps translate that request into clearer context for everyone involved.

Fixli is not just a better search engine for home repair. It is an effort to make the moment before commitment feel more understandable, fair, and actionable.

Design Response

I shaped the early experience around a simple principle: homeowners should not need professional language to ask for help, and pros should not have to guess what they are being asked to evaluate. The design work centers on making vague repair needs feel clearer without making the process feel clinical or over-automated.

Design Approach

From vague repair need to clearer next step: designing a flow that helps both sides understand what matters before they commit.

+

The defining product question was how much help the interface should provide before either side feels locked into a decision.

1. Describe need
2. Clarify context
3. Compare options
4. Decide next step

Design Principles

Reduce translation burden. The homeowner should be able to start with plain language. The product should help turn that into useful context without asking the homeowner to become an expert.

Make uncertainty visible. A repair request often contains unknowns. Instead of hiding those unknowns, the interface should make them easy to resolve at the right moment.

Design for both sides at once. The same information can create confidence for one side and hesitation for the other. My work focuses on balancing those needs instead of optimizing one side in isolation.

Keep the human decision in view. AI can support clarity, but the product still has to feel accountable, legible, and respectful of the homeowner's judgment.

Protect sensitive product detail. Because the project is still in progress, this case study describes the design challenge and my role without disclosing internal product mechanics or unreleased plans.

Two-Sided Trust UX

The most important insight in Fixli's early design work was that homeowners and pros make their trust decision at different moments, while current platforms often treat trust as if it happens at the same time for both.

A homeowner decides to trust before they've committed any money: at the moment they choose which pro to contact, or which response to accept. They need enough context to feel that the option is credible, fair, and appropriate for the situation.

A pro decides to trust before they've committed any time: at the moment they receive a request and decide whether to respond. They need enough context to understand whether the inquiry is real, clear, and worth pursuing.

These trust signals are not the same. Designing for one side does not automatically serve the other. Much of my work has been about identifying where the two perspectives overlap, where they diverge, and how the interface can create confidence without exposing unnecessary complexity.

The design exploration looks at how homeowners evaluate credibility before booking and how providers evaluate whether a request is worth responding to. I focused on the information hierarchy, tone, and sequencing needed to make those decisions feel less opaque.

Because the project is ongoing, specific screens and internal learnings remain private. The public version of this case study emphasizes the design problem, not the confidential solution.

Current State

Fixli is an ongoing project. The current work is focused on validating the early service experience and shaping the core interactions for a trustworthy home repair marketplace.

My design work to date spans early product strategy, user flow definition, interface exploration, and service design across both sides of the marketplace.

Additional launch plans and unreleased product details remain private.

What I'm Learning

The thing Fixli has clarified most sharply is that AI features and trust are not the same thing. It is possible to make a flow more efficient while making it feel less human. The harder design work is deciding when the product should help, when it should ask, and when it should hand control back to the person making the decision.

The two-sided nature of the problem makes this harder. Every trust mechanism for the homeowner has consequences for the provider, and every provider-side requirement changes the homeowner experience. That tension has pushed me to think about trust as a system, not a single screen.

The founding work on Yerbba taught me to think about service architecture before screens. Fixli extends that lesson into a more ambiguous consumer context, where the interface has to make a high-friction offline service feel understandable before anything has happened yet.