Project Info
Inspiration
Healthcare is one of the biggest financial and logistical burdens in the United States. One of our teammates had a mother battling cancer and a complex blood clotting condition. The total cost of her hospital-based care, including chemotherapy, accumulated to $1.7 million, causing the family to lose their home at a young age. This is an unfortunate reality for many families in the US. Through hospital-at-home care, she was able to receive the same treatments at home safely and effectively, reducing costs to $200,000 even without insurance by eliminating unnecessary hospital stays and administrative fees, while reserving hospital resources for the most invasive and emergency cases. This experience showed us that hospital-level care does not always require a hospital. We were inspired by the growing "hospital-at-home" movement and real-world examples showing that treatments such as IV therapy, chronic disease management, and chemotherapy can be safely delivered at home at a fraction of the cost. tIt inspired us to create CareBnb, a platform that makes home-based care safe, affordable, and accessible, with the potential to change the future of healthcare. Healthcare in the United States is expensive, fragmented, and often inaccessible. Many patients delay or avoid care due to cost, transportation barriers, or fear of hospitals. For families dealing with chronic illness or cancer, repeated hospital visits can be financially, physically, and emotionally exhausting. The problems CareBnb solves Astronomical Healthcare Costs: Facility fees, fragmented billing, and administrative overhead inflate costs. CareBnb reduces costs by eliminating unnecessary hospital stays, middleman fees, and administrative complexity, saving patients hundreds of thousands of dollars. Rural and Underserved Inequity: Patients far from hospitals struggle to access care. CareBnb delivers home visits to bridge geographic inequities. Hospital Overload and Burnout: By shifting non-acute cases to the home, we free up hospital resources for ICU, emergency surgery, and neonatology while reducing provider fatigue. Patient Comfort and Independence: We replace stressful hospital environments with the safety of home, preventing the functional and cognitive decline often seen in hospitalized elderly patients.
What it does
CareBnb makes hospital-level care available in the comfort of your home. Patients can book nurses, caregivers, or specialists for home visits, while clinicians use the platform to manage and deliver care efficiently. Our AI-powered voice copilot records intake calls, extracts symptoms, medications, allergies, and vitals, and generates structured clinical notes, care timelines, and safety alerts, reducing administrative burden. CareBnb supports preventive care, chronic disease management, chemotherapy, post-operative care, and more… all delivered at home. By combining patient-centered design, AI, and home-based care, CareBnb makes healthcare more affordable, accessible, and dignified. We envision a future where the hospital isn’t a building… It's your home.
How we built it
CareBnb is a full-stack, location-aware healthcare platform built for speed, scalability, and real-world clinical workflows. The frontend is a React single-page application served through Next.js, providing booking with dynamic routing and real-time data. The backend uses Next.js API routes for authentication, provider matching, booking creation, and care request management. We use Supabase (PostgreSQL) for secure relational data and built-in authentication via Supabase Auth. Geographic matching is powered by PostGIS, enabling radius-based and distance-ranked queries. Custom SQL functions such as match_providers and match_requests calculate proximity and sort results by distance, provider rating, and completed visits. Patients can search for care by service, time, and location, then complete a structured booking flow that confirms service details, collects intake data, and generates a booking tied to both patient and provider accounts. Providers have a dashboard to register their role, list services, set locations, confirm bookings, mark visits complete, and browse nearby open requests. Our AI-powered intake pipeline supports clinical documentation. Voice or audio input is converted to text, and key medical entities, symptoms, medications, allergies, and duration, are extracted into structured fields. The system generates organized notes and flags potential safety concerns to help providers prepare. The database core includes tables for providers, patients, bookings, and care requests, connected via foreign keys and managed with Supabase migrations. For testing, we seeded the system with multiple providers and open requests in San Francisco, enabling full end-to-end workflows: discovery, matching, booking, intake processing, provider confirmation, and completion.
Challenges we ran into
The most complex challenge was integrating all parts of the system into one seamless workflow. We had a React frontend, Next.js API backend, a Supabase database, and multiple AI intake components. Ensuring that patient searches, bookings, intake data, and provider actions all communicated correctly across these layers required significant debugging and coordination. Another major challenge was setting up the AI intake pipeline itself. We combined speech-to-text, symptom extraction, and structured note generation into a single process. Getting these models to work reliably together, and then connecting their outputs to the booking and provider systems, took careful testing within the hackathon timeframe. Scope control was also important. It was tempting to build a full healthcare platform with insurance billing, credentialing, and complex scheduling. Instead, we focused on a clear MVP that demonstrated the core value: matching patients with at-home providers and automating intake. Finally, healthcare is inherently complex, with licensing, regulation, insurance, and highly variable pricing depending on location and provider. Since this was an MVP, we designed features that felt medically credible and easy to understand, while leaving deeper regulatory and billing integrations for future development.
Accomplishments we're proud of
Our greatest accomplishment was the team itself. In just one weekend, two Cornell undergraduates, a Cornell Tech student in New York City, and a Stanford student studying computer science, biomedical engineering, and medicine came together to build a technically ambitious solution. Despite our different backgrounds and locations, we were united by a shared entrepreneurial mindset and a focus on one of healthcare’s most pressing challenges: cost. We designed a system aimed at reducing healthcare expenses while improving the patient experience, demonstrating that care can be delivered more efficiently without sacrificing human-centered design. We are especially proud of how far we pushed ourselves outside our comfort zones. We deliberately chose a complex problem at the intersection of healthcare, AI, and full-stack development. Over the course of the weekend, we stayed late troubleshooting integration issues, debugging AI pipelines, and learning firsthand how challenging it is to properly implement and orchestrate AI systems. At the same time, we experienced how powerful AI can be when used thoughtfully to accelerate development. Beyond the product itself, we’re proud of the growth that came from the process. We learned how to ship quickly, divide responsibilities strategically, communicate clearly, and build something meaningful under pressure. We also valued connecting with other builders working on similar technologies and contributing to a broader innovation community. More than just a prototype, we built momentum, technical confidence, and a shared vision for what healthcare technology can become. Last but not least, we shared plenty of jokes along the way. We set out to reduce hospital visits, and by the end of the weekend, we all agreed we might need one ourselves: four young, caffeine-powered builders pushing the limits.
What we learned
Many hospital visits are preventable or could be safely managed at home. Despite this, only about 3% of healthcare spending goes toward preventive care. We realized that hospitals are essential for invasive procedures, but for many acute conditions, at-home care can be a better, more patient-centered option. We also learned that the biggest cost drivers in healthcare are infrastructure and complications, not just treatments themselves. AI can play a transformative role by reducing administrative burdens and improving patient safety, but it must be implemented thoughtfully. Finally and importantly, connecting AI tools, coordinating care, and building a system that is both usable and reliable requires careful planning, collaboration, and focus on the core problems.
What's next
for CareBnb We are launching a pilot program in a focused region, starting with oncology and chemotherapy. This will let us work closely with clinicians, refine the platform, and ensure care is safe, personal, and effective. We are enhancing our technology with AI chatbots, helpful agents, and a friendly avatar to guide patients, while expanding our network of clinicians and adding telehealth options for virtual consultations. We will integrate real pricing and insurance support to make care transparent and practical, allowing providers to focus on patients and patients to feel confident in their care. Our vision is for CareBnb to become the operating system for at-home healthcare, bringing high-quality, accessible, and compassionate care directly to patients' homes.
CareBnb Marketplace
A full-stack care marketplace that connects patients with care providers and lets providers find open care requests. Built with Next.js (App Router), Supabase, and PostGIS for location-based matching.
Table of contents
- Features
- Tech stack
- Prerequisites
- Setup
- Running the app
- Project structure
- Pages & routes
- API reference
- Environment variables
- Supabase configuration
- Deployment
Features
Patient side
- Find care — Search by service, date/time, and location (or “Use my location”). See a ranked list of providers (distance, rating, visits). Filter by minimum rating. “Available for similar dates” re-runs search with a shifted date.
- Provider profile — Click a provider card to view full profile (photo, role, specialties, price, next available). Book from profile or from search.
- Book — Creates a booking and sends you to the intake form (name, phone, address/notes, consent). Then a confirmation page with booking details.
- My bookings — List of your bookings with provider, service, date, status. Cancel pending/confirmed bookings. Open any booking to see details or cancel.
- Request care — Post an open care request (service, description, preferred time, location). Providers see it in “Find open requests.”
Provider side
- Register as provider — On the provider dashboard, if you’re logged in but not yet a provider, you can register (name, role, services, location). Your account is linked via
user_id. - My jobs — List of bookings where you’re the provider. Confirm pending bookings and Mark complete confirmed ones. Links to the booking confirmation page.
- Find open requests — Search by service and location to see nearby open care requests (jobs board). Use “Use my location” or default (SF area).
Auth & account
- Sign up / Log in — Email and password (Supabase Auth). Session is used for bookings (patient id) and provider profile (provider id).
- Forgot password — “Forgot password?” on login → enter email → receive reset link → Reset password page to set a new password.
- Header — When logged in: email and “Sign out.” When logged out: “Log in” and “Sign up.”
Data & backend
- Patient linkage — First time you book or post a care request while logged in, a
patientsrow is created and linked to your auth user (user_id). Future bookings use that patient. - Provider linkage — Register as provider to create a
providersrow with youruser_id. “My jobs” and provider actions (Confirm / Mark complete) use that provider.
Tech stack
| Layer | Technology |
|---|---|
| Frontend | React (Vite) app in front end/, served by Next.js at /; legacy Next.js pages in app/_legacy/ |
| Backend | Next.js API routes (/api/*), Supabase, PostGIS |
| Database | Supabase (PostgreSQL) |
| Geo | PostGIS (geography points, distance queries) |
| Auth | Supabase Auth (email/password) |
Combined setup (front end + backend)
- UI: The React/Vite app in
front end/is built topublic/spa/and served for all non-API routes (patient search, provider dashboard, etc.). - API: Next.js serves
/api/*(providers, bookings, auth, care requests). The front end calls these when running from the same origin. - Build: From project root run
npm run build:front(orcd "front end" && npm run build), thennpm run buildfor Next.js.npm run devruns Next.js only; the SPA is served from the built files inpublic/spa/.
Prerequisites
- Node.js 18+
- npm (or yarn/pnpm)
- Supabase account — supabase.com
Setup
1. Clone and install
git clone <repo-url>
cd CareBnB
npm install
2. Create a Supabase project
- Go to Supabase Dashboard and create a new project.
- Note:
- Project URL (e.g.
https://xxxxx.supabase.co) - Anon public key (Project Settings → API)
- Project URL (e.g.
3. Database: extensions and schema
In the Supabase SQL Editor:
-
Enable extensions (if not already):
CREATE EXTENSION IF NOT EXISTS postgis; CREATE EXTENSION IF NOT EXISTS pgcrypto; -
Run the main schema
Opensupabase/schema.sql, copy its entire contents, paste into the SQL Editor, and run it. This creates:- Tables:
providers,patients,care_requests,bookings - Indexes (GIST on location, GIN on services, etc.)
- RPCs:
match_providers,match_requests - Seed data (demo patient, ~12 providers near SF, 3 open care requests)
- Tables:
-
Run the auth/intake migration
Opensupabase/migrations/001_auth_and_intake.sql, copy and run it. This adds:user_idonpatientsandproviders(FK toauth.users)- Intake fields on
bookings:patient_name,patient_phone,address_notes,consent
-
Run the provider count migration (for “X providers found” to use DB total)
In Supabase Dashboard → SQL Editor, paste and run the contents ofsupabase/migrations/003_match_providers_total_count.sql. This updatesmatch_providersto return atotal_countso the patient search shows the real number of matching providers. -
Verify
In Table Editor, confirm the four tables exist. Under Database → Functions, confirmmatch_providersandmatch_requests.
Detailed checklist: supabase/README.md.
4. Environment variables
Copy the example env file and set your Supabase keys:
cp .env.example .env.local
Edit .env.local:
NEXT_PUBLIC_SUPABASE_URL=https://YOUR_PROJECT_REF.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your_anon_public_key
Running the app
- Build the front end (once, or after changing
front end/):
npm run build:front - Start the server:
npm run dev - Open http://localhost:3000. The React SPA (patient search, provider dashboard) is served at
/; backend APIs at/api/*.
- Build for production:
npm run build - Start production server:
npm run start - Lint:
npm run lint
Project structure
CareBnB/
├── app/
│ ├── layout.tsx # Root layout, header nav
│ ├── page.tsx # Home: Find care (search + provider cards)
│ ├── globals.css
│ ├── login/
│ ├── signup/
│ ├── forgot-password/
│ ├── reset-password/
│ ├── request-care/ # Post a care request
│ ├── bookings/ # My bookings (patient)
│ ├── intake/ # Intake form after Book
│ ├── booking/confirmed/ # Booking confirmation + actions
│ ├── provider/
│ │ ├── page.tsx # Provider dashboard (register, my jobs, find requests)
│ │ └── [id]/page.tsx # Provider profile
│ └── api/
│ ├── me/ # GET current user + patientId/providerId
│ ├── providers/
│ │ ├── match/ # GET match providers by service/location
│ │ ├── [id]/ # GET one provider
│ │ └── register/ # POST register as provider
│ ├── requests/match/ # GET match open care requests
│ ├── bookings/ # GET (patient or provider list), POST create
│ ├── bookings/[id]/ # GET one, PATCH (intake/cancel/confirm/complete)
│ └── care-requests/ # POST create care request
├── components/
│ └── HeaderAuth.tsx # Log in / Sign up / Sign out in header
├── lib/
│ ├── supabase.ts # Browser + server Supabase client
│ └── auth.ts # getPatientIdForUser, getProviderIdForUser, getAuthUser
├── supabase/
│ ├── schema.sql # Tables, indexes, RPCs, seed
│ ├── migrations/
│ │ └── 001_auth_and_intake.sql
│ └── README.md # SQL run checklist
├── .env.example
├── .env.local # Not committed
├── package.json
├── tailwind.config.ts
├── tsconfig.json
└── next.config.mjs
Pages & routes
| Path | Description |
|---|---|
/ | Find care: search bar (where, time, type of care, doctor name), provider cards, filter by rating, “Available for similar dates” |
/login | Log in (email/password). “Forgot password?” → /forgot-password |
/signup | Sign up (email/password) |
/forgot-password | Enter email → send reset link |
/reset-password | Set new password (landing from email link) |
/request-care | Post open care request (service, description, time, location) |
/bookings | My bookings (patient): list, cancel, link to confirmation |
/intake | Intake form when bookingId in URL (name, phone, address, consent). “Save & confirm” → confirmation |
/booking/confirmed?id=... | Booking details. Patient: Cancel. Provider: Confirm / Mark complete |
/provider | Provider dashboard: register as provider, My jobs, Find open requests |
/provider/[id] | Provider profile: photo, name, role, rating, price, specialties, “Book this provider” |
API reference
All APIs that need auth expect: Authorization: Bearer <access_token> (from supabase.auth.getSession()).
| Method | Path | Auth | Description |
|---|---|---|---|
| GET | /api/me | Optional | Returns { user, patientId, providerId } for current user |
| GET | /api/providers/match | No | Query: service, lat, lng, when?, radius?, limit?. Returns providers within radius, sorted by distance/rating |
| GET | /api/providers/[id] | No | One provider by id |
| POST | /api/providers/register | Yes | Body: name, role, services[], lat?, lng?. Creates provider linked to user |
| GET | /api/requests/match | No | Query: service, lat, lng, radius?, limit?. Returns open care requests |
| GET | /api/bookings | Optional | Query: for=provider optional. Returns bookings for current patient or provider |
| POST | /api/bookings | Optional | Body: providerId, service, when, careRequestId?. Creates booking (uses demo patient if not logged in) |
| GET | /api/bookings/[id] | No | One booking with provider details (for confirmation page) |
| PATCH | /api/bookings/[id] | Yes | Patient: patient_name, patient_phone, address_notes, consent, status: "cancelled". Provider: status: "confirmed" or "completed" |
| POST | /api/care-requests | Optional | Body: service, description?, requested_start, lat, lng. Creates open care request |
Environment variables
| Variable | Required | Description |
|---|---|---|
NEXT_PUBLIC_SUPABASE_URL | Yes | Supabase project URL |
NEXT_PUBLIC_SUPABASE_ANON_KEY | Yes | Supabase anon (public) key |
Use .env.local for local development. Do not commit secrets.
Supabase configuration
Redirect URLs (for password reset)
In Supabase Dashboard → Authentication → URL Configuration:
- Site URL: e.g.
http://localhost:3000(dev) or your production URL - Redirect URLs: Add:
http://localhost:3000/reset-password- Your production URL +
/reset-passwordwhen you deploy
Email (optional)
- Authentication → Providers → Email: You can disable “Confirm email” so signups work without verification for demos.
- Password reset emails are sent by Supabase when you call
resetPasswordForEmail.
Deployment
- Build:
npm run build - Deploy to Vercel (or another host). Set Environment Variables in the project:
NEXT_PUBLIC_SUPABASE_URLNEXT_PUBLIC_SUPABASE_ANON_KEY
- In Supabase, add your production URL (e.g.
https://your-app.vercel.app) to Redirect URLs and set Site URL if needed.
License
Private / unlicensed unless otherwise specified.
Analysis
View
Metric
- 12
- 2
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- AnthropicIn code
- CSSIn code
- HTMLIn code
- JavaScriptIn code
- Next.jsIn code
- OpenAIIn code
- PythonIn code
- ReactIn code
- SQLIn code
- SupabaseIn code
- Tailwind CSSIn code
- TypeScriptIn code
- Node.jsClaimed
- PostgreSQLClaimed
12 of 14 appear in the indexed code. 2 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
3.5 MB
Source files
202
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
SonaLily/CAREBnB_
787 files · 1268.2 MB · @ 6b7ab83
Structure
Interface
103 files · 13%Screens, components and styles rendered to the user.
+5 moreAPI & routing
27 files · 3%Request entry points: routes, handlers and controllers.
Application logic
251 files · 32%Domain rules, services and shared utilities.
+6 moreData & schema
42 files · 5%Schema definitions, migrations and data access.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- JavaScript83%
- TypeScript6%
- Python4%
- CSS3%
- Markdown2%
- SQL2%
- Other (2)0%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
front end/package.json
npm · 38- @dhiwise/component-tagger
- @radix-ui/react-slot
- @reduxjs/toolkit
- @supabase/supabase-js
- @tailwindcss/forms
- @testing-library/jest-dom
- @testing-library/react
- @testing-library/user-event
- axios
- class-variance-authority
- clsx
- d3
- date-fns
- dotenv
- framer-motion
- lucide-react
- react
- react-dom
- +20 more
package.json
npm · 14- @supabase/supabase-js
- dotenv
- next
- react
- react-dom
- +9 more
audio-model/requirements.txt
pypi · 8- anthropic
- metapub
- openai
- pandas
- PyMuPDF
- PyPDF2
- python-dotenv
- reportlab
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.