Fyxes: on-demand home cleaning

Booking a cleaner shouldn't mean a group chat, three reschedules, and hoping the person who shows up is who you agreed to. Fyxes was my attempt to fix that for Melbourne: a proper two-sided marketplace where customers booked a clean in a few taps and cleaners ran their whole workload from the same system.

It was also the first product I built entirely on my own terms. I was the founder, the designer and the product owner, working alongside an AI-augmented team standing in for the engineering, finance and QA roles I couldn't hire for: Kai on engineering, Amy on finance, Knope on project management, Mochi on QA. Every call on scope, and especially on money and auth, got made the way I'd want a senior engineering team to make it.

The customer side starts with a home screen built around one job: get a clean booked fast. From there, a room-by-room builder (bedrooms, bathrooms, kitchen, living areas) prices the job as you go, so there's never a surprise total at checkout.

Confirmation closes the loop immediately: cleaner assigned, time and address locked in, room list itemised. No back-and-forth, no waiting to hear back.

None of that works without the other half: cleaners need their own tool to manage jobs, availability and service areas, or the whole thing turns into me manually matching bookings by hand. The cleaner app runs on the same booking data (upcoming jobs, ratings, availability), so both sides of the marketplace are looking at the same source of truth.

The apps were only half the operation. Around them I built a marketing website to do the SEO legwork, an ops dashboard to run the business from, and a pair of AI agents doing the work a support team would. Every surface designed, built and shipped solo, all of it in production.

The website's job was to be found, and then to convert. Sixteen suburb pages across Melbourne's inner north, each one hand-written rather than templated, structured data down to a per-suburb service schema, and an llms.txt so even AI assistants could quote the pricing correctly.

Pricing lives as code in a single shared schedule: one source of truth feeding the app, the website's earnings calculator for cleaner recruitment, and the structured data, so the numbers could never drift apart. And the cookie banner has a real reject: saying no genuinely tears the trackers down. A small thing, but it's the kind of honest UX I want my name on.

Behind the marketplace sat the dashboard I ran the company from: cleaner applications, document verification, disputes and call-outs as work queues, with live booking insights on a map. It started as a launch-week monitoring tool and hardened into a proper admin product, with multi-factor login and every state-changing action written to an audit log.

Its most important design rule: money never moves casually. Some surfaces hand the action to Codsworth in Slack to draft and approve; the ones that act directly state their money outcome in plain language before the button will work, and write to the audit log after. The post-payout dispute form is my favourite example: it tells you exactly what submit will do, the Stripe reversal, the fallback if the payout already cleared, who gets paged, before it lets you do it.

Fyxes used AI where it removed real toil, never as garnish. Cleaner onboarding is the clearest example: Claude reads each police check and insurance document in two passes, a quality gate that tells the cleaner instantly when an upload is unreadable, then extraction of names, expiry dates and coverage. The AI pre-screens; I made every final call. One detail I'm fond of: if the model abstains on an identity document for safety reasons, the document routes to human review instead of auto-reject. An AI declining to answer should never cost someone a job application.

Booking photos got the same treatment. Customers photograph their kitchen and bathrooms, and a vision model answers exactly one question: is this a regular clean or a deep clean? It shows its reasoning, it only speaks up when it's confident, and the customer always confirms. The rule we locked early: on a pricing path, no suggestion beats a wrong suggestion. If the AI fails, the booking flow never blocks.

Opi is the first responder. It watches live bookings for the moments that go sideways, a customer not home, a cleaner running late, a dispute, and works the problem over SMS with both sides while reporting to me in Slack. It runs on tiered autonomy: almost everything is drafted for my approval first, and its one self-serve money action is the $60 call-out fee, charged only after a timed three-message escalation goes unanswered.

Codsworth is the operations lead: a courteous AI butler who lives in my Slack DMs. Fifteen tools, from booking and customer lookups to long-term memory, and the two that matter, cancel and refund. Anything destructive posts a draft with an Approve button; nothing sends and no dollar moves until I tap it. Both agents run on a metered monthly budget with a hard pause, because an AI ops team should have a payroll cap too. And yes, he's named after the Fallout butler.

None of this ran unwatched. The whole platform reported into a single #fyxes-alert channel in Slack: severity-throttled pages when something broke, and a cron watchdog that checked all 38 scheduled jobs and posted a heartbeat on every tick. My favourite line in the whole system lives inside that heartbeat: if the message stops arriving, the watchdog itself is down. Even the thing that watches the things gets watched.

Running a marketplace solo is mostly a supply-chain problem: pick boring, reliable services and make them talk to each other. This is what was in the hold.

Fyxes launched in June 2026. I ran Meta ads, dropped flyers across nearby suburbs, offered 15% off a first clean, and recruited the supply side one conversation at a time. The top of the funnel did its job: 21 customers signed up, 19 cleaners registered, and five made it through document verification.

Then the number that mattered: zero. Not one of those 21 signups became a booking. Every booking in the production database was me, testing. The marketplace I had spent months hardening never processed a single real transaction.

When weeks of live marketing refused to move that number, I made the call to shut it down. Not because I stopped believing in the problem, but because the data had answered the question the company existed to ask, and the answer was no. Killing it quickly was the last product decision Fyxes needed from me. I think it was the best one I made.

I sequenced it backwards. I built a production system I'm still proud of: fraud signal logging, payout reconciliation, rate limiting, dispute flows. All of it defends against risks that require customers to exist. The only question that actually mattered, will a stranger pay for this, could have been answered in a fortnight with a landing page and a weekend of matching bookings by hand. I answered it last, after months of engineering. Next time: validate demand with the cheapest artifact that can produce a yes, and spend real engineering only after real money moves.

A two-sided marketplace is two cold-start problems at once, and a solo founder with a day job gets to solve one at best. Supply was winnable; cleaners answered flyers and finished verification. Demand needed a budget or a distribution edge I didn't have. I'd build a marketplace again one day, but not alone, and not as a 5-to-9.

What survived the shutdown: the AI-augmented team practice, the stack, the defensive instincts on money and auth, and a tested playbook for shipping production software solo. All of it went straight into Simply Kind, which went from first sketch to the App Store in a fraction of the time. Fyxes never returned the investment in bookings. It returned it in capability.