Early-stage startupIllustrative case study
From hackathon prototype to security questionnaire
A health-tech team answered a customer’s security questions before they became a rebuild.
Illustrative. This is a fictional composite written to show how the model works. The people, startup and details are invented. It is not a real client, and no result or outcome is claimed or guaranteed.
The situation
The team built a scheduling tool at a hackathon and kept building. It stored user information in a managed database and used two AI services to summarise notes.
A pilot customer sent a security and privacy questionnaire. The team could not say where data was stored, who could see it, whether it was encrypted, or how AI summaries were checked.
The question in the way: Are we building the right thing safely?
- Team
- Four-person technical team
- Sector
- Health-technology scheduling with AI-assisted summaries
- Stage
- Working product, first pilot customer
- Route
- Startup plan
What the diagnostic found.
The UERF baseline ranked the gaps by urgency. Severity is shown by name and symbol.
- CriticalAccess to customer data was broad, with shared credentials and no multi-factor authentication.
- CriticalNo data map or retention rule for the information collected.
- HighAI services in use with no register, no review of vendor terms and no human check on summaries.
- HighCode and cloud accounts held personally.
- MediumNo cost forecast for cloud and AI usage.
The plan, in order.
One priority map, worked through by the roles the stage called for.
First 7 days
- Turn on multi-factor authentication and remove shared logins.
- Draw a one-page architecture diagram with data flows and third parties.
By day 30
- Write the data map and a retention rule.
- Create an AI register and decide which outputs need human review.
- Move code and accounts to company control.
By day 60
- Make build-versus-buy decisions, such as using a managed login service instead of a custom one.
- Forecast cloud and AI costs and test backups.
Who helped
What they produced
- Architecture review
- AI register
- Security and privacy control plan
- Cloud decision
- Vendor comparison
Connected modules
METPL.Cloud, InfraVeritas. How they connect
Step 5 and 6: Prove, then raise and scale
What changed.
- The questionnaire was answered from documents that now existed, not from guesses.
- The planned custom login system was replaced with a managed service, saving a rebuild.
- A person now reviews AI summaries before they reach users, and the team keeps a log of problems found and fixed.
- Cloud costs were forecast against expected usage for the first time.
Lessons
- Security and privacy are cheapest when they are design decisions, not retrofits.
- A short, honest AI register answers most customer questions.
- Build-versus-buy is a decision to record, not an accident.
Illustrative. This is a fictional composite written to show how the model works. The people, startup and details are invented. It is not a real client, and no result or outcome is claimed or guaranteed.
Other case studies.
- Student foundersThree friends, one app, no paperworkA campus ed-tech team found out who owned what before an investor asked.
- Early-stage startupThe calendar nobody ownedAn agri-tech startup turned scattered filings into one calendar and a folder of proof.
- Early-stage startupTwelve warm leads, two invoicesA workflow-tool startup found where deals were stalling by writing the pipeline down.