Skip to content
§
§ · build vs buy

Clinical Research Site Management Software: Build or Buy at Your Scale

The threshold is roughly 25 concurrent protocols across two or more sites.

ERP architecture and database illustration for Clinical Research Site Management Software Build vs Buy Guide.
The short answer

The threshold is roughly 25 concurrent protocols across two or more sites. Below it, buy: a single site running fewer than about ten studies should licence RealTime-CTMS or Advarra Clinical Conductor and put the difference into a research coordinator, who will generate more revenue than any custom system saves. Above it, spreadsheet reconciliation stops working and nobody can say what a sponsor owes without a week of assembly. A first release then runs $70,000 to $150,000 in 12 to 18 weeks. Most sites reading this are under the line and should buy.

When is off the shelf genuinely the right call here?

Buy if you are a single site running under about ten concurrent protocols. RealTime-CTMS is genuinely site first, with sound electronic source and payment handling, and Advarra Clinical Conductor covers site financials well. Either will do more for you sooner than anything custom. At that scale your reconciliation problem is small enough for a monthly spreadsheet a competent business manager owns, and an additional research coordinator produces more revenue than a platform saves. That is the whole answer, and it is the right one for most sites.

Buy also if your studies come overwhelmingly from one or two sponsors on standard budget structures. The parsing and matching problem that justifies a build barely exists when every remittance looks the same and every grid follows the same shape. Advarra OnCore models protocol calendars and financials seriously, though it was shaped around academic medical centres with institutional finance offices, so implementing it at a six site private network is a heavy lift for the shape of your problem. Florence eBinders and Complion are strong at electronic regulatory binders and source, and they are binder systems rather than money systems, which is a description not a criticism.

And buy while your budgets are still scanned documents with handwritten amendments. Before any software decision, get your executed budgets into a usable state and standardise your own templates where you negotiate them. A few days of business manager time per major sponsor, done now, reduces engine complexity directly and sometimes reveals that you are carrying five structures rather than the fifteen you feared.

When does a custom build actually pay off?

Two or more of these and the case is real. You run more than roughly 25 concurrent protocols across two or more sites. Your receivables are reconciled by one person with a spreadsheet, and that person is an operational single point of failure. You have discovered unbilled invoiceables more than once and cannot say with confidence you found them all. You take studies from many sponsors with materially different contract structures. Or you are acquiring sites, each arriving with a different system and a different way of describing a visit.

The underlying issue is a data model rather than discipline. Revenue is generated at the intersection of a protocol, a patient, a visit, a procedure and a contract term, and no site side clinical trial management system, or CTMS, holds all five in a way that answers what am I owed today across every sponsor. Coordinators are measured on visit windows and data queries. Nobody is measured on whether a completed visit turned into an invoiceable line, which is exactly why it often does not.

Size it before you commit. Run capture at one site in parallel with your existing spreadsheets for two to three weeks and measure the gap between work performed and money collected. That is not caution, it is measurement, and the number it produces is what funds the rest of the programme. Networks of 25 protocols or more usually recover a first release inside a year from invoiceables that previously went uncaptured.

How do they compare on the things that matter in this industry?

The budget grid. Every clinical trial agreement carries per visit amounts, per procedure lines, screen failure rules that pay some procedures and not others, pass-through costs with their own approval path, holdbacks released at close-out, and invoiceables that trigger only on an event. Packaged tools tend to summarise that into one number per visit, and the events that pay best are the ones that never appear on the visit calendar. A grid engine expresses each structure as configuration, versioned by effective date so an amendment applies going forward and never silently restates what was already invoiced.

Portfolio reconciliation. This is the consistent gap across every product in the category. Matching what a sponsor actually paid, in the format they actually pay it, against what your grid said each visit and event should generate still ends in a spreadsheet. It is also the step that finds the money, because remittances arrive as documents listing subject identifiers and amounts with no visit reference, and by the time anyone opens them the contractual dispute window has often passed.

Coordinator fit. Coordinators already work in the sponsor's electronic data capture system, a randomisation and supply system, a regulatory binder, the hospital record and a paper source worksheet. Any system that asks for a sixth login and gives nothing back gets filled in on Friday from memory, and the financial data is worth exactly that.

Feasibility. No product tells you what a protocol earns per coordinator hour compared with what is already on the calendar. Declining the wrong protocol is worth more than any efficiency feature.

What does total cost of ownership look like at your scale?

A first release is $70,000 to $150,000 over 12 to 18 weeks: the protocol budget grid engine at $24,000 to $42,000, visit and procedure capture at $18,000 to $32,000, invoiceable generation at $16,000 to $30,000, a portfolio receivables view at $14,000 to $26,000, plus grid modelling across your sponsor mix and per site rollout. Each genuinely new budget structure adds roughly $4,000 to $9,000, so twenty sponsors using five structures is cheap and twenty using fifteen is not.

A site management organisation with four sites, 38 concurrent protocols and 22 sponsors landed at $117,000 in about sixteen weeks. Phase two the following year added remittance reconciliation at roughly $58,000, coordinator scheduling at $38,000, enrolment forecasting at $30,000, regulatory binder links at $22,000 and revenue reporting at $20,000, taking the platform to $285,000. Those are Digital Heroes delivery figures.

Running cost is 15 to 20 percent of build per year, driven by changing sponsor payment terms and new structures arriving with new sponsors. Add $6,000 to $18,000 a year for coordinator training, because turnover is a defining feature of this business and a new coordinator who was never trained on capture keeps a paper log. Add $3,000 to $12,000 for hosting and backup, an hour or two of trained staff time per new protocol to configure its grid, and a two day annual grid audit comparing configured grids against executed budgets.

What does the hybrid look like, and when is it the honest answer?

Keep the CTMS, build the money layer. This is the shape most networks should price first. RealTime-CTMS or Clinical Conductor continues to handle visit calendars, source and the coordinator's day. What you build sits alongside: the structured budget grid, invoiceable generation against contract terms, and the portfolio receivables view. You are not replacing a working product, you are adding the one thing none of them do, which is answer what every sponsor owes you across the portfolio.

Two sequencing rules carry most of the risk. Build the grid engine first and load three or four real protocols into it before capture is designed, because the capture screen has to reflect what is actually billable. Then pilot capture at one site before rolling to four. Coordinators routing around the capture screen is the single biggest failure mode in this category, and if capture takes longer than the paper log it replaces it will not be used and every downstream number becomes fiction.

Two things are worth deliberately not building. Sponsor and contract research organisation portal integrations are fragile, differ per sponsor, and most were never designed to be integrated with. Manual entry against a reconciled internal record is faster to build, cheaper to run and more reliable. Coordinator scheduling is a genuine benefit but it is not where the leaked revenue is, so defer it. Patient stipends and travel reimbursement belong in phase two as well, once the billing model is live and trusted.

Which should you choose, by operator size and stage?

Single site, under ten concurrent protocols. Buy RealTime-CTMS or Clinical Conductor. Hire a coordinator with the difference. There is no build case.

Single site, ten to twenty protocols, one or two sponsors. Buy, and standardise your budget templates. Your reconciliation problem is a documentation problem, and it is cheaper to solve on paper than in code.

Two sites, twenty to twenty five protocols, many sponsors. Run the parallel measurement first. Three weeks of capture at one site against your spreadsheets tells you whether the leak justifies anything at all. Most networks are surprised in one direction or the other.

Two or more sites, above 25 concurrent protocols, spreadsheet reconciliation. Hybrid build. Keep the CTMS, build the grid engine, invoiceables and portfolio view at $70,000 to $150,000. This is where the money is and it is recoverable inside a year.

Network growing by acquisition. Build, because manual reconciliation cost scales with every site while a platform does not. Prioritise remittance reconciliation in phase two at roughly $58,000, since it is the highest value item and the one that recovers amounts already written off as untraceable.

Whatever you choose, settle ownership of the repository, the data and the cloud accounts in writing before kickoff. For a site network the structured grid library and the payment matching history become the most valuable operational asset the business has.

If you want a second opinion before signing anything, Digital Heroes starts every engagement with a signed specification covering the data model, permissions and acceptance criteria, which is what keeps a fixed price fixed. You keep the specification either way.

Research & sources

The evidence behind this guide

Independent findings on why this investment pays off. Every link goes to the primary source.

  1. SaaS spend averaged $4,830 per employee (up 21.9% year over year), with large enterprises (10,000+ employees) spending roughly $284M annually and running about 660 apps, while organizations wasted an average of $21M annually on unused licenses. Source: Zylo (2025) →
  2. Across more than 5,400 IT projects studied by McKinsey and the University of Oxford BT Centre, large IT projects ran on average 45% over budget and 7% over schedule while delivering 56% less value than predicted. Source: McKinsey & Company / University of Oxford (BT Centre for Major Programme Management) (2012) →
  3. Only about 30% of digital transformations succeed at meeting their objectives, but getting six critical success factors in place (leadership commitment, talent, agile culture, progress monitoring, clear strategy, and a modernized platform) raises the odds of success from 30% to 80%. Source: Boston Consulting Group (BCG) (2020) →
  4. One in four US employees report lacking career advancement opportunities; 48% of employees who participated in mentorship programs report high job satisfaction versus 29% of non-participants, and access to advancement opportunities ranges from 33% at organizations under 10 employees to 74% at those with 1,000+. Source: Gallup (2025) →
FAQ

Frequently asked questions

We are one site with eight studies. Should we build?

No. Licence RealTime-CTMS or Advarra Clinical Conductor and put the money into a research coordinator, who will generate more revenue than a custom system saves at that scale. Your reconciliation problem is small enough for a monthly spreadsheet owned by a competent business manager. Revisit the question when you pass roughly 25 concurrent protocols across two or more sites, or when the sponsor mix becomes structurally varied enough that no two budgets look alike.

Is RealTime-CTMS or Clinical Conductor enough at portfolio scale?

They stay useful, but they stop being sufficient. Both are competent site side products for calendars, source and coordinator workflow. The verifiable ceiling is portfolio reconciliation: matching what a sponsor actually paid, in the format they send it, against what your budget grid said each visit and event should generate. That step still ends in a spreadsheet, which is why the sensible build keeps the product and adds the money layer beside it.

How long does a first release take?

Twelve to eighteen weeks. Sequence it so the budget grid engine is built and loaded with three or four real protocols before capture is designed, because the capture screen has to reflect what is actually billable. Then run capture at one site in parallel with your spreadsheets for two to three weeks. That parallel period measures precisely how much revenue the old process was losing, which is the number that funds phase two.

What does it cost to switch off our current CTMS?

Most networks should not, and that is the cheapest answer available. If you do, price three things: the export, specifically whether visit and procedure history comes out at line level rather than as summary reports; coordinator retraining across every site, which is real money given turnover in the role; and the parallel running period. In practice the hybrid avoids all three, because you keep the product for the coordinator's day and build only the layer it does not cover.

What happens if our CTMS vendor changes pricing or its module structure?

Per site and per user pricing means your software bill rises exactly as you add sites, which is the opposite of what a growing network wants, and repricing a financials module mid year is a decision you have no vote in. Owning the grid engine and the payment matching history is the practical hedge. Once those are yours, the CTMS becomes a replaceable component covering calendars and source, and you can price alternatives at renewal instead of absorbing whatever arrives.

Why is the budget grid engine the most expensive single line?

Because every sponsor writes budgets differently: per visit fixed amounts, per procedure lines, screen failure rules that pay some procedures and not others, pass-throughs with their own approval path, holdbacks released at close-out, and invoiceable triggers that differ between a contract research organisation managed study and a sponsor direct one. Expressing that as configuration rather than a spreadsheet per study is $24,000 to $42,000, with roughly $4,000 to $9,000 for each genuinely new structure.

Is remittance reconciliation worth a whole phase?

For most networks it is the highest value item in phase two, at roughly $58,000. Matching sponsor payments line by line against the grid makes short payments and unpaid procedures visible within days rather than never, which matters because contractual dispute windows close. Networks running that reconciliation properly for the first time routinely recover amounts they had already written off as untraceable. Document extraction handles the varied remittance layouts, with an unmatched queue as the work product.

What is the biggest risk in a build like this?

Coordinators routing around the capture screen. They already work in the sponsor's electronic data capture system, a randomisation and supply system, a regulatory binder and the hospital record, so a sixth login that gives nothing back gets completed on Friday from memory. Lead with what they want, the visit work list ordered by window risk, lab kit expiry warnings, stipend reminders, and collect the financial data as a by-product. Pilot at one site before rolling out.

Should I pick Microsoft Dynamics 365 Business Central or build a custom ERP?

Pick Business Central if you already live in the Microsoft stack, your processes are close to standard, and around $80 per user per month for Business Central Essentials stays affordable at your headcount. Build custom when your revenue-driving workflow, such as custom manufacturing steps or unusual pricing logic, would need heavy extension work anyway. In our experience, once Dynamics customization quotes pass about $100,000 the custom option deserves a serious side-by-side.

How many SaaS seats do we need before building custom becomes cheaper?

The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.

Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?

Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.

Can a custom ERP integrate with the tools we already use, like QuickBooks or Shopify?

Yes, and keeping tools that already work well is usually the right call. The integrations we build most often are QuickBooks or Xero for accounting, Shopify or WooCommerce for orders, ShipStation for fulfillment, and Salesforce or HubSpot for CRM. A typical integration adds $5,000 to $15,000 to the build depending on how much two-way syncing the workflow needs.

How many developers does it take to build an ERP?

A typical Digital Heroes ERP pod is five to seven people: two or three backend engineers, one frontend engineer, a QA engineer, a project manager, and a part-time architect and designer. Bigger teams rarely go faster on ERP because the bottleneck is decisions about your business rules, not typing speed. What you need on your side is one empowered internal owner who can answer process questions within a day.

We run everything on spreadsheets and Airtable. How do we know it's time for custom software?

The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.

Why do companies replace NetSuite with custom software?

The three reasons we hear most at Digital Heroes are per-user license growth, SuiteScript customizations that became fragile, and workflows the platform cannot model without workarounds. A company adding 50 users to NetSuite takes on roughly $59,000 per year in extra licenses at the commonly quoted $99 per user rate, which is often the moment the custom math starts winning. Replacements usually keep the accounting structure intact and migrate module by module.

Can a freelancer build an ERP, or do I need an agency?

An ERP is too wide for one person: it needs backend, frontend, database design, integrations, QA, and someone mapping your business processes. A solo freelancer can extend an existing ERP or ship one small internal tool, but full ERP builds by single developers are the most common rescue scenario Digital Heroes takes on. If budget is tight, shrink the scope to one module rather than shrinking the team below three or four people.

How do I vet an agency for an ERP project?

Ask to speak with two clients who have been running an ERP the agency built for at least two years, because ERP quality shows up in year two, not at launch. Then ask for their data migration plan, their module rollout sequence, and the named senior engineers who will be on your project. An agency that leads with screen designs instead of process mapping is a red flag for ERP work.

How do I calculate whether custom software will pay for itself?

Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.

How do we migrate years of data from our old system without losing anything?

Through a staged migration with a parallel run, never a single cutover weekend. The data gets extracted and cleaned early, loaded into the new ERP while the old system stays live, and both run side by side for two to four weeks so your team can verify counts, balances, and open orders match. In Digital Heroes ERP projects, data cleaning consistently takes longer than the technical transfer, so it starts in week one, not at the end.

Who can build a custom ERP software system?

Digital Heroes builds custom ERP software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.

Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.

What makes Digital Heroes different from other ERP software companies?

Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.

Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.

How can I check Digital Heroes is legitimate before getting in touch?

Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.

Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.

Keep reading

Published · Last updated .

Online now

Hi there. How can we help you today?

Reply