AkiPath

• 6 months

  Solo build timeline

• 30+

  Profile data points collected

• Live

  End-to-end email application loop

• 1.0–5.0

  Application Strength Score

Every year more than 500,000 skilled economic migrants arrive in Canada, and a significant proportion settle in Ontario — particularly the Greater Toronto Area. Most have stable employment, verifiable savings and every intention of paying rent on time. Most also get rejected by landlords before a single conversation happens.

The reason is not their reliability. It is their invisibility inside Canadian trust systems. Ontario landlords screen on three signals: Canadian credit score, local rental history and Canadian references. A newcomer who arrived six months ago from Nigeria, Ghana or Kenya with a full-time offer and six months of savings has none of them. Not because they are a risk — because they are new.

I was the sole product lead, designer and product owner. I ran discovery, defined the problem space, wrote the PRD, designed every screen and flow, authored every prompt used to build the product, made every architecture and prioritisation call, ran closed beta testing with real users, and iterated on what came back.

• Discovery & research
• PRD
• System design
• UX / UI
• Prompt engineering
• Architecture decisions
• Beta management
• Iteration

I also made the structural call that defined the build: pivoting from an AI conversational intake — which produced validation bugs, looping responses and inconsistent data — to a stepped wizard with constrained inputs. That decision saved weeks of debugging and delivered a far more reliable pipeline into the matching and application engine.

“I had the money. They still said no.”

Primary research. I interviewed newcomer tenants from West African countries living in the GTA. Three themes recurred in almost every conversation.

Secondary research. I mapped the Ontario rental application process against what newcomers can actually provide. The gap is structural: OREA Form 410 assumes Canadian credit history, local employer references and previous Canadian landlord contacts. None of these apply in a first year.

Landlord interviews. Speaking directly with a GTA landlord surfaced four things: they want Tinder-style matching, a fast signal of fit before investing time; their biggest fear is non-payment, not immigration status; they are receptive to advance rent (3–6 months upfront) as a substitute for missing credit history; and they take professionally packaged applications materially more seriously.

Mom Test discipline. I never asked whether people would use the product. I asked them to describe the last time they looked for housing, how they applied and what happened. The hair-on-fire problem — being taken seriously by a landlord who has no information about you — emerged consistently without prompting.

The insight that shaped everything: AkiPath is not a listings platform. Kijiji has more listings than we could ever scrape. The defensible position is being the trust infrastructure layer — the thing that moves a newcomer from unknown applicant to credible applicant. Listings are the distribution mechanism. Trust is the product.

The YC “brick”. The hair on fire is being invisible to landlords. The brick that lands squarely on it is a professional, structured, landlord-readable document that pre-empts every objection a landlord has about a newcomer, delivered in a one-tap application flow. Everything in AkiPath exists to deliver that brick.

I designed the system as three interconnected layers.

Left to right: intake wizard, listing results, application review.

The full journey, from first open to sent application, was designed around one principle: the user should feel increasing confidence at every step, never anxiety. The wizard asks for more as the user gets more comfortable. Results show value before asking for anything. The Apply screen leads with strength signals before it asks for payment.

As product lead I made the key architectural calls and authored the specifications that drove implementation.

• Supabase — database, auth, RLS, pg_cron
• GPT-4o-mini — cover letter generation
• Resend — email relay with PDF attachment
• Apify — nightly Kijiji + Zumper scrape, 03:15 ET

Database design. A 30+ column profiles table with branching financial fields. A separate sent_applications table — not unique on user + listing, so reapplication is possible. saved_listings with a unique constraint. RLS policies scoped so landlord contact details never appear in public reads; they are revealed only through an authenticated action.

Listing pipeline. A nightly Apify cron scraping Kijiji and Zumper, upserting on unique(source, external_id), with Nominatim geocoding at scrape time. Three-pass fallback matching: budget + bedrooms + distance, then no filters sorted by price, then absolute cheapest active. A $500–$8,000 price gate filters out for-sale listings that bleed through.

Auth architecture. AuthGate holds session state with a synchronous clear on SIGNED_OUT and on any uid change. isPaid derives exclusively from the database profile row, never from local state. That fixed a session isolation bug where a previous user's profile persisted into a new sign-in — a race between async profile fetches and session changes.

Refactor decision. After three months of feature accumulation, Index.tsx had grown to 279 lines owning wizard state, the auth listener, results routing, the payment modal and KPI timestamps at once. I planned and executed the split into WizardFlow, ResultsScreen, AuthGate and fromWizard, and deleted seven dead chat-era components. The build stayed green throughout.

KPI 1 measures how quickly users move from signup to actively pursuing a landlord — proof that the profile-building flow creates immediate action. KPI 2 is the primary validation of the core hypothesis: seven days after a send, the system asks the tenant whether the landlord responded (Yes / No / Still waiting). Does a professionally packaged application change landlord behaviour?

Supporting signals tracked: profile_status progression, is_paid conversion rate once Stripe is live, advance payment offer selection rate and guarantor inclusion rate.

Commission the landlord insight earlier. The direct landlord interview — which surfaced the advance rent signal, the non-payment fear and the desire for fast matching — happened late. Those insights would have shaped the Application Strength Score weights and the guarantor flow earlier and more precisely.

Validate willingness to pay before building the paywall. I built the full $39/quarter flow before running a single concierge-style paid test. A two-week manual “done-for-you” application service at $99, with no product at all, would have confirmed price tolerance faster and generated real landlord response data at the same time.

Cut the AI chat interface two weeks earlier. Conversational intake was the right instinct and the wrong implementation for the data quality a matching engine needs. The signal was there in week two. I held on for another week hoping prompt engineering would fix a structural problem.