Inside this chapter7 sections · About 4 min including detail
Cofounders
The founders own the buyer relationship and the first pilot.
Giles-Evan Mboumi
CEO and cofounder
My aunt is a nurse. She was fully qualified and still got stuck waiting on paperwork. That is where this started for me.
Before Rōvn, I built BOVYN, a Python trading product used by more than 200 paying traders. It reached about $10K in monthly revenue at its peak.
From 2023 to 2026 I carried a Florida territory selling cardiovascular drugs to physicians for Boehringer Ingelheim. Rōvn brings that experience with healthcare buyers together with building and selling software.
Source: Giles, self-reported, October 1, 2026.
Christian Montgomery
Cofounder
Before Rōvn, Christian worked on new-hire onboarding: accounts, access, devices and day-one preparation. He leads sales to healthcare operators and plans to run the first pilot, from the agreed scope and baseline through the operating review.
Engineering and product
Four builders with distinct responsibilities.
Krishna
Shared backend
Works on the backend that the facility side and the clinician side share.
Anish Nayak
Agents
Builds the agent systems for authorized administrative work.
Arju Singh
Facility frontend
Builds the facility workflow and its frontend.
Jerry Kou
Design and frontend
Leads product design and builds frontend surfaces.
Capabilities added with this round · plan
The next capacity to add is deployment.
The round is intended to add security assurance, facility deployment capacity, enterprise sales and growth as pilots begin.
Founders retain the first buyer conversations and pilot ownership. Further hiring and specialist support follow the approved operating plan.
Current team roles and founder backgrounds: company record, October 1, 2026. Planned capabilities are not represented as current hires or signed advisors.
Connect the team’s work to one facility outcome.
The six-person team spans the buyer relationship, shared backend, agent behavior, facility interface and product design. The next challenge is integration: making those responsibilities converge on work a facility can accept, with the clinician’s experience and permissions intact.
The founders’ proposed pilot role is to carry the customer’s actual workflow into the build: requirements, owners, evidence routes, constraints and the baseline. The backend must preserve identity, state and evidence across the two sides. Agent work must respect the allowed task and recover from failures. The interfaces must make the next requirement, supporting evidence and reserved human decision understandable.
Product design matters operationally. If a coordinator cannot distinguish “document received” from “source checked,” a polished screen can still create a wrong handoff. If the clinician cannot understand or correct a request, the facility inherits more rework. Design and engineering therefore need to review the same complete case.
Review the work across its boundaries.
The proposed delivery method uses an end-to-end case as the unit of integration. A change is examined where it affects evidence, permission, task ownership and the destination. It is incomplete if the interface works but the record cannot explain what happened.
Customer understanding
The facility owners confirm the operating map and unresolved questions. Sales language cannot silently become an implementation requirement or an assurance claim.
Product acceptance
Review the normal path alongside stale evidence, conflicting identities, revoked access, duplicate work and interrupted writes. A meaningful result includes exercised recovery.
Operating acceptance
The recipient accepts the work in the agreed destination and the named person makes any reserved decision. Internal completion is not the end of the customer workflow.
Economic acceptance
Include customer time, clinician time and Rōvn support. The team needs to see when an apparent automation gain merely moves work to someone else.
This is the operating discipline we intend to demonstrate through the first pilot. It is not presented as a history of successful customer deployments.
Add capacity against the next proven bottleneck.
Security assurance and facility implementation require capabilities beyond writing product code. Enterprise selling requires procurement and stakeholder work beyond an interested introduction. Those needs inform the planned use of capital without implying that every role has already been hired.
Before widening the customer cohort, the founders need a realistic account of concurrent deployments, support requirements and who can cover an operational interruption. Repeated onboarding questions should become better configuration and documentation; decisions requiring customer authority must stay with that customer.
The hiring and specialist-support plan should follow those observed constraints. If source integration dominates implementation time, solve that bottleneck. If buyers cannot reach a procurement decision, strengthen commercial execution. If the initial product cannot be supported economically, additional sales capacity alone will not fix it.
Judge the team through the work it can show.
The founders’ backgrounds explain their starting point: healthcare buyer exposure, building a paid software product and coordinating onboarding work. The current team’s responsibilities explain how the product is being built. Neither substitutes for demonstrating the next operating milestone.
A diligence conversation should examine a complete product case, how customer learning changed it, how the team handles an exception and how responsibilities meet at a release. Company organization, commitments and supporting records belong in the appropriate confidential review; this page does not infer employment status, availability or credentials beyond the dated biographies.
