Adams Internal Medicine
Building a Solo Practice Website
from the Ground Up

Most medical practice websites fail in predictable ways. They're template sites with stock photography and generic copy. They don't tell you what insurance they accept, whether they're accepting new patients, or how long you'll wait to hear back after booking. They have no meaningful compliance infrastructure. They look the same on mobile as they look in a PDF export from a CMS. They've never been tested by anyone who uses a screen reader, a keyboard instead of a mouse, or a 4G connection in a parking lot.

Adams Internal Medicine is a solo internal medicine practice opening in Richardson, Texas in August 2026. The physician — Dr. Stamatina Adams — is a board-certified internist, University of Patras valedictorian, NIH/NIDDK postdoctoral researcher, and experienced hospitalist with training and practice across Greece, New York, Miami, and Dallas. The challenge was to build a website that represented those credentials honestly, served real patients practically, and held up to the kind of scrutiny a healthcare website should face: legal, clinical, accessibility, and security — not just aesthetic.

The result is 48 pages of original content totaling over 28,000 words, a five-step inline booking system, a 13-question FAQ, ten service landing pages, six patient intake forms, a verified patient review page, a HIPAA Notice of Privacy Practices referencing Texas Chapter 181, and a Content Security Policy with SHA-256 hash verification. It was built and audited iteratively across more than 30 build revisions.

The site needed to do everything a practice website does at launch: establish clinical credibility, confirm that the practice is accepting patients, explain what services are offered, name the insurance carriers accepted, provide the address and hours, and offer a way to book. It also needed to do what most practice websites don't: actually answer the questions patients ask, handle the edge cases (prescription refills, post-hospital follow-up, patients transferring care from another physician), and be findable on Google the day DNS was pointed.

The physician's background introduced specific requirements. International training from a Greek medical school needed to be framed as a credential pathway, not an immigration narrative. NIH postdoctoral research at NIDDK needed to be scoped precisely enough that a physician peer could verify it — not vague enough to be dismissed as credential inflation. Three languages needed to be surfaced as a patient access benefit. Community involvement with UNICEF, FLITE to FREEDOM, and the Greek Food Festival needed to appear as a real person, not a PR-polished biography.

And the site needed to open on time — before the practice was live, with a booking system that communicated clearly that appointments were requests subject to office confirmation, not confirmed bookings.

That quote, from the physician's own biography on the About page, sets the tone for everything the site needed to achieve technically. A patient reading it is evaluating whether this is someone they want to trust with their health. The website's job is to not get in the way of that evaluation — and to answer every practical question before it becomes friction that sends them to a competitor's site.

The site is a static HTML/CSS/JS build deployed on Netlify. No build step, no framework, no CMS. Every page is a handwritten HTML file. This decision was made deliberately and has specific tradeoffs: the site loads faster than anything generated at runtime, is trivially deployable anywhere that serves static files, has no dependency vulnerabilities, and requires no server-side infrastructure. The tradeoff is that content updates require editing HTML files, which became a known limitation documented in the post-launch punch list.

The CSS architecture is a patch-based system that accumulated across 30+ iterative builds. Each significant change — a mobile layout fix, an accessibility improvement, a new component — landed in its own stylesheet, then linked from all 48 pages. This approach kept individual builds targeted and low-risk (a broken stylesheet can't break an unrelated page), but produced a 63-file cascade that creates a render-blocking waterfall on first load. It's the primary technical debt item carried out of the project, flagged for post-launch consolidation into five logical files.

The nine JavaScript files each serve a specific purpose with no cross-dependencies. smart-back.js is a 282-line custom navigation memory system that records the patient's internal browsing path via sessionStorage, enabling the floating "Back" button on subpages to return to the correct referring page with scroll position restored. booking-widget.js manages the five-step inline booking flow. cookie-consent.js handles the GDPR-pattern consent banner with localStorage persistence. None of the nine files has any external dependency — there is no jQuery, no analytics tag, no chat widget SDK in the build.

The content philosophy was simple: every question a patient might have before booking should be answered on the site, in plain language, without requiring a phone call. This produced a site with more content depth than most solo practices build in their first five years — a 13-question FAQ, ten service landing pages, a dedicated page for patients transferring care from another physician, a post-hospital care page for recently discharged patients, a What to Expect page that walks through the visit experience before the patient arrives, and a page explaining the practice's refill and prescription process.

The booking flow deserves specific attention as a patient-journey design decision. The original concept was a redirect to an external booking platform. The final implementation is a five-step inline flow: reason for visit, date and time preference, contact information, insurance carrier, and a confirmation review screen. The success state — reached after submission — says exactly what happens next: "Our office will contact you within 1–2 business days by phone or email to confirm your appointment. Please remember that this request does not confirm an appointment automatically." That sentence eliminates the most common source of patient anxiety after submitting a booking form at a new practice that isn't open yet.

Healthcare website compliance is a category most developers treat as a checkbox. HIPAA Notice of Privacy Practices page: check. Cookie consent: check. Privacy Policy: check. The work done on this site goes meaningfully further than that, because the standards that apply to a Texas medical practice website are more specific than "has a privacy policy."

The single highest-impact performance decision in the project was converting 36 hero images from PNG to WebP using the proper <picture><source type="image/webp"> pattern. The original hero images totalled 53MB. The WebP conversions total 2.2MB — a 96% reduction. The homepage banner image alone went from 3.0MB to 139KB. The <picture> element provides a PNG fallback for browsers that don't support WebP, covering the 3% of users that would need it. All 106 non-LCP images use loading="lazy" and decoding="async".

Asset caching is configured in netlify.toml via Cache-Control: public, max-age=31536000, immutable on the /assets/* path. This means returning visitors never re-download a hero image, CSS file, or font. The PWA manifest and 192px/512px icons allow the site to be installed as a home screen app on iOS and Android.

The Content Security Policy was delivered via Netlify's _headers file and includes X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy restrictions on camera, microphone, and geolocation. The SHA-256 hash for the JSON-LD Schema.org block was computed and verified mathematically — a confirmed match, not an assumed one. All 69 external links in the site use rel="noopener noreferrer".

Accessibility in a healthcare context is not a regulatory checkbox. The patients who most need accessible websites are the ones most likely to be using assistive technology: older patients with low vision, patients with motor impairments who use keyboards instead of mice, patients with cognitive disabilities who depend on clear heading structure and predictable navigation. A medical practice website that isn't accessible is a medical practice that's inaccessible to some of the people who need healthcare most.

The majority of healthcare website traffic comes from mobile devices. A patient who just got a referral, or is standing outside the practice trying to confirm the address, or is in a waiting room filling out paperwork — they're on their phone. The mobile experience received more iterative revision than any other dimension of this build, because it's the experience that matters most.

The tap-to-call button enforces a 48px minimum touch target (WCAG 2.5.5), respects env(safe-area-inset-bottom) so it doesn't overlap the iPhone home indicator, hides when a form input is focused so it doesn't cover the keyboard, and collapses to an icon-plus-label format on screens narrower than 520px. That's four separate mobile considerations, all handled in one component.

The smart back button — which follows the patient as they scroll, positioned just below the fixed header — uses var(--aim-fixed-header-height), a CSS custom property set by JavaScript after measuring the actual rendered header height at runtime. This ensures the button doesn't overlap the header regardless of what the header's pixel height turns out to be on any given device.

The homepage banner, which overlays text on a hero image, required specific mobile treatment. On desktop, the text is position: absolute centered vertically over the image. On mobile, that centering breaks when the image height is constrained — the text falls outside the image or overlaps it incorrectly. The fix kept the text absolutely positioned but switched from vertical centering (top: 50%; translateY(-50%)) to bottom anchoring (inset: auto 22px 34px 22px), and switched the gradient overlay from left-to-right to top-to-bottom so the bottom of the image is dark enough for the text to read against.

A new practice that isn't findable on Google isn't findable at all. The SEO infrastructure was built to ensure that the moment DNS points to the production domain, the site is ready to be submitted to Search Console and indexed correctly.

The netlify.toml configuration includes clean URL redirects for 30+ routes so /about resolves alongside /about.html. A telehealth page that was removed during development is handled with a 301 redirect to the services page — any cached search result or shared link that pointed to that URL lands correctly rather than hitting a 404. The 404 page itself is a custom-designed error page rather than Netlify's default.

The site was evaluated iteratively across 19 distinct persona lenses — not as a marketing exercise, but as a systematic way to find the things that conventional QA misses. A security audit catches technical vulnerabilities. A Mom Test catches the things that are technically correct but practically confusing to a 61-year-old in Plano who found the site through a Facebook group recommendation. Both matter.

Three of the 19 lenses were developed specifically for this project and not used in standard web development audits:

The three new lenses developed for this project — Google, Patient in Crisis, and Five Years Later — each revealed a category of issue that conventional audits don't surface. The Google lens identified the absence of Schema.org structured data, which was added as a pre-launch fix. The Patient in Crisis lens confirmed that the site serves frightened and recently-diagnosed patients adequately through the post-hospital care page, the booking urgency field, and the 911 guidance on the contact page. The Five Years Later lens produced the most actionable long-term punch list: the opening date copy that needs to come down on August 20, the 63-file CSS architecture that will be difficult to maintain without the original developer, and the absence of a CMS that will result in stale content within 12–18 months if not addressed.

The site scores 96 across 19 lenses. The four points off are the CSS file consolidation (63 files is functional but architecturally fragile), the homepage title tag truncating at 78 characters in Google search results, the night mode implementation that was built and deferred, and the absence of a CMS for long-term content maintainability. None of these prevent launch. All of them are known and documented.

What the score reflects is a site where every patient-facing interaction works correctly — the booking form sends a request, the FAQ answers the questions patients actually ask, the contact form states response time expectations, the insurance page names the carriers a patient would recognize, and the physician's biography sounds like someone a patient would want to meet. Those are the things that determine whether a website converts a visitor into a booked appointment. Technical correctness is the foundation. Patient trust is what's built on it.