Genomics Pipeline Platform Development: Buy Terra or Seqera, or Build the Governance Layer?
Sample count and consent complexity decide this, and the threshold sits around 10,000 sequenced samples.
On this page
Sample count and consent complexity decide this, and the threshold sits around 10,000 sequenced samples. Below that, on stable pipelines with a single consent regime, buy: Terra, Seqera Platform or DNAnexus will serve you and a custom platform is capital spent on a governance problem you do not yet have. Above it, when you reprocess cohorts as reference builds and callers change and cannot attribute cloud spend to a project or a grant, build the layer above the executor. Note the shape of that answer: almost nobody in this category should build the execution engine.
When is off the shelf genuinely the right call here?
If you are a single laboratory processing a few hundred samples a year on stable pipelines, do not build. Terra is well suited to academic work in its ecosystem. Seqera Platform is genuinely excellent at Nextflow execution, monitoring and observability. DNAnexus brings a stronger compliance posture for regulated work. Illumina BaseSpace is convenient if you are entirely on Illumina instruments and content to stay there, and Velsera Seven Bridges covers similar ground. At that scale disciplined version control and a modest cloud bill get you reproducibility, and a platform to run a handful of workflows is a waste of scientific budget.
Buy and stop, too, if your pain is concentrated in execution rather than governance. If the complaint is that jobs fail silently, that retries are manual, or that nobody can see what is running, that is what these platforms are built for and they do it better than a first attempt would. Building a second orchestration layer alongside an under used one gets you two systems your bioinformaticians distrust.
Even at larger scale, keep the execution engine. This runs against our own commercial interest and it is still the right advice. Nextflow with Seqera, or a workflow description language with a solid runner, is not what you should rebuild. Workflow languages and executors are a solved problem with real communities behind them, and reinventing that is the most expensive mistake available in this category.
The honest test is whether anyone can tell you, without a meeting, what last quarter's cloud bill was spent on by programme. While the answer comes back quickly, you have not outgrown what you can buy.
When does a custom build actually pay off?
The signals are administrative rather than scientific, which is why they get noticed late.
You cannot decompose your cloud bill into compute for which pipeline on whose samples for which programme, so nobody can price a reprocessing decision and nobody can say no to one. You hold identifiable data under consent scopes your execution platform cannot express, meaning purpose limits, jurisdiction limits and withdrawals that have to propagate. Somebody asked you to reproduce an analysis from more than a year ago and it was hard. Two colleagues run what they believe is the same cohort query and get different sample counts. Or storage has become a monotonic line on the finance report because nobody can prove which intermediates are safe to delete.
The cause is structural. Execution platforms are built to run workflows reliably at scale, and they do. What none of them provides is the layer above execution: a record connecting a sample to a consent scope, to a versioned cohort definition, to a run with everything pinned, to a cost, to a storage lifecycle class. That layer is what turns a pile of sequencing output into an asset an organisation can govern, and at most institutions it is currently built by hand in tickets and spreadsheets.
The second trigger is portability. Workspace permissions and run history inside a commercial platform are not portable evidence. If you migrate platforms and a reviewer asks you to reproduce a finding from the old one, the platform's own history does not travel with you. That is worth noticing before an egress or licensing arrangement makes your data expensive to move, because at that point the platform has real bargaining power over your science.
How do they compare on the things that matter in this industry?
- Provenance depth. A workflow file in version control is the smallest part of reproducibility. You need resolved container image digests rather than tags, since a tag can be re-pushed, plus exact reference assembly files with checksums, the full parameter set including per sample overrides, and input file checksums. Platform run history records some of this to varying degrees and none of it in a portable form.
- Cost attribution. Some commercial platforms resell compute with a margin, so the unit economics are not yours to optimise. Others run in your account but attribute at platform level rather than per run, project or grant. Building that attribution costs roughly $32,000 and it is what makes anyone accountable for the bill.
- Consent modelling. Workspace permissions say who can enter a room. Consent scope says which samples may be used for which purpose by which requester, with effective dates, and it changes as participants withdraw. These are different concepts and no general execution platform models the second.
- Cohort versioning. A query is not a cohort. Without a versioned, citable object holding criteria, resolved sample list, consent decisions and timestamp, the same criteria resolve differently six months later and neither result is defensible.
- Storage lifecycle. Classifying every output at generation as raw and irreplaceable, derived and regeneratable, or published and immutable is what makes deletion authorisable. Lifecycle policy costs roughly $55,000 and often pays for itself inside a year.
- Data egress. Pulling large cohorts out of a platform or between regions produces charges that surprise people annually. A walled garden makes that worse by design, so ask about export cost before you commit, not after.
What does total cost of ownership look like at your scale?
From Digital Heroes delivery experience, a focused first release covering the run registry with full provenance pinning, executor integration, cost attribution and estimation, and consent aware sample selection runs $90,000 to $200,000 and ships in 12 to 20 weeks. A full platform adding versioned cohort management, storage lifecycle policy, re analysis planning, controlled access auditing and metadata harmonisation runs $250,000 to $650,000 phased over 8 to 14 months.
A worked shape: a research institute holding roughly 40,000 sequenced samples came in at $154,000 for a first release in about 17 weeks, split across discovery and workflow inventory at $16,000, run registry with pinned versions at $38,000, executor integration at $34,000, cost attribution at $32,000 and consent linked access control at $34,000. Phase two took it to $519,000 across about 13 months.
Then there is the number that dominates the business case and appears in no build quote. Cloud compute and storage runs $40,000 to $400,000 or more a year depending on cohort size and reprocessing frequency, and in the programmes we have costed it passes the build cost somewhere between year one and year two. Software maintenance is a comparatively contained 15 to 20 percent of build cost annually. Reference build and caller transitions are reprocessing programmes with their own compute bills and should be planned as projects with budgets, not as background work.
That ratio is the whole argument. The platform is not competing with a subscription; it is competing with an unattributed cloud bill that will exceed it. Model five years of compute and storage under your real reprocessing habits before anyone quotes you, because that model, not the build number, is what the decision rests on.
What does the hybrid look like, and when is it the honest answer?
In this category the hybrid is not a compromise, it is the recommendation for essentially every organisation that builds anything. Keep the execution engine. Build the governance, provenance and cost layer above it, and treat the engine as swappable.
The boundaries are unusually clean. The workflow language and executor own submission, scheduling, retries and monitoring. The custom layer owns the run registry, consent scoped sample selection, versioned cohorts, cost attribution and storage lifecycle. The interface between them is a job submission with enforced tagging on the way out and a completion record with resolved digests and checksums on the way back. Nothing in that requires the platform vendor's cooperation, which is exactly why the layer survives a change of platform and why the evidence it holds is portable in a way the platform's own history is not.
The smallest useful version is the run registry plus cost attribution, without cohorts, lifecycle or a self service interface. Those two capabilities pay for themselves fastest and they make every later decision cheaper to argue, because from that point on a reprocessing proposal arrives with a number attached. Add consent scoped selection second if you hold identifiable data, since that is usually the compliance argument that funds the rest. Leave cohort versioning and lifecycle policy to phase two, with one exception: if storage is already your dominant cloud line, pull lifecycle forward, because it is the rare feature that reduces its own cost.
Registry before orchestration is the other staging rule worth stating. Recording what ran, with what versions and at what cost, delivers most of the value and can precede any change to how jobs are actually submitted, which means the bioinformatics team does not have to stop work while you build.
Which should you choose, by operator size and stage?
Single laboratory, a few hundred samples a year, one stable pipeline: buy, and spend the difference on sequencing. Terra or Seqera Platform will cover you and nothing else on this page applies yet.
Core facility or small biotech under roughly 10,000 samples, single consent regime: buy, then measure two things. How long it takes to answer what last quarter's compute was spent on by programme, and how long it would take to reproduce a result from eighteen months ago. If both are quick, keep configuring.
Above roughly 10,000 samples with regular cohort reprocessing: build the registry and cost attribution layer. This is the population where an unattributed bill has become an ungoverned one and where reprocessing decisions get quietly deferred because nobody can price them.
Anyone holding identifiable data under multiple consent regimes or data use agreements: build the consent scoped selection layer regardless of sample count. Bridging workspace permissions to consent scope by hand is how a well meaning analyst assembles a cohort they should not have, and no execution platform is designed to prevent it.
Clinical or regulated use rather than research: build, and budget for validation documentation as its own work package. The provenance requirements are stricter, the retention period is longer, and retrofitting either onto a research grade setup costs more than doing it once.
Federated or multi site consortia: build, and settle the architecture question before the budget. Data that cannot leave its jurisdiction turns a straightforward analysis into a distributed one, and that decision has a larger price attached than any feature on this page.
When you are ready to turn this into a specification, 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 can take that specification to any other firm on your shortlist.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- The average developer spends more than 17 hours a week dealing with maintenance issues such as debugging and refactoring, and about four of those hours on 'bad code' - waste that equates to nearly $85 billion annually worldwide in opportunity cost. Source: Stripe (2018) →
- Retailers improving Core Web Vitals saw measurable gains: Vodafone improved LCP by 31% for 8% more sales, Lazada saw a 16.9% mobile conversion increase, and Cdiscount saw a 6% Black Friday revenue uplift. Source: web.dev (Google Chrome team) (2021) →
- EMARKETER reports that over 54% of mobile commerce transactions now happen within shopping apps rather than mobile browsers, underscoring the app channel's growing dominance of m-commerce. Source: EMARKETER (2025) →
- PMI's Pulse of the Profession research found organizations waste an average of roughly 9.9% of every dollar invested in projects due to poor performance - equivalent to about $1 million wasted every 20 seconds collectively worldwide. Source: Project Management Institute (PMI) (2018) →
Frequently asked questions
What does it cost to move off Terra, DNAnexus or Seqera later?
The workflows themselves usually travel, because a workflow language is portable by design. What does not travel is run history, workspace structure and any provenance the platform recorded in its own format, so results produced before the migration become harder to reproduce afterwards.
The other cost is egress. Pulling large cohorts out of a platform or between regions produces charges that surprise people, and it is worth pricing before you commit rather than at the point of leaving. A governance layer that holds provenance in your own accounts makes the switch a compute exercise rather than an evidence problem.
What happens if our platform vendor changes its pricing or compute margin?
Model it against your projected cohort size and reprocessing frequency rather than today's, because reprocessing is a scientific decision that tends to increase. Platforms that resell compute with a margin mean the unit economics are never yours to optimise, so spot and preemptible capacity savings may not reach you.
Running in your own cloud accounts with enforced tagging changes the negotiation, because you can see exactly what you would be paying elsewhere. It does not remove the bill, and we would not pretend it does, but it turns a repricing into a comparison rather than an announcement.
How long does a genomics platform layer take to build?
About 12 to 20 weeks for a first release covering the run registry, executor integration, cost attribution and consent aware access, in Digital Heroes delivery experience. A full platform runs 8 to 14 months in phases.
The gate is rarely engineering. It is agreement between bioinformatics, research leads and compliance on what constitutes a reproducible run: what must be pinned, how long results must stay reproducible, and what happens when an upstream dependency is deprecated. Those conversations determine the registry schema, so they cannot happen afterwards.
Is Seqera Platform enough on its own for a large institute?
For execution, yes, and we would keep it. Nextflow execution, monitoring and observability at scale is what it is built for and it does that well.
Where it stops is above execution. It does not model consent scope with effective dates, it does not make a cohort a versioned citable object, and it does not attribute cost back to a grant in a form your finance office will accept. Those are governance concerns rather than execution concerns, and a platform that solved them for you would be making assumptions about your consent regime that would not hold.
Can we delete intermediate files safely to cut storage cost?
Yes, if the environment that produced them is pinned. Classify every output at generation as raw and irreplaceable, derived and regeneratable, or published and immutable, then attach an expiry to the regeneratable class.
Because the registry stores container digests, reference checksums and parameters, regenerating a deleted intermediate becomes a defined operation rather than a gamble, which is what makes deletion authorisable. Without that provenance nobody signs off on deletion, and you keep paying to store the same information several times over.
How do we enforce participant consent when the platform only has permissions?
Put a consent aware selection layer in front of data selection rather than trying to express consent as folder permissions. Samples carry consent scope with effective dates, a cohort request declares a purpose, and the system returns only the samples permitted for that purpose at that moment while recording the decision so it can be replayed later.
Withdrawal has to propagate as well: a withdrawn participant disappears from future cohorts and generates a task list for derived data already produced. That behaviour is the compliance argument that funds most builds in this category.
Should we build our own workflow engine or orchestration?
No, and this is the clearest advice on the page even though it reduces the size of a project we could quote. Adopt an established workflow language and executor. That community solves problems you would otherwise pay to rediscover, and using one removes a large slice of the executor integration line from your build.
Build the layer above it. If a developer proposes writing orchestration from scratch, treat that as a signal about the rest of their judgement rather than as an ambitious plan.
Who owns the code and the cloud accounts if we hire an agency?
The platform should run in your own cloud accounts, and you should own the repository plus an unrestricted right to hire another firm, written into the contract before kickoff. At Digital Heroes the client owns the code from the first commit.
This matters more here than in most categories, because egress charges and platform dependency give whoever holds the billing relationship real influence over research decisions. That influence should sit with the people responsible for the science, not with a supplier.
How long does it take from first call to software my team can actually use?
Plan for four to six months: two to three weeks of discovery, two to four weeks of design, then a 10 to 16 week build with testing. In Digital Heroes delivery experience the schedule killer is not engineering speed but decision lag; a client who takes two weeks to approve wireframes adds two weeks to launch. Book a weekly 30-minute decision slot before kickoff and most of that risk disappears.
Is it cheaper to customize Salesforce than to build a custom CRM from scratch?
If you use less than a third of what Salesforce does, a custom CRM is often cheaper by year three. Salesforce Enterprise lists at $165 per user per month, so 25 seats cost about $49,500 a year before admin and consultant fees, while a focused custom CRM runs $60,000 to $100,000 once plus 15 to 20% a year in maintenance. If you genuinely need Salesforce's ecosystem, reporting, and app marketplace, customizing it beats rebuilding it; the mistake is paying enterprise prices to use it as a glorified contact list.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
Will an app built for 10 users survive growing to 500?
Yes, if it is built on standard cloud infrastructure with a sound data model, because moving from 10 to 500 users is a hosting configuration change, not a rebuild. The scaling decisions that actually hurt are made early and invisibly: how the database is structured, how accounts and permissions are modeled, and whether background work is queued properly. Ask your agency how the system would handle ten times the load; the right answer is boring and specific, and a promise to cross that bridge later means you will pay for the bridge twice.
How do we get years of data out of our old system and into the new one?
Treat migration as a planned sub-project: a field-mapping document, at least one dry run on a copy of your data, then a cutover with the old system kept read-only for 30 days as a safety net. On Digital Heroes projects it consumes 10 to 15% of the budget when the old system has an export, and more when data must be pulled out screen by screen. Ask any vendor to walk you through their last migration before you sign.
How much should a small business expect to pay for custom software?
Across 2,000+ Digital Heroes projects, a small business system that replaces spreadsheets or one core workflow typically lands between $40,000 and $80,000, with more complex first versions running up to $150,000. The two levers that move the number most are integrations and user roles, not the team's hourly rate. Any quote under $15,000 for a full production system means the vendor has not understood your scope yet.
How do I work out whether custom software will pay for itself?
Do the arithmetic on hours before anything else: if the system saves three staff eight hours a week at a $35 loaded hourly cost, that is about $43,700 a year against, say, a $70,000 build plus 15 to 20% annual maintenance, a payback around two years. Add revenue effects only if you can name them specifically, like faster quotes or fewer abandoned orders, not as vague growth. In our delivery experience the businesses that see payback inside 24 months are the ones automating a process they already measure.
What is the biggest mistake first-time software buyers make?
Choosing the lowest quote without asking why it is the lowest. A bid 40% under the field usually gets there by skipping tests, documentation, and code review, which are invisible in a demo and brutal to pay for later; every stalled project Digital Heroes has been asked to rescue tells some version of that story. The second mistake is signing without a written scope, which reliably turns the winning cheap quote into 1.5x to 2x the price by launch.
Who can build a custom software system?
Digital Heroes builds custom 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 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.
Related guides
Published · Last updated .
