The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
A self-directed learning project exploring full-stack AI integration for a HealthTech scenario — the user enters symptoms, the backend calls an AI provider through a swappable abstraction, and returns triage guidance. Built to study the Facade and provider-abstraction patterns.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Pawline: booking built around the van, for mobile pet groomers
Pawline is a booking system for a small mobile pet grooming business: one van, two groomers, three Austin zones.
Most booking tools treat a mobile groomer like a salon. The real problem is logistics: travel fees by zone, visits with several pets that take different amounts of time, and one van that can't be double-booked.
What it does:
🐾 ZIP check with instant zone travel fees
🐾 Live pricing and visit length for up to 4 pets, including add-ons and setup time
🐾 Only shows time slots the van can actually fit, and respects the owner's blocked time
🐾 Private links so customers can reschedule or cancel without an account
🐾 Owner dashboard with a daily van timeline
🐾 Public demo mode with fictional bookings and hidden customer details
Built for real use: owner-only data access, leaked-password protection, and full end-to-end testing on desktop and mobile.
Try the owner demo: Owner → "Try the demo dashboard"
Live: https://pawline-grooming-app.lovable.app
Designing around travel zones instead of a salon schedule is the right call. The demo mode is a nice touch for people testing it.
DJ LUVABLE 🪩
What does a good booking flow look like for both sides?
For the Contra × Lovable challenge, I became DJ Luvable, a wedding and art-venue DJ from a parallel universe, and built his site with Lovable to find out.
FOR THE CLIENT
✦ Every package, inclusion and deposit shown upfront
✦ Reels and playlists to check the style before booking
✦ Lulu, a voice assistant built with VAPI, for anyone who'd rather talk than type
FOR THE DJ
✦ Availability synced with Google Calendar, so no double bookings
✦ Fewer "quick question" emails
✦ Enquiries that arrive with everything already filled in
Also made with AI: two moody reels, two music sets and 3D character illustrations.
The (very real) testimonial of the week: “I’m giving him five out of five disco balls! 🪩🪩🪩🪩🪩”
The behind-the-scenes footage starts at around 2:00 in the demo video.
You spend an hour getting a feature working with an AI. The code looks fine in the pull request. Variable names make sense. Error handling is there. Types check out. You approve it. It goes live. Then it crashes because a webhook sent a null user_id something that "should never happen."
Here is the problem. AI code reads well because the examples it learned from are all clean and perfect. It falls apart in real situations. The model doesn't know your system.
Two things it misses:
It only knows the success case. The model writes code for when everything works. Every tutorial shows the success case. It doesn't write code for when the request gets cut off halfway. That never appears in examples. It only appears in your logs at 2 AM.
Assumptions you can't see. The code assumes the payment API returns "status: ok". It assumes the cache has data. It assumes the list isn't empty. These look like normal defaults. But in your system, the payment API returns "data.status: succeeded" on success. On timeout it throws a 500 with HTML garbage.
How to catch this:
Test the empty case first. Send nothing. Send an empty array. Leave out the header. Use an expired token. The happy path works in the demo. The empty path breaks in production.
Then read the code and ask: what does this assume is true? Not what it does what it assumes. The API format. The data shape. The timing. The permissions. The timezone. Check each one against your actual system. Not the one the model imagined.
The code isn't bad. It was written for a perfect world. Your world isn't perfect. The review that matters happens in your codebase with your data. Not in the chat where the code was written.
That null user_id crash really highlights how AI generated code can miss the edge cases hidden in real logs.