Building AI for healthcare leaves zero room for error.
I’m currently collaborating with an incredible team on Raphald AI, a medical detection application. Building the systems for a project with stakes this high is a massive reminder that the underlying backend architecture matters just as much as the machine learning model itself.
When integrating diagnostic AI, your API endpoints cannot drop requests, and your database workflows demand absolute integrity. You aren't just passing JSON payloads; you are handling critical, real-time workflows where stability is non-negotiable.
Engineering these systems continues to shape my approach to building robust Python backends. If you are developing a product that requires reliable AI integration or rock-solid FastAPI infrastructure, check out the newly updated services on my profile. Let's build something that works when it counts.
AI Home Services App — Smart Technician Booking & Repair
A premium AI-powered home services app designed to simplify how people diagnose home problems, find the right service, and book qualified technicians.
The product uses AI to turn a simple problem description into a clear service recommendation — helping users move from “What’s wrong?” → “What do I need?” → “Who can fix it?”
Key Experience
→ AI-powered problem diagnosis
→ Text, voice & photo input
→ Smart service recommendations
→ Technician discovery & booking
→ Transparent service information
→ Real-time technician tracking
→ Premium, intuitive mobile experience
The concept is designed for founders building AI home-service platforms, technician marketplaces, repair apps, and SaaS products where reducing friction and improving the booking experience can create a stronger customer journey.
Role: Product Designer
Focus: AI Product Design · UX/UI · Mobile App Design · Service Marketplace
Normal work disappears. Genuine judgment surfaces.
I built Northline Flow for @Lovable’s #lovablechallenge — a fictional owner-operated home-services business in Surrey, BC.
I didn’t want to build another prettier scheduler. The problem I wanted to attack was the handling around the booking.
Routine requests can continue toward booking. Genuine ambiguity reaches the owner as one framed decision. Unsafe or wrong-fit requests stop instead of being forced into the normal booking path.
I also built a deterministic test harness and a playable Morning Shift proof mode: three fictional requests enter the same routing rules, but only one requires a human decision.
The part I’m most excited about is that the challenge itself became reusable. We captured the process from brief → working flow → adversarial testing → cinematic donor → bounded visual integration → playable proof → final freeze.