SDUAHER Students: A Health-Tech Appointment Booking App as a Full Stack Internship Project

Yes, a clinic appointment booking app is a strong full stack internship project for SDUAHER students, provided you keep it small and use only dummy patient data. In 14 days you can ship a React front end, a REST API and a database that let a patient pick a doctor and slot, and let a receptionist see and manage the day’s bookings. The privacy habits you practise along the way matter as much as the code.

This guide gives you a scope-and-features worksheet, a day-by-day plan, a data model, an endpoint list, a double-booking worked example and a privacy checklist you can reuse.

Why an appointment booking app suits a two-week full stack project

Booking is a compact problem that still touches every layer of a web stack. You need forms and validation on the front end, routes and business rules in the API, and relational data with real constraints in the database. It also has one genuinely interesting rule: two patients must never get the same slot.

It also has a built-in story for a portfolio. Health-tech is a domain where an interviewer will ask how you handled sensitive data, and you will have a concrete answer: you never used real data, you minimised what you stored, and you wrote down the rules.

If you want a structured place to do this, the free two-week online internship from CareerSwami runs for 14 days and includes a free offer letter and a free completion certificate after successful completion. It is an independent programme, and this article is an independent guide for students; it is not connected to SDUAHER.

Scope-and-features worksheet for the clinic booking app

Fill this in on Day 1 before writing any code. The aim is to sort every idea into “must”, “should” or “later” so that you finish a working product instead of half of a large one.

Add three more columns for your own copy: “Acceptance test” (one sentence describing how you will know it works), “Risk” and “Done on day”. A feature without an acceptance test is not scoped yet.

Questions to answer in writing before you start

• Is this a single-clinic app or multi-clinic? Choose single-clinic.
• How long is one appointment slot? Fix it at 15 or 30 minutes for the whole app.
• What are the clinic hours and which days are closed? Hard-code these as configuration first.
• What is the minimum patient detail needed to book? A display name and a dummy phone number is enough.
• Who can see the list of bookings? Only the receptionist role.

Dummy patient data rules for a health-tech practice project

Treat the project as if it were real, but never let real information near it. Real patient names, phone numbers, Aadhaar numbers, diagnoses or photos do not belong in a student repository, a screenshot or a demo video.

• Generate fake patients with obviously fictional names such as “Test Patient 01” and phone numbers like 9000000001 to 9000000020.
• Do not use the names or details of friends, family, classmates, faculty or real doctors. Use “Dr. Sample Physician” style labels.
• Write one seed script that creates all dummy data, so anyone can wipe and rebuild the database.
• Keep reason-for-visit as a short list of generic options (for example “General check-up”, “Follow-up”) rather than free text, which invites people to type real symptoms.
• Add a visible banner in the UI: “Demo only. Do not enter real personal or medical information.”

Architecture: React front end, REST API and a relational database

Keep the stack boring and well documented. A reasonable choice is React with Vite, Node.js with Express, and PostgreSQL or MySQL. SQLite is fine for a first version because it needs no server, and the schema carries over. Use whichever you already know; the learning is in the design, not the brand.

1. React client: pages for doctor list, slot picker, booking form, confirmation and the receptionist day view.
2. REST API: JSON endpoints that validate input and enforce business rules.
3. Database: tables for doctors, patients, appointments and users, with constraints that protect the rules even if the API has a bug.

Data model

REST endpoints

Worked example: stopping two patients from booking the same slot

This is an illustrative design walk-through, not output from a tested run. Suppose two dummy patients, “Test Patient 01” and “Test Patient 02”, both open the 10:30 slot for “Dr. Sample Physician” and press Book within the same second.

A naive API first checks “is the slot free?” and then inserts. Both requests can pass the check before either inserts, and you end up with two bookings. The fix is to let the database be the final judge.

1. Create a unique index on active appointments for the pair (doctor_id, slot_start). In PostgreSQL this can be a partial unique index where status is “booked”; in other databases, a unique constraint plus deleting or re-marking cancelled rows works.
2. In the API, attempt the insert directly and catch the unique-violation error.
3. If the insert succeeds, return 201 with the appointment. If it fails because of the constraint, return 409 with a plain message such as “That slot was just taken. Please choose another.”
4. In React, handle 409 by refreshing the slot list and showing the message, instead of a generic error.

A sketch of the idea in pseudo-code:

POST /api/appointments
  validate doctorId, slotStart, displayName, phone
  try:
    insert into appointments (doctor_id, patient_id, slot_start, status)
  catch unique_violation:
    return 409 "Slot already booked"
  return 201 appointment

Write a test for it: fire two simultaneous POST requests for the same slot and assert that exactly one returns 201 and the other 409. Run it yourself and record the real result in your README.

14-day build plan for the booking app

If you fall behind, cut “Cancel” and the login polish first. Never cut double-booking protection or the privacy checklist.

Privacy and security checklist for a clinic app handling dummy data

Use this as a pass or fail list on Day 12. Each item should have a short note in your README showing what you did.

SDUAHER and a Clinic Appointment App: Where a Software Project Fits

Sri Devaraj Urs Academy of Higher Education and Research is a Deemed to be University at Tamaka, Kolar, Karnataka. Its governance page states that it was declared under Section 3 of the UGC Act, 1956, by an MHRD notification dated 25 May 2007, and that it is sponsored by the Sri Devaraj Urs Educational Trust for Backward Classes. The campus is about 5 km from Kolar town.

The same site organises its programmes into faculties such as Medicine, Allied Health, Nursing, Pharmacy and Physiotherapy, plus a School of Law. No dedicated software or computing faculty is listed there, so a full stack project like an appointment booking app is usually a self-directed or externally arranged build rather than a university-prescribed internship. The practical consequence is that students should agree the scope with a department or mentor before starting, instead of assuming a standard scheme exists.

The value-added courses page states a minimum of 16 hours for such courses, and lists titles such as Artificial Intelligence in Ocular Disorder and Essential Tools in Research. These are not software internships, but they show how the institution documents extra learning. A health-tech project is stronger when it respects patient privacy: use dummy data only, and never real patient records.

Steps to confirm before building

• Ask the office whether a software project can be recorded as part of your programme, and in what form.
• Identify a faculty member willing to mentor and review the project.
• Confirm the data rules: dummy patient data only, with no real clinic records.
• Ask whether the hospital or department needs to approve any demo to clinic staff.
• Check the current academic calendar for periods suited to project work.

Presenting the finished project in your README and demo

• Problem statement: two sentences on the booking problem and who it serves.
• Screenshots: three to five, using fictional data only.
• Setup steps: clone, install, configure .env, run the seed script, start the server and client.
• API table: the endpoint list above, kept up to date.
• Design decisions: why the unique index exists, why you excluded medical details.
• Test evidence: the actual outcome of your double-booking test, and anything that failed.
• Limitations and next steps: reminders, payments, audit logs and a compliance review.

Frequently Asked Questions

Can I use real patient or clinic data to make the booking app more realistic?

No. Use only fictional names, numbers and doctors. Real data creates privacy risk, and it is unnecessary for demonstrating full stack skills. A seed script with believable fake records is enough.

Which database should I pick for a clinic appointment project?

PostgreSQL or MySQL are good choices because they support constraints that prevent double booking. SQLite is acceptable for a quick start. Choose the one you can set up and explain confidently.

Do I need user accounts for patients?

Not for a 14-day scope. Let patients book with a display name and dummy phone, and reserve login for the receptionist. Patient accounts can be listed as future work.

How do I handle time zones and slot times?

Store slot times in a consistent form, such as UTC timestamps, and convert to Indian Standard Time in the interface. Alternatively, keep a single clinic-local time for the whole demo and document that choice.

Will this project count for academic credit at my university as a Sri Devraj Urs Academy of Higher Education and Research student?

That cannot be assumed. Ask your department in writing whether a self-directed online internship can be recognised, and in what form. CareerSwami’s programme provides a free offer letter and a free completion certificate after successful completion, but no academic credit.

What should I test first if time is short?

Test the double-booking rule, input validation on the booking endpoint and the access check on the receptionist view. These are the places where a bug does the most damage.

Is this project enough to apply for full stack roles?

It is a solid portfolio piece, but it does not guarantee interviews or jobs. It becomes stronger with a clear README, tests, a short demo and honest notes about limitations.

How do I keep the scope from growing during the two weeks?

Return to your worksheet. Any new idea goes into the “Later” list unless it replaces something in “Must” or “Should” with the same effort. Freeze scope by the end of Day 7.

Related Full Stack Web Development guides

• Assam Rajiv Gandhi University of Co-operative Management: Full Stack Project for Co-op Societies
• Sant Gahira Guru Vishwavidyalaya Students: A Weekly Daily-Log Format for Web Dev Interns
• Mahatma Gandhi Udyanikee Evam Vanikee Vishwavidyalaya: Agri-Marketplace Full Stack Internship Plan
• All Full Stack Web Development internship guides