Investor-ready prototypes and production MVPs for GRC and regulated products.
Governance, risk and compliance, healthcare, fintech and AI governance. I design for the auditor who won’t accept “trust us” and the clinician who needs Break Glass at 3am — because those constraints shape the whole product.
I'm Rajeev Karemane. I've spent fifteen years designing products in industries where a regulator, an auditor, or a clinician can reject the design for reasons that have nothing to do with how it looks.
That's the constraint I've gotten good at designing inside — enterprise GRC and AI governance across four jurisdictions, hospital access control under HIPAA, and NHS primary-care prescribing. I work with founders and product teams in the US, UK, Singapore and Australia.
Experience
15 years
Sectors
GRC · Healthcare · Fintech · AI governance
Clients in
US · UK · Singapore · Australia
Work
Prototypes · MVPs · Design systems
Client calls weekdays 8:30 AM – 2:00 PM ET · Reply within your working day
What clients say
We started working with Rajeev more than a year ago on an investor proof of concept. Since then, the project has grown into four products and 20 modules. Rajeev led a team of four designers, guiding the work from early requirements through to the customer-facing experience.
Enterprise GRC client · name under NDAEnterprise GRC platform · Case study 01
Our four-year-old product needed a refresh, especially around UX and user flows. Rajeev helped us improve the experience while addressing our HIPAA requirements. He brought expertise across the project and delivered quickly, using AI effectively to speed up the work.
Alowonle AwedaUS hospital software company · Hospital access control under HIPAA · Case study 02
We’ve worked with Rajeev for over a year, and the results have become clear over the past six months. We’ve seen growth in revenue and secured investors. Rajeev’s work has been an important part of that progress.
Reza SamaniArog Care · Primary-care prescribing · Case study 03
He translated a complex, regulated healthcare product into an experience that feels simple and trustworthy for patients.
Akhil TCEO, Signifier Medical · UK Snoozeal — companion app for an IoT medical device
Easy to hire from the US, UK and EU
Pay in your own currency
Local bank details in USD, EUR, GBP, CAD, AUD and SGD through Payoneer or Deel. Your finance team makes a domestic transfer, not an international wire.
Hire on the platform you use
I work as an independent contractor, directly or through Deel or the platform your company already uses. No payroll or local employment paperwork on your side.
Your NDA and contract
I sign your NDA and MSA before work starts, and a GDPR data processing agreement if the project needs one. Most projects never touch real user data.
Start with a trial sprint
Begin with a one-week sprint on a real part of your product, for $2,500. Contract type, payment terms and notice are agreed in writing per project.
A hospital information system where the hardest design decisions were about who may see what, not how it looks.
View demo →Full clickable prototype · opens in a new tab · synthetic data only
Scope
28 screens · 11 modules
Roles
4
Domain
US hospital
Focus
HIPAA access control
Context
BridgeCare HMIS runs a US regional medical center across eleven modules: clinical care, patient access, revenue cycle, ancillary and supply, and administration. Four roles use it — an attending physician, a patient access and financial coordinator, an ancillary and supply chain director, and a COO who is also the IT admin.
The client is a US hospital software company, unnamed under NDA, so the product is shown here as BridgeCare, a stand-in name, with synthetic data. I joined midway through a refresh of their established product, to rework the compliance use cases and redesign the UX around how doctors actually work.
The constraint
HIPAA's minimum necessary standard means each role sees only the patient information its job requires. The physician sees the full chart. The coordinator sees account, payer and coded data. The COO sees no clinical PHI at all.
And in an emergency, a clinician with no care relationship to a patient still has to get in. That is not a permissions screen. It decides the navigation, what every table shows, what can be exported, and what has to be written down afterwards.
Locking people out is easy. The design problem is letting the right person in at 3am, and proving afterwards why they were there.
The decisions
Break Glass is a deliberate, recorded act.A sealed record shows as a row, never as data. Opening it needs a reason, free text and an attestation. It grants 60 minutes of access, alerts the Privacy Officer and department chair, and puts the access on the weekly review list.
Privacy Mode masks identifiers, not clinical facts.Names, MRNs and ages blur on shared screens while results and tasks stay readable. Revealing a single value is possible, and each reveal is written to the audit log. The bed board stays masked because corridor workstations can see it.
Locked modules stay visible.Modules outside a role appear in the menu marked Locked instead of disappearing, so the boundary is something users can see rather than guess at.
A critical result needs a documented action, not a click.Acknowledging writes the reviewer, timestamp and action taken to the permanent record. The queue shows how long the oldest critical value has waited against the 60-minute policy.
Some permissions can't be granted at all.Controlled-substance prescribing needs the prescriber's second factor, never SMS, and the PDMP check is recorded on the prescription. In the role matrix, an administrator cannot give Break Glass or EPCS to a non-clinical role — those boxes are prohibited by policy, not just unticked.
What shipped
28 screens across 11 modules and 4 roles
Privacy Mode, automatic logoff, Break Glass, and an append-only audit log retained for six years
Minimum-necessary exports — a full chart export for a claim appeal is blocked, not just discouraged
Controlled-substance e-prescribing with EPCS and PDMP
Single-file HTML prototype, hosted and clickable end to end, on synthetic data
Outcome
Shorter time to complete a case or consultation
More time spent in the product, and a larger user base
Many HIPAA compliance gaps closed, reducing the risk of penalties
Sales up 7%
Our four-year-old product needed a refresh, especially around UX and user flows. Rajeev helped us improve the experience while addressing our HIPAA requirements. He brought expertise across the project and delivered quickly, using AI effectively to speed up the work.
Attending dashboard — a critical lab, a sepsis timer and a coding query in one queue.Patient census — a record you're not cleared for appears as a sealed row.Break Glass — opening that sealed row needs a reason and an attestation, and alerts the Privacy Officer.Order entry — a sulfa allergy blocks one order, and the opioid prescription needs a PDMP check and the prescriber's second factor.Results review — a critical value needs a documented action within 60 minutes.The dashboard under Privacy Mode — clinical detail stays readable.
Four regulators, four definitions of the same control, and an auditor who needs to reconstruct a decision months later.
Domain
Enterprise GRC
Platform
Web
Tech
Snowflake
Jurisdictions
4+
Deliverables
Product + collateral
Client work under NDA. The product is shown under a mock brand, Colormoon, and some details are generalized — the design reasoning is unchanged.
Context
An enterprise governance, risk and compliance (GRC) platform built on Snowflake. Eleven modules cover policies and controls, risk, compliance, audit, third-party risk and AI governance, for an organisation operating in the US, Germany, the UK and India — HIPAA, SOC 2, ISO/IEC 27001, NIST CSF, PCI DSS, GDPR, UK GDPR and India's DPDP Act, with AI models and agents governed alongside them.
I joined at the earliest stage of the proof of concept, working directly with the founder and stakeholders. I gathered the requirements and set the scope: which compliance frameworks, domains and controls the product would target first.
The constraint
Every regulator wants the same underlying thing — evidence that a control existed and operated. But each defines the control differently, on a different cadence, with a different evidence standard.
Model the product around one regime and you produce a tool that satisfies one auditor and fails the others. Model it around the union of all requirements and you produce something nobody can use. The design problem was finding the layer underneath — the atomic evidence event — and letting each regime's view compose from it.
An auditor does not accept "trust us." Every screen had to answer: what happened, when, who permitted it, and how do I verify that independently?
The decisions
Evidence is the primitive; frameworks are views.One evidence event maps to many controls across many regimes. Building the reverse — a control that generates evidence — would have required duplicating every event per framework.
Policy-as-code surfaced as readable policy, not code.The person attesting to a control is a compliance officer, not an engineer. The rule executes as code and displays as a sentence, with the code available one click away for whoever needs it.
Jurisdiction is a filter, never a mode.Making it a mode means someone is always looking at an incomplete picture without knowing it. As a filter, the full state is always one click away and the omission is visible.
Design and front end built together, not handed over.I designed the UX and built the complete front end myself, with AI speeding up the build. Every user type, use case and flow was working in the browser, so the founder and stakeholders reviewed real behaviour, not static screens.
Sales material drawn from the product, not invented for it.The demo video, flyers, brochure and marketing material use the same screens, terms and flows as the product, so what investors and buyers see in a pitch is what they get in the demo.
What shipped
A complete, responsive front end covering every use case and user type
Figma designs for each flow, with both the happy path and the error paths
Process maps and user flows
A product demo video
Flyers, a brochure and supporting marketing material
Outcome
The working product aligned the internal team on what was being built, and it supported the fundraise: investors saw the product working, not a slide describing it.
We started working with Rajeev more than a year ago on an investor proof of concept. Since then, the project has grown into four products and 20 modules. Rajeev led a team of four designers, guiding the work from early requirements through to the customer-facing experience.
Executive dashboard — one compliance score and the open exposure in dollars, every number linked to its records.Business & Footprint — four jurisdictions, and 16 frameworks activated from where the business operates, not configured by hand.
Governance
Governance overview — policies due for review, live attestation campaigns, and an AI policy suggestion a person has to accept.Policy library — version, status, owner, next review and the frameworks each policy serves.Control library — type, owner, last test result and effectiveness side by side, so a failing control can’t hide.
Compliance
Framework posture — HIPAA, SOC 2, ISO 27001, NIST CSF, PCI DSS and GDPR, requirement-weighted.Frameworks — each one with its score, health, controls, policies, open gaps and a named owner.
Discover — connectors and lineage
Connectors — one control plane, many data planes. Ten of fourteen connectors are read-only.Every connector shows its access level, health and token status. Scans can’t run without a connected source.Data lineage — from SAP ERP through procure-to-pay to the controls, frameworks and reports that depend on it.
Risk
Risk distribution by category and department — select a slice to highlight it.Twelve-month risk trend — raised, mitigated, closed and formally accepted.Risk matrix — the residual heatmap of 59 open risks, four above appetite.
Audit
Audit calendar — 14 engagements in 2026, from HIPAA and SOC 2 to an AI model governance audit and DPDP readiness.Audit dashboard — 14 engagements, overdue audits, and open findings by severity.Findings by department, and completion rate across every open engagement.
Trust Estate and third parties
AI agents — an identity check flags one agent sharing a service account, a PCI DSS Req. 8.2 violation.AI model registry — provider, approval, governance score and policy violations for every model in production.Third party — vendor tiers, risk scores, reassessments due and contracts ending within 90 days.
Reports
Reports — issues in scope, open exposure, and alert precision after human review.Open issues by control domain — issues not linked to a control show up as Unmapped, not hidden.
Repeat prescriptions that don’t get stuck between the patient, the practice team and the GP.
View demo →Full clickable prototype · opens in a new tab · all data made up
Scope
52 screens
Roles
Patient, practice team, GP
Market
NHS England
Type
White-label platform
Context
A repeat prescription in an NHS GP practice passes through three people who rarely meet: the patient who orders it, the prescription coordinator who prepares it, and the GP who signs it. Most of the hand-offs between them run on phone queues and free-text notes.
Arog Care is one shared workflow with a view for each of them. A single case runs through all three: Anita orders her repeats, Leanne in the practice team prepares the decisions, and Dr Carter decides and signs.
A pharmacy company wanted the system for its own patients, built as a white-label product that other pharmacies could run under their own name. I came to it fresh and led the design on my own, covering the three journeys you can click through in the demo: patient, practice team and GP.
The constraint
Only the GP can prescribe. The practice team can check, prepare and pend against protocols the GP sets, but the signature and the clinical judgement behind it stay with the prescriber.
So the product had to take as much work as possible off the GP’s desk without ever letting the team cross that line, and without asking the patient for anything already in their GP record.
The team prepares, the GP decides. The design job is making each hand-off carry its evidence with it.
The decisions
The GP owns the protocol. The team applies it.Leanne can pend a repeat when it meets criteria Dr Carter has set, like one 28-day issue when a review is overdue and bloods are current. Anything outside the protocol goes to the GP. The signing queue is split into “meets your protocols” and “needs your judgement”.
Hospital letters become actions with the evidence attached.The team pulls out what the letter asks the practice to do and attaches kidney function, HbA1c, interactions and formulary status, so the GP decides once instead of re-reading the record.
Messages are routed, never answered from a template.Symptoms go to a clinician or the right NHS service — chest tightness to 999 and the duty doctor, an uncomplicated UTI to Pharmacy First. Admin questions stay with admin.
Decisions are appended, not overwritten.Changing a decision adds a new entry. The earlier one stays in the record, so anyone can see what was decided, by whom, and in what order.
The patient sees the process, not just a status.Each order shows who is doing what and by when. A review that will shorten a supply is explained before the order is sent, and exemptions like the diabetes medical certificate are offered rather than left for the patient to discover.
What’s in the prototype
Patient. NHS login, onboarding from the GP record, a four-step repeat order with collection, delivery or barcode, charges and exemptions, home monitoring, test results, messages, and family proxy access.
Practice team. The repeat request queue, hospital letters, care navigation, home monitoring triage, reviews and recalls, and proxy access checks.
GP. Signing with a Smartcard, filing results with a note the patient can read, hospital requests, fit notes and forms, QOF, and repeat protocols.
Built to WCAG 2.2 AA. Status is always in words, never colour alone, and the NHS number stays masked until the patient chooses to show it. There is no backend and every patient in it is made up.
We’ve worked with Rajeev for over a year, and the results have become clear over the past six months. We’ve seen growth in revenue and secured investors. Rajeev’s work has been an important part of that progress.
Family and proxy access — what a proxy can see depends on age and consent, and the practice approves every one.Messages — the team explains why only a month was issued and what the patient needs to do next.
Practice team
Today — the coordinator’s queues, with the same-day items pulled to the top.Care navigation — each message goes to the right place, never a template reply.Home monitoring — readings sorted by who needs action first, against home blood pressure targets.
GP
Today — what the team has already prepared, before the GP starts signing.Prescriptions to sign — protocol items in one batch, judgement items kept separate.Results to file — the note the GP writes is what the patient reads in their app.
Most design processes start with screens and discover the constraints during build. In regulated products that order is expensive — you ship, then rebuild after the first compliance review.
01
Scope
One call. What you're building, who has to approve it, what the real deadline is, and what happens if it slips.
02
Domain logic
Roles, flows, edge cases, and the constraints that decide whether the product is usable at all. Written down and agreed before any visual work.
03
Screens
Clickable, real data, edge cases built. The screen you'll spend half your pitch on gets built to a different standard than the rest.
04
Handoff
Design system, every state, annotations on the decisions that matter. What your engineers build from without a meeting.
Engagements
Fundraise prototype
from $8,5002–3 weeks
12–20 clickable screens. Real data, edge cases, and the flow you'll spend half your pitch on built to a different standard.
MVP product design
from $24,0006–10 weeks
Full flows, design system, developer handoff. What your engineering team builds from.
Design partner
from $7,500/mo2 days/week · 3-month minimum
Ongoing capacity for funded teams shipping continuously. Scales to 3 or 4 days.
Trial sprint
1 week · paid
Not ready to commit? A one-week sprint on a real part of your product, so you can see how I work before a larger engagement.
$2,500
All engagements start with a 20-minute scoping call and a written proposal before any commitment.
Hiring me from abroad
My clients are in the US, UK, Singapore and Australia. Hiring me should feel like hiring someone local.
Payment
I invoice in USD, EUR, GBP, CAD, AUD or SGD and you pay to local bank details through Payoneer, or through Deel. Your finance team makes a domestic transfer. Fixed-scope work is billed by milestone; design partner work is billed monthly.
Contract
I work as an independent contractor — directly, through Deel, or through the platform your company already uses. There’s no payroll, benefits or local employment paperwork for you. I sign your NDA and MSA before any work starts.
Data and privacy
Most projects run on synthetic or anonymised data and never touch real user data. Where the work does need it, I’ll sign a GDPR data processing agreement.
Terms and notice
Contract type, payment terms and notice period are agreed per project and written into the proposal. For ongoing work I suggest two weeks’ notice on either side.
Not sure yet?
Start with a one-week trial sprint on a real part of your product, for $2,500. If it isn’t working, you’ve spent a week, not a quarter.
Working together
Timezone
I hold 8:30 AM – 2:00 PM ET on weekdays open for client calls and you'll have a reply within your working day. I work with teams in the US, UK, EU, Singapore and Australia.
What speed actually means
Most studios quote 6–8 weeks for a fundraise prototype. I work in 2–3, because I've built a production workflow around AI-assisted tooling while spending the saved time on the parts that decide whether the product works — flows, edge cases, domain logic.
For a team burning $60k a month, five weeks back is worth considerably more than the design fee. That's the trade I'm offering.
What I don't do
Brand identity, marketing sites without a product behind them, or execution against a spec someone else has already decided.
Start with a scoping call.
Twenty minutes. If I'm not the right fit I'll say so and point you somewhere better.
A prototype that gets funded and a prototype that gets built are two different artifacts. Most founders only discover that after the round closes.
The funded one has to survive a specific kind of scrutiny: an investor who has seen a thousand clean flows and is looking for the thing you haven't thought about. Six things separate the ones that hold up.
Show the hard case, not the happy path
Every founder demos the flow where everything works. It proves nothing, because everything working is the easy part. Show the rejected claim, the failed payment, the clinician overriding the alert. The edge case is where you demonstrate that you understand the business rather than the interface.
Real data, never lorem ipsum
Fake data reads as "we have not spoken to a customer." Real names, real amounts, real reason codes. It costs an hour and it changes the entire read of the product.
One flow complete beats ten flows half-built
Breadth signals you have ideas. Depth signals you understand a problem. In a pitch you have eight minutes, and you will spend four of them on one screen — so build that screen to a different standard and let the rest support it.
Clickable, not a deck of images
The moment an investor clicks and something responds, the thing stops being a concept and becomes a product in their head. That transition is worth more than any amount of visual polish.
Design the empty states
That is what your product looks like on day one for every single customer. Skipping them is skipping the first impression of the actual product.
Know which screen carries the pitch
Even quality across forty screens is a worse outcome than uneven quality with the right screen built exceptionally. Decide in advance which one you are spending your time on.
The prototype isn't a preview of the product. It's an argument that you know what you're building.
None of this is about visual craft. It is about whether the artifact demonstrates that you have thought past the demo — which is the only question the person across the table is actually asking.
In most products, constraints are discovered in roughly this order: design, build, test, ship, first customer, security review, rebuild.
In regulated products that order is expensive, because the constraints are not preferences that can be negotiated. They are legal boundaries, and a product that crosses one is not a product with a bug — it is a product that cannot be sold.
An example
In US controlled-substance prescribing, a medical assistant can prepare an order and cannot sign it. EPCS two-factor authentication is tied to the prescriber's identity and is not delegable.
Discovered during design, that is an afternoon's work: the MA composes, the order pends, the physician reviews and signs. Discovered during build, it is a rework of the permission model, the queue, the notification system, and the audit trail. Discovered by a customer's compliance officer, it is a lost deal and a rebuild.
The cost of a constraint is not fixed. It multiplies with every week you go without knowing about it.
What this means practically
The first week of a regulated-product engagement should produce almost no visual output. Roles, boundaries, sequencing, evidence requirements, what has to be true before an action is permitted. Written down, argued about, agreed.
Founders sometimes read that week as slow. It is the opposite — it is the week that prevents the rebuild, and it is the reason a two-to-three week prototype is achievable at all.
The tell
You can usually spot a product designed without domain input in one pass. Permissions modelled as settings toggles. Records with edit affordances where amendments are required. Approval flows ordered by arrival time rather than urgency. Each of those is a design that will work in a demo and fail in a clinic.
A founder told me his design timeline was eight weeks. His runway was five months.
Two months of a five-month runway, spent on screens, before a single investor conversation. Nobody had made that decision on purpose. It was simply what the quoted timeline implied, and the implication went unexamined.
The arithmetic nobody runs
A team burning $60,000 a month spends $120,000 during an eight-week design cycle. Compress it to three weeks and $75,000 comes back — not as savings, but as runway, which is the more valuable currency. It is also five extra weeks of investor conversations at the front of the process rather than the back.
Against that, the difference between a $6,000 and a $12,000 design fee is noise.
The output isn't cheaper when it's faster. It's earlier. Earlier is worth more.
What makes it possible
AI-assisted production, used for the parts that are production rather than judgment. Screen generation, component systems, state variations, copy iterations. The saved time goes into the things that decide whether the product works — domain logic, edge cases, the sequencing of a regulated flow.
The failure mode is using the speed to produce more screens. A hundred screens generated quickly is volume, and volume is what cheap vendors sell. The same speed spent on depth is a different product.
The pricing implication
Charging less because the work took less time prices the hours. Nobody buying a fundraise prototype is buying hours — they are buying a closed round, an approved budget, a dev team with something to build. Delivering that outcome a month sooner makes it more valuable, not less.
When a healthcare revenue-cycle team adds automation — a bot that submits claims, an AI agent that drafts appeals — the dashboard usually reports what the automation did. Claims submitted. Appeals sent. Tasks completed.
None of those is the outcome. The outcome is whether the payer paid, and the payer already tells you.
What the 835 is
The 835 is the X12 electronic remittance advice: the file a US payer sends back after it adjudicates a claim. For every claim line it says what was billed, what was paid, and why the two differ — in claim adjustment reason codes (CARCs), remark codes (RARCs), and group codes that say who carries the balance: a contractual write-off, the patient, or something else.
It is structured, it arrives as part of normal payment, and it is the payer’s own record. As evidence goes, that is about as good as it gets.
Self-reported success is not success
An agent that submits an appeal and marks the task complete has reported its own success. Whether the appeal worked shows up weeks later, in a remittance, as a payment or another denial. A dashboard that stops at “appeal sent” is measuring activity and calling it an outcome.
The automation tells you what it did. The 835 tells you what happened.
Designing around the reconciled outcome
Join every automated action to the remittance that settles it, and show the gap. An action with no remittance yet is pending, not successful.
Report cost per paid claim, not cost per task. A cheap action that leads to a second denial is an expensive one.
Group denials by reason code, not by the automation’s own categories. CARCs are the shared language of the payer, the billing team and the auditor.
Keep the remittance one click away from every number, so anyone can check a figure against the payer’s file.
Beyond billing
The pattern holds in any regulated product with an outside record of truth: a bank statement, a regulator’s acknowledgement, an auditor’s sign-off. Find the record you don’t control and design the measurement around it. It is harder to argue with, and it is usually already free.
An organisation operating in the US, Germany, the UK and India can answer to HIPAA, SOC 2, ISO/IEC 27001, GDPR, UK GDPR and India’s DPDP Act at the same time. Each has its own control language, its own cadence and its own idea of what proof looks like.
The tempting design is a tab per framework. It is also the one that quietly doubles the work.
The control is not the unit
Take a quarterly user access review. HIPAA expects access to patient data to be managed and reviewed. SOC 2 tests logical access. ISO 27001 has a control for reviewing access rights. GDPR asks for appropriate technical and organisational measures. Four framings, one activity: someone checked who has access, and signed it off.
If the product models four controls, the team uploads the same review four times — or four slightly different versions of it. When the auditor asks which one is true, nobody can say.
Evidence is the primitive. Frameworks are views.
What changes in the design
One evidence record, many mappings. The review is stored once, with its date, owner and source, and mapped to every requirement it satisfies.
Jurisdiction is a filter, not a mode. A German auditor filters to GDPR and BDSG. The full picture stays one click away, and nothing outside the filter disappears without saying so.
Unmapped is a first-class state. An issue with no control behind it shows as Unmapped, with its exposure, instead of falling out of every report.
Frameworks activate from the footprint. Where the business operates and what it processes decide which frameworks apply, so nobody has to configure one by hand — or forget to.
The test
Pick any number on the dashboard and ask: what evidence is this built from, and which regulators does that evidence satisfy? If the product answers in one click, it was designed around the evidence. If it needs a spreadsheet, it was designed around the frameworks.
A Figma and React design system for governance, risk and compliance products, built around how audits really work: chasing evidence, owners and deadlines.
A Figma and React design system for AI governance products, built around what the law actually asks: classify, prove, and report before the clock runs out.
Components
79 · 638 variants
Screens
15
Tokens
171 variables
React
Component library
Free Figma file · full kit from $49, or $119 with the React library
