eCOA and ePRO Platforms: Licence Signant Health, or Build Your Own at Portfolio Scale?
This is a portfolio decision, not a study decision, and the threshold is whether per study configuration has become your largest data collection line.
On this page
This is a portfolio decision, not a study decision, and the threshold is whether per study configuration has become your largest data collection line. For a single pivotal trial where a licensed instrument carries the primary endpoint, licence Signant Health, Medidata Patient Cloud or YPrime and do not think about it again: their existing migration and approval work for common instruments is worth more than ownership on that timeline. Build when the same instrument set repeats across many studies, or when sensors, app behaviour and questionnaires are one product rather than three vendors. Most sponsors reading this should licence.
When is off the shelf genuinely the right call here?
Licence if you are running a single pivotal trial where a licensed instrument carries the primary endpoint. Signant Health, Medidata Patient Cloud and YPrime have already done the screen migration and approval work for the common instruments, and that prior work is genuinely worth paying for when your filing depends on it. Taking on first time screen approval for a validated instrument while a pivotal study is enrolling is a schedule risk with no compensating benefit, and we would tell you so before quoting.
Licence also if your requirement is periodic questionnaires in one language for a short study. The economics never turn over. Two costs sit outside the software either way and they dominate at that scale: instrument licence fees, paid to whoever owns the copyright on the questionnaire and quoted per study by that owner, and screen level migration approval, which is calendar time rather than cash and is the most common reason an electronic clinical outcome assessment go live date moves.
Buy and stop, too, if your complaint is a configuration complaint. If a vendor rendered an instrument in a way your team dislikes but the instrument owner approved it, that is a preference, not a defect, and building a second platform will not change what the copyright holder will accept.
The test that settles it: add up three years of actual per study configuration spend, add the instrument licence fees you pay regardless, and compare against a build plus 20 to 26 per cent annual maintenance. If the first number is smaller, licence.
When does a custom build actually pay off?
The build case is a volume and integration argument rather than a feature argument, and it needs two or more of these to hold.
You reuse the same instrument set across many studies and per study configuration has become a visible budget line rather than a rounding error. You have a digital endpoint programme where sensors, app behaviour and questionnaires form one product rather than three vendor relationships that reconcile afterwards. You work in a therapy area where subject experience materially affects retention, and you want to iterate on the app rather than file a change request and wait. You run decentralised studies where the app effectively is the site. Or you are building a data asset across studies and cannot have it fragmented across three vendors' export formats.
The structural reason is that a platform vendor's economics are per study. That is a perfectly reasonable model, and it is exactly wrong for a sponsor whose value comes from running the twentieth study on the same instrument set as cheaply as the first. Nothing a vendor can configure changes their pricing shape, and no amount of negotiation converts a per study fee into a portfolio fee.
The tipping point is when patient experience becomes part of your scientific strategy rather than a collection mechanism. Once you are designing the interaction rather than selecting a questionnaire, renting the interaction back per study stops being defensible.
How do they compare on the things that matter in this industry?
- Instrument fidelity. Instruments must appear as licensed and validated, with item order, response option layout, recall period wording and scale presentation preserved. A vendor with an approved presentation for your instrument is genuinely ahead. This is the single strongest reason to licence.
- Migration approval calendar. Moving a validated paper instrument to a screen usually requires the instrument owner to review the electronic presentation, per instrument, per language, sometimes per device form factor. That queue is the same length for everyone, so a vendor who already cleared it has a real advantage on one study and none on the twentieth.
- Timestamp defensibility. An entry must be timestamped at completion, not at sync, and a subject must not be able to backdate it. That means device clock, server clock and drift held together with attribution. It is a data structure decision made on day one rather than a feature.
- Language count economics. Every translated instrument version is a separate approved artefact with its own rendering test. Eleven languages is not marginally harder than three, and vendor pricing and build cost both scale with it.
- Sensor and questionnaire reconciliation. Continuous data beside episodic diary entries needs its own gap handling and reconciliation. Where these sit with different vendors, the reconciliation lands on you anyway.
- Per study economics. Configuration fees recur per protocol indefinitely. A platform you own does not, which is the whole portfolio argument.
What does total cost of ownership look like at your scale?
In Digital Heroes delivery experience a first release runs $95,000 to $200,000 and ships in 14 to 20 weeks. That covers instrument rendering, scheduled diary windows, offline capture with defensible timestamps, reminders, a site compliance view and a 21 CFR Part 11 audit trail. Typical line items inside it are instrument rendering at $34,000 to $52,000, diary scheduling and windows at $22,000 to $36,000, offline capture and sync at $26,000 to $42,000, reminders at $14,000 to $24,000, the site compliance view at $16,000 to $28,000 and the audit trail at $18,000 to $30,000.
A full platform adding provisioned device fleet management, bring your own device distribution, multi language instrument versions, wearable and sensor ingestion, proxy reporting and a reconciliation feed into electronic data capture runs $280,000 to $650,000 across 9 to 15 months. Wearables alone are $50,000 to $85,000.
Language count is the driver most teams miss. Bring your own device is second, because supporting patient owned hardware widens the test matrix considerably and creates support cases you cannot reproduce. A strict quality function is third: the same feature set can vary by $60,000 or more between two sponsors purely on validation evidence expectations.
Ongoing cost is 20 to 26 per cent of build value a year, the highest ratio in most regulated categories, because operating system updates on patient devices arrive whether you are ready or not and each needs a compatibility pass. Add device fleet logistics per patient, a patient helpdesk proportional to enrolment, translation maintenance and instrument licence fees you pay either way.
What does the hybrid look like, and when is it the honest answer?
The hybrid here is a sequencing decision more than an architecture one, and it is the honest answer for most sponsors moving from licensing towards ownership.
Licence the pivotal studies. Build for the tail. Your filing enabling trials keep the vendor with the approved instrument presentations and the regulatory familiarity, because that is where schedule risk is intolerable. Your repeating studies, registries, extension studies and observational work move onto a platform you own, starting with the instruments you use in every protocol and one language pair. That gives you a real portfolio saving without putting a filing on a first in house system.
The other hybrid shape is inside the build itself. Provisioned devices only for the first study is a deliberate choice: a controlled fleet is more logistics work and far less testing work than patient owned hardware, and it removes a large category of unreproducible support cases from your first release. Defer wearables if your primary endpoint is a questionnaire. Carry forward instrument presentations already approved on screen for an earlier study, because reusing that exact presentation avoids a fresh migration review and the approval cycle attached to it.
The smallest useful version is rendering, diary windows, offline capture and the audit trail for the instruments in every protocol, one language, provisioned devices. That is the bottom of the first band and it proves the platform on studies where a delay is survivable.
Which should you choose, by operator size and stage?
Small sponsor, one or two pivotal studies: licence. Spend the money on data management people rather than a platform, and revisit only when your portfolio changes shape.
Any sponsor with a licensed instrument carrying a primary endpoint on a filing enabling study: licence for that study specifically, whatever you do elsewhere. First time screen approval during enrolment is not a risk worth taking.
Mid sized sponsor running a repeating instrument set across five or more studies a year: build for the tail while licensing the pivotal work. Start with the instruments common to every protocol and one language pair, then widen as the portfolio demands.
Digital endpoint programmes combining sensors and questionnaires: build, and design the reconciliation between continuous and episodic data first. Splitting these across vendors means the reconciliation lands on you regardless, so you may as well own the design.
Decentralised trial sponsors where the app is the site: build, and put accessibility work in the first release rather than a later one. In a population over seventy it is real design effort with a direct effect on retention, and skipping it shows up immediately as falling compliance.
Contract research organisations serving many sponsors: build, and build multi study separation into the architecture from the start rather than retrofitting it. Your economics are the twentieth study, which is exactly the shape a per study vendor model cannot serve.
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. The document is yours whichever way you go.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Push notification opt-in rates vary sharply by category and platform (e.g., Business apps 56.7% Android / 46.3% iOS; Games 27.8% / 20.6%); average all-category retention was 28.29% at 1 day, 17.86% at 7 days, and 7.88% at 30 days, and apps sending onboarding messages saw 24% higher install-to-purchase conversion. Source: OneSignal (2024) →
- Google-commissioned research (conducted by Deloitte and 55) analyzing over 30 million user sessions across 37 leading European and American brand sites found that faster mobile site speed correlated with improved funnel progression, conversions, and average order value across retail, travel, luxury, and lead-generation verticals. Source: web.dev (Google Chrome team) / Milliseconds Make Millions (2020) →
- 48% of private companies cite integration with legacy systems or technical debt as a top obstacle to realizing the full value of their digital and AI investments (behind data quality/availability at 72% and gaps in AI fluency or technology talent/leadership at 53%). Source: Deloitte (2026) →
- Almost half of all the activities people are paid almost $16 trillion in wages to do in the global economy have the potential to be automated by adapting currently demonstrated technologies. Source: McKinsey Global Institute (2017) →
Frequently asked questions
What does it cost to move studies off Signant Health onto our own platform?
The cash cost is modest. The calendar cost is the migration approval queue, because your own screen presentation of each instrument needs review by the instrument owner, per instrument, per language, and sometimes per form factor.
Never migrate an in flight study. Move at protocol boundaries, start with the tail, and sequence approvals well before you need them. The data itself exports cleanly enough that it is rarely the constraint.
What if our vendor raises per study configuration pricing?
Per study pricing scales with your portfolio, so it grows exactly as your programme succeeds. That is the shape to model, rather than any single increase.
Add up three years of actual per study configuration spend and project it forward at your planned study count. If that curve crosses build plus 20 to 26 per cent annual maintenance within a few years, a repricing is not the problem, the pricing model is.
How long does a first eCOA release take?
Fourteen to twenty weeks for rendering, diary windows, offline capture, reminders, the site compliance view and the audit trail, in our delivery experience. The validation package runs alongside rather than afterwards.
The schedule risk is not engineering. It is instrument owner approval of your screen presentation, which is calendar time you cannot compress and which should start before the build does. Plan around that queue rather than hoping it moves.
Is Medidata Patient Cloud enough if we already use Medidata for data capture?
Often yes, and the integration advantage is real rather than marketing. Outcomes data reconciling with clinical data inside one vendor's estate removes a reconciliation feed you would otherwise build and validate.
The case changes if your endpoints combine sensors, app behaviour and questionnaires as one product, or if per study configuration across a large portfolio has become your biggest data collection line. Both are portfolio arguments that no single study comparison will surface.
Do we still pay instrument licence fees if we build our own platform?
Yes, in full. Instrument licence fees are paid to whoever owns the copyright on the questionnaire, quoted per study by that owner, and they are identical whether you build or licence a platform.
Get those quotes before you compare anything, because they are frequently a larger number than either option and they make the comparison honest rather than flattering to whichever side you already favour.
Should we support patient owned devices in the first release?
Usually not. A provisioned fleet is more logistics work and considerably less testing work, and it removes a whole category of support cases you cannot reproduce because you do not have the device.
Add patient owned device distribution once the platform is stable and you know which populations need it. Supporting hardware and operating system versions you do not control is a test matrix rather than a feature, and it is the second largest cost driver after language count.
How do we prove an entry happened when it claims to have happened?
Hold the device clock, the server clock and the drift between them, capture the time zone, reconcile at sync, and log refused attempts. The entry is timestamped at completion rather than at sync, and a subject must not be able to backdate it by changing the date on the phone.
Ask any developer this before signing. An answer that treats the phone as the source of truth means they have not thought about the subject who changes the date to complete a missed diary.
Who owns the app store accounts and the validation package?
You should, along with the repository and the infrastructure, agreed in writing before kickoff. At Digital Heroes all of it belongs to the client from the first commit.
The app store account matters more than people expect. A study app published under a supplier's account is a dependency you cannot unwind mid study. The validation package matters just as much, because without it a future partner starts qualification from zero and you inherit that cost by accident.
What does it cost to run a mobile app every month after launch?
Budget three buckets: store fees (Apple charges $99 a year, Google Play a one-time $25), hosting and infrastructure, and per-use services like maps, SMS, or payment processing. Across Digital Heroes client projects, a small production app runs $150 to $500 a month all-in before any new feature work. The number scales with usage, so ask your agency for a cost projection at 1,000 users and at 50,000, not just at launch.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
How do I vet a mobile app development agency before signing?
Ask for three apps they built that are live in the stores right now, then download them and read the recent reviews yourself. Ask exactly who will work on your project, because some agencies sell with senior staff and deliver with juniors or subcontractors, and request one past client you can call. An agency that stalls on any of those three requests is answering your question.
Is buying a template app from CodeCanyon cheaper than hiring a developer?
Upfront, yes: templates sell for $30 to $200 against tens of thousands for custom work, but the total cost often flips within the first year. Templates commonly arrive with outdated dependencies, no ongoing updates, and code you cannot inspect before buying, and heavy customization of someone else's codebase can cost more than building clean. They are fine as a throwaway prototype and a poor foundation for an app your revenue depends on.
Is custom software more secure than off-the-shelf SaaS?
Neither is secure by default; security tracks the practices of whoever builds and operates the system, not the model. SaaS gives you the vendor's certifications and patching but puts your data in a shared multi-tenant platform on their terms, while custom gives you full control over data residency, access rules, and compliance requirements like HIPAA, with the responsibility sitting with you and your agency. Before hiring anyone for a system holding sensitive data, ask for their security checklist: encryption at rest and in transit, an OWASP Top 10 review, role-based access, and a penetration test before launch.
Who owns the source code when an agency builds my app?
You should own the source code outright, and the contract must say it plainly with an intellectual property assignment that transfers ownership on final payment. Watch for agreements that only license the code to you, keep it in the agency's repository, or register the Apple and Google developer accounts under the agency's name. Insist on code delivered into a repository you control from week one, not at final handover.
Should I launch with an MVP or wait until the app feels complete?
Launch the minimum viable product, because no app is ever complete and real store reviews reshape a roadmap faster than any internal debate. In Digital Heroes delivery experience, a focused first release with five to eight core features runs 40 to 60% less than the founder's full wish list and ships months sooner. The discipline is choosing the one job the app must do perfectly and deferring everything else to updates.
What does app maintenance actually include after launch?
Four things: adapting to the major iOS and Android versions Apple and Google ship every year, updating third-party libraries before they break or go insecure, monitoring and fixing crashes, and keeping up with changing store policies. New features are not maintenance; they belong in a separate roadmap budget. An app that gets none of this usually starts visibly misbehaving within a year or two as operating system changes pile up.
Should I hire a freelancer or an agency to build my app?
A strong freelancer suits a small, tightly defined app where you supply the product direction and design references yourself; in the competing quotes Digital Heroes sees, freelance rates usually run $30 to $100 an hour. An agency earns its overhead when you need design, mobile, backend, and testing in one accountable team, and when the project cannot stall because one person disappears. A rough dividing line is $25,000 of scope: below it, a good freelancer is often the better buy.
Who can build a custom mobile app system?
Digital Heroes builds custom mobile app 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 mobile app 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.
Related guides
Published · Last updated .
