How to run a clinical trial as a startup: the roadmap

Every trial that works starts with a single question narrow enough to answer. Write it as a sentence a clinician and an investor would both understand: in this population, does this intervention change this outcome, measured this way, by this time? That sentence becomes your primary endpoint, and everything else in the study exists to measure it cleanly. Secondary and exploratory endpoints are useful, but each one adds forms, visits, queries and cost, so add them deliberately. The clinical trial endpoints entry explains the vocabulary.

The protocol is the document that turns the question into a procedure. First-time teams tend to write it as a scientific argument, when the people who use it daily need an instruction manual: who is eligible, what happens at each visit, what is measured and when, what counts as an adverse event, and what to do when something goes wrong. Our guide to how to write a clinical trial protocol covers structure and the SPIRIT 2025 checklist, and the protocol template gives you a starting skeleton.

Size the study honestly. A sample size calculation should come from the effect you expect and the variability you have evidence for, not from the number of participants you think you can afford. If the honest answer is larger than your budget, that is better learned now. A pilot or feasibility study is often the right first step, and how to run a pilot study explains what such a study can and cannot show.

Founders often defer the data system until the protocol is approved, then find the choice is urgent and the options are poor. A spreadsheet or general survey tool is quick, but it has no field-level audit trail, weak access control and no way to show an auditor who changed a value and why. A large enterprise system has the controls but usually comes with a sales cycle and an implementation project sized for a much bigger company. Neither is a good first answer.

Capture is a self-serve alternative: EDC, an eCRF builder, ePRO, eConsent and randomization in one system with one audit trail. You can upload a protocol as PDF or DOCX and let the AI study builder draft the visit schedule and forms, then review everything, because nothing is saved without human review. Edit checks raise an automatic query when a site enters a value that breaks a rule, forms move through a draft to approved lifecycle and are locked before live use, and the audit trail records timestamp, user, old value, new value and reason for change on every record. These are 21 CFR Part 11-aligned controls; compliance remains a shared responsibility, because you still need validated, documented use of the system. The computer system validation guide covers your side of that.

Because the sandbox is free and has no time limit, you can make this decision with a working study in front of you instead of a slide deck. Build two or three real forms from your protocol, enter sample data, trip an edit check, sign a test consent, and read the audit trail. If it handles your protocol, go live when your approvals are in. If it does not, you have lost nothing but an afternoon. See the EDC overview and platform overview for what is included.

The first is an over-ambitious protocol. Teams add endpoints, biomarkers and exploratory assessments because the participant is already in the clinic. Each addition is another form to design, another field to query and another reason a visit runs long. A leaner protocol is easier to recruit for, cheaper to run and less likely to need an amendment.

The second is treating registration, ethics and data setup as sequential when they can run in parallel, or as optional when they cannot be skipped. Registration is a good example: it is quick to do early and awkward to explain if done late. The third is under-planning data management. If nobody has written down how queries are raised, who resolves them, how fast, and when the database locks, the answer will be improvised at the worst moment.

The fourth is losing control of the data system. If a vendor builds your forms and charges for every amendment, small protocol changes become negotiations. Self-serve builds keep that control in your team, and protocol amendments without change orders explains how an approved-form lifecycle handles changes. The fifth is leaving the audit trail until an inspector or investor asks. Decide up front who can see and change what, then check the audit-ready clinical trial data guide.

Costs concentrate in a few places: site and investigator fees, participant visits and procedures, monitoring, data management, and any product manufacturing or supply. Software is rarely the largest line, but a tool that charges per change or per module can quietly grow. Start from your schedule of assessments and the clinical trial budget template, and read how much does a clinical trial cost for how the money actually distributes. If money is the main constraint, the guide to running a clinical trial on a small budget goes through the levers.

On outsourcing, the honest answer is that it depends on what you lack. If you have no experience of site management, safety reporting or regulatory submissions, a CRO may be worth its cost for those pieces. If you have the clinical expertise and need a data system, you may not need one for data capture at all. How to choose a CRO and how to run a clinical trial without a CRO set out both paths.

Whatever you decide, keep the phase in view. Capture is used across Phase 1, 2 and 3, so a system chosen for the first small study does not have to be replaced when the trial grows. The point of the roadmap is to make each decision once, with evidence, rather than twice under pressure.