LF Patient

LF Patient helps health sciences students find patients for supervised care, while giving everyone a clearer, safer platform to discover services and express interest.

Comment

Inspiration

Across the Philippines, every year thousands of health sciences students often rely on Facebook groups, group chats, and personal networks to find patients for supervised care for coursework, academic, and graduation requirements. These posts can reach many people, but important details are often scattered across captions, images, comments, and direct messages.

Patients browsing these opportunities may not immediately know the school, service, location, number of visits, cost, schedule, or worse, if a student is actually posting and if their requirements are legitimate.

I built LF Patient to keep the reach of social sharing while giving students and patients a clearer, safer platform to connect. It sits at the awkward gap between an informal “looking for patients” post and a trustworthy public platform: clearer facts, visible care boundaries, and one page and link that is easy to share.

What it does

LF Patient is a Philippines-focused* marketplace for supervised care offered through Dental Hygiene and Dental Medicine* students.

*as a pilot and can expand to other countries and medical fields.

Students can:

  • Create and verify their student profile
  • Publish clear listings with care details, photos, location, schedule, and costs
  • Preview and share listings across social media, group chats, and direct messages
  • Privately manage patient responses for each listing

School email verification confirms control of that email address. It does not claim school endorsement, enrollment status, identity verification, or clinical eligibility.

Patients can:

  • Browse and search listings without creating an account
  • Compare clear care details and listing photos
  • Share listings with someone who may need them
  • Express interest privately through their preferred contact methods

LF Patient does not request diagnoses, symptoms, medication details, insurance information, or medical history. Patient contact details are visible only to the student who owns the listing.

Fill with AI

Students may already have a Facebook post, caption, or screenshot containing the information they want to publish.

LF Patient includes an optional Fill with AI workflow that turns this existing material (text or image) into structured field suggestions. It shows what information was found, what is missing, and which values came from the source.

AI suggestions are never applied automatically. Students must explicitly review and apply them, and the system never publishes a listing without human confirmation.

The manual listing form remains fully usable should a student prefer to fill in details on their own.

How I built it (with AI)

The frontend uses React, TypeScript, and Vinext on Cloudflare Pages. A Node.js API and PostgreSQL database run on Graylabs behind nginx and Cloudflare.

The application uses:

  • secure HttpOnly sessions;
  • authenticated encryption for private contact details;
  • strict Origin and CORS validation;
  • persistent rate limits;
  • owner-only access to patient responses;
  • server-side publication checks; and
  • one narrow public data model shared by marketplace cards, listing pages, social metadata, and sharing copy.

The API checks listing images, removes their metadata, resizes them, and converts them to WebP before storage.

The database and private development email service have no public listener. Cloudflare protects the API with hostname-scoped Strict TLS.

How I used Codex and GPT-5.6

I used Codex as the primary environment for product exploration, implementation, security review, testing, deployment preparation, and documentation.

GPT-5.6 through Codex helped me:

  • compare six initial product ideas through adversarial validation;
  • study real student patient-recruitment patterns;
  • define privacy, verification, and publication boundaries;
  • coordinate bounded implementation, review, and QA work across agents and coding models;
  • find security, interaction, and product-copy problems;
  • validate responsive behavior on desktop and at 390px and 360px widths;
  • align the application, infrastructure, and submission materials; and
  • generate and refine the product images, logo, favicon, and submission assets.

The main Codex agent coordinated the build, reviewed agent output, and ran acceptance checks. GPT-5.6 agents handled bounded implementation and independent review work. I made the final product, safety, design, and publication decisions.

Challenges

Building trust without implying endorsement

A school email can confirm control of a mailbox, but it cannot prove enrollment, identity, school approval, or suitability for a procedure. The verification language had to remain useful without overstating what was verified.

Protecting patients without adding friction

Patients should be able to respond easily, but their contact details should not become public. LF Patient keeps browsing open while keeping responses private and restricting them to the listing owner.

Turning scattered posts into clear information

Real posts may combine captions, posters, screenshots, comments, and direct-message instructions. The structured form had to support these details without becoming overwhelming.

Keeping AI assistive

Automatically completing or publishing listings would create avoidable risks. LF Patient keeps AI optional, source-aware, reviewable, and unable to publish.

Hitting usage limits

I have repeatedly hit AI usage limits during this build and have had to use my banked resets. Nonetheless the credits, generous usage limits, and almost daily resets have helped me a lot in this aspect.

Accomplishments

  • Built a working student-to-patient marketplace backed by PostgreSQL.
  • Published responsive patient and student experiences.
  • Added searchable service and Philippine location discovery.
  • Created shareable listing pages with dynamic social metadata.
  • Added public listing photos with server-side image processing.
  • Protected patient contact details with encryption and owner-only access.
  • Added structured student profiles and school-email verification.
  • Validated the application through automated tests and desktop and mobile browser QA.
  • Deployed the frontend and API behind Cloudflare.

What I learned

AI can greatly reduce the cost of researching, designing, implementing, testing, and reviewing a product. It does not remove the founder's responsibility to define what the product should do and where its boundaries should remain. Most importantly, it depends on me to direct the product shape and making product decisions.

LF Patient became stronger each time I removed unnecessary scope: no medical intake, no automatic publishing, no public patient contact information, no school-endorsement claim, and no misleading AI confidence claims.

What's next

  • launch with a focused Philippine student community;
  • gain market acceptance and position LF Patient as the go-to in this niche space;
  • expand carefully into additional health sciences disciplines;
  • add production email delivery for student verification (e.g. edu, university provided emails);
  • evaluate screenshot-assisted extraction using enrollment evidence;
  • add monitoring and encrypted off-site backups;
  • explore partnership/B2B possibilities with colleges and/or universities;
  • expand product scope so LF Patient remains useful even after a student has graduated (e.g. verified reviews, student portfolio export, etc.); and,
  • understand market usage and reaction in order to inform next product decisions/priorities.

Built With

Share this project:

Updates