HospiHealth is a full-stack site for a hospital consulting firm: a founder-story page, a structured job-application portal, and a custom admin dashboard, shipped from brief to live in eight weeks. The founder had significant expertise; the digital footprint hid it entirely. These are the three calls that defined the build and the one scope cut we made in week one.
The brief was simple: build a site. What we heard underneath it was different. The founder was competing for hospital consulting contracts — procurement teams and healthcare networks were Googling them, landing on something that did not match the CV, and moving on. The problem was not the absence of a site. It was that the existing presence was working against credibility rather than for it.
What did the build actually need to be?
Three surfaces. Not four, not six.
- Founder-story page — not a bio, a track record. Hospital consultants get hired because of specific domain expertise. The page needed to answer "why trust this person with our operations" in the first screen, not bury the answer in a timeline.
- Jobs portal — healthcare consulting firms hire. "Email your CV to hq@..." is a signal that the firm has not operationalised its own process. A structured intake, with defined fields and a document upload, signals the opposite.
- Custom admin — for the founder to manage job postings, review applications, and track the pipeline without a spreadsheet.
We turned that list into a spec in week one. We also removed one thing from the original brief.
What did we cut, and why?
The first instinct — the founder's and ours — was a job-board marketplace. Public listings, candidate-facing profiles, a matching interface. It reads well on a brief.
We cut it in week one.
Here is the math: a marketplace requires two-sided volume to be useful. A new consulting firm has one employer and no candidate base yet. A marketplace with five listings and zero candidate profiles reads as abandoned — which is worse than a clean intake form. We built the data structure to support marketplace features later. We shipped the intake form now.
The cut saved six weeks and shipped a product the founder could use on day one.
Why custom admin instead of a SaaS tool?
The founder asked about Notion or Airtable for managing applications. We declined.
Healthcare consulting involves document-sensitive data: CVs that reference named hospitals, sometimes salary information tied to specific facilities, referrals to named individuals. Dropping that through a third-party workspace with unclear data residency adds compliance risk no consulting firm in healthcare should take voluntarily. A custom admin took two weeks to build and removed the conversation permanently. Every application submission routes to a private system the founder owns and controls.
The build cost of the custom admin was lower than the compliance conversation that follows a data residency incident.
What was the hardest part of the build?
The founder-story page.
We treated it as a standard About page in week one: credentials, education, tenure, achievements. It listed. After the first review call, we rewrote it from scratch.
The question the page needed to answer was not "who is this person" but "why should this hospital trust this person with our operational problem." The rewrite was shorter, not longer, and took a day once we had the right frame.
The lesson: for any professional-services build, write the positioning question before the first wireframe. "What does this page need to prove?" should be a written sentence in the scope document. When it is not, you find it in the first review call and spend a week resetting.
What shipped at launch?
A live site with the founder's track record framed as an argument. A jobs section with structured intake and document upload. A custom admin where applications land, searchable and exportable. The founder sent the URL to two hospital networks the week it went live.
The jobs portal has since accumulated forty-three applications across three posted roles, all managed through the admin without a spreadsheet or a third-party tool.
What would we do differently?
One thing: the positioning conversation should happen before the first wireframe, not after.
We ran a standard kickoff — goals, audience, surfaces — and started wireframing the founder story page before we had agreed on what it needed to prove. The rewrite in week two was not expensive in hours. It was expensive in the frame it set for the rest of the build: the first week's design was calibrated for the wrong problem.
The fix is straightforward. Before wireframing any professional-services site, write one sentence: "This page needs to convince [audience] of [claim]." If that sentence takes more than fifteen minutes to agree on, the scope conversation is not over.
The scope decisions that held through this build — marketplace out, custom admin in, founder story rewritten to an argument — follow the same logic we apply on every project. The twelve questions to ask before hiring any dev shop include the scope conversation, and the marketplace cut above is what that conversation looks like when it goes right.
Written 2026-07-18 by Naman Barkiya.