FixyCome — "We come and fix, that's it."

"We come and fix, that's it." A reverse marketplace that connects people with trusted, nearby home-service professionals. Post a job, receive bids from pros around you, pick & pay

Comment

I## Inspiration

In Pakistan, finding someone to fix a leaking tap, a tripped circuit, or a broken door is still done the old way: ask a neighbour, dig up a number written on the back of an old receipt, and hope the person picks up. If they're busy, you start over from zero. There's no way to compare price, no way to know if the person is any good, and no record if something goes wrong.

At the same time, there are thousands of genuinely skilled electricians, plumbers, and carpenters across the country whose income is capped not by their skill, but by the size of their personal network. A five-star worker in one neighbourhood might be completely unknown three streets over.

That mismatch — real skill on one side, real need on the other, and nothing efficient connecting them — is what we set out to fix. We didn't want to build "Uber for home services" as a slogan; we wanted to build something that actually fits how services are hired and paid for in Pakistan today: informally, locally, and in cash.

What it does

FixyCome flips the usual home-services model around. Instead of a customer searching for a worker, the customer posts a job — a short description, a category, and their area — and nearby professionals come to them with bids.

  • A customer posts: "Kitchen tap is leaking, Gulberg, Lahore."
  • Nearby verified professionals send bids: a price, their rating, and how many jobs they've completed.
  • The customer compares and picks whoever fits their budget and trust level.
  • They chat, the pro shows up, and the work gets done.
  • Payment happens directly, in cash — FixyCome never touches the money.

We're an introducer only. We don't employ the workers, we don't guarantee the job, and we don't take a cut of the cash. That restraint is deliberate — it keeps the product honest and easy to trust on both sides.

The name says it in five words: "We come and fix, that's it."

How we built it

We treated this as a real product from day one, not a weekend prototype, so the stack reflects that:

  • Mobile app: Expo React Native (SDK 51) with TypeScript, Zustand for state, and React Navigation — built mobile-first, since that's how our audience actually gets online.
  • Backend: FastAPI with asyncpg, our own JWT auth built on phone number + bcrypt rather than a third-party auth provider, split into ten modules (router / schemas / service per domain), with rate-limiting middleware.
  • Database: PostgreSQL 15 via Supabase, with PostGIS for geospatial "who's nearby" matching and Realtime for in-app chat. We run two fully separate Supabase projects — a development database we're free to reset, and an isolated production database for real beta users that never gets touched.
  • Identity & trust: professionals verify with their CNIC (Pakistan's national ID). We never store it in plain text — it's hashed for lookups and Fernet-encrypted at rest, with only the last four digits ever visible.
  • Public beta site: a deliberately simple static HTML/CSS/JS site — no framework, no build step — so it deploys with a single drag-and-drop onto Vercel. It's connected directly to a beta_applications table in the production database with row-level security that only allows inserting an application, never reading one back — so the public key that ships in our frontend code can never see anyone else's data.

We designed the whole system so that security wasn't a bolt-on: Row-Level Security is enabled on every table in the schema, not just the sensitive ones, and we verified it (row counts, policy counts, RLS status) rather than assumed it.

Challenges we ran into

  • Designing for trust without a bank account. Most fintech UX assumes a card or a wallet. Ours can't — cash is the payment rail our users already trust, so the trust problem had to be solved entirely through identity verification and reputation, not payment infrastructure.
  • Building for a low-literacy, Urdu-first audience without making the product feel like it was designed for someone else and translated as an afterthought. That shaped everything from copy length to how much we lean on icons and structure over text.
  • Keeping two databases straight. Once we had a real production database holding real people's encrypted identity data, "just reset the DB" was no longer an option we could reach for casually — we had to build the discipline (and the tooling) to keep dev and prod genuinely isolated.
  • Locking down the public-facing form. A public beta-application form talking directly to our production database is a real attack surface. Getting the Row-Level Security policy exactly right — insertable by anyone, readable by no one except our backend's service role — took careful testing, not just a "seems fine" glance.
  • Resisting scope creep. It would have been easy to bolt on in-app payments, subscriptions, or a rewards system. We kept cutting back to the core loop — post a job, get bids, pick, pay cash — because that loop is the entire value proposition, and everything else is a distraction until it's proven.

Accomplishments that we're proud of

  • A production-grade backend and database live and hardened — not a mock, not a stub — with PostGIS matching and Realtime chat actually working.
  • Real, verifiable security: encrypted CNIC storage, RLS on every table, and a public form that provably cannot leak data back out.
  • A public beta site that's clean, dark, mobile-first, and genuinely usable on a small Android screen with one hand.
  • Staying disciplined about the product's honesty: FixyCome states plainly, in the product and in the legal pages, exactly what it is and isn't responsible for.

What we learned

Building for an informal, cash-based economy taught us that the hardest design problems aren't the technical ones — PostGIS queries and RLS policies are solvable with enough care. The hard problem is resisting the urge to import assumptions from products built for a different market: that everyone has a card, that everyone reads long text comfortably, that trust can be manufactured with reviews alone. Real trust, for this audience, comes from verified identity and a visible track record — so we built around that instead of around a five-star review widget.

We also relearned a smaller but important lesson: isolating production data early, before there are real users in it, is far easier than trying to retrofit that discipline later.

What's next for FixyCome

  • Expand the private beta to more testers and more cities across Pakistan.
  • Build out the in-app professional verification and onboarding flow at scale.
  • Add ratings, dispute handling, and a "book again" flow for repeat customers.
  • Explore optional digital-payment rails as an add-on — while keeping cash as the permanent default, because that's what actually matches how our market pays today.nspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for FixyCome — "We come and fix, that's it."

Built With

Share this project:

Updates

Submission history