Verdict · Verified 18 August 2026
Emergent — you own the code, and the free tier is enough to evaluate properly
Free tier · Standard from $17/mo annual
Code ownership is the feature that matters most and it is the one buyers overlook. Emergent generates applications you own and can host anywhere, with GitHub integration — which is what determines whether a tool survives the postdoc who built it leaving. The free tier gives 10 credits a month, enough to build something real and find out whether this approach suits your problem before spending anything. Standard is $17/month billed annually.
Build free on Emergent Opens on the vendor’s site · CASRAI referral link
Read the data rules before you build → — The one hard constraint: do not put identifiable participant data into a tool built this way without your DPO and ethics committee reviewing it first.
Editorial disclosure: CASRAI has commercial referral arrangements with some of the vendors named on this page, and may earn a commission if you subscribe to them. We name them here regardless of whether a link is present. We only recommend tools our editorial team has independently researched. Read our full disclosure policy.
In summary
- Free $0/mo (10 credits) · Standard $17/mo annual (100 credits) · Pro $167/mo annual (750 credits, 1M context, custom agents) · Enterprise custom. Verified 18 August 2026.
- You own the generated code and can host it anywhere; GitHub integration is on every tier.
- SSO, RBAC, audit logs, self-hosted database and VPC deployment are Enterprise-only — which is what an institutional IT review will ask about.
- Credits are consumed by iteration, not just by building. Refining eats them faster than expected.
- Suitable for operational data. Not suitable for identifiable participant data or anything regulated.
Emergent plans
Verified from the vendor site, 18 August 2026. Prices shown are annual billing.
| Dimension | Free | Standard | Pro | Enterprise |
|---|---|---|---|---|
| Price / month | $0 | $17 | $167 | Custom |
| Credits / month | 10 | 100 | 750 | Negotiated |
| You own the code | Yes | Yes | Yes | Yes |
| GitHub integration | Yes | Yes | Yes | Yes |
| Context window | Standard | Standard | 1M | 1M |
| Custom AI agents | No | No | Yes | Yes |
| SSO / RBAC / audit logs | No | No | No | Yes |
| Self-hosted DB / VPC | No | No | No | Yes |
No credit card is required for the free tier. The controls an institutional IT review asks about — SSO, role-based access control, audit logs, data residency — are Enterprise-only, which is the constraint most likely to matter for anything holding real data.
Why code ownership decides this
Most evaluations of these platforms compare output quality. For a research group the more consequential question is what happens in eighteen months.
The tool gets built by a postdoc or a PhD student, because they are the person with both the need and the willingness. It works, the group comes to depend on it, and then they finish and leave. If the application exists only inside a vendor’s platform, under an account tied to a departed person, on a subscription nobody remembers approving, the group has a dependency it can neither maintain nor exit. This is not hypothetical — it is the standard life cycle of research software, and it is why so many groups end up back on a spreadsheet.
Emergent generates code you own and can host anywhere, with GitHub integration on every tier including free. That changes the failure mode: even if the subscription lapses and the author leaves, the code is in a repository the group controls and any competent developer can pick it up.
Act on this from day one rather than at handover. Export the code into a group-controlled repository as soon as the first working version exists, and write down who maintains it in the group’s handover documentation. It takes ten minutes and it is the difference between a tool and a liability.
What it is genuinely good for
The realistic use case is the backlog every research group has and none of them clear: small internal tools, each a week or two of work, with no week or two available.
Shared equipment booking with per-instrument rules, a training-requirement flag and usage reporting for the facility manager. Most groups run this on a wall planner or a shared calendar nobody trusts.
Sample and inventory tracking — location, freezer, box, position, aliquot count. The default is a spreadsheet with a version-conflict problem and one person who understands it.
Internal request forms with a workflow — core facility service requests, reagent ordering, access requests — replacing an email thread with no status visible to the requester.
Reading dashboards over data that already exists: recruitment progress by site, spend against budget.
The shape that works: a handful of screens, a simple data model, a known set of users, and no regulatory obligation attached. Notice that all of these handle operational data — bookings, equipment, inventory, workflow status — which is exactly the category that avoids the governance problem below.
What you must not build with it
The risk with these platforms is not that the code is bad. It is that they make it trivial to create something that should not exist, and to have it live within an afternoon before anyone with governance responsibility has seen it.
Do not put identifiable participant data into a tool built this way without your data protection officer and, for human-subjects research, your ethics committee reviewing it first. You would be creating a new processing system on infrastructure your institution has not assessed, quite possibly in a jurisdiction nobody has checked, with access controls you configured and nobody audited. If it holds health data it may engage HIPAA or GDPR special-category rules. If your study protocol specifies where data is held, building a shadow system outside that specification is a protocol deviation.
Note the tier constraint that makes this concrete: SSO, role-based access control, audit logs, self-hosted databases and VPC deployment are Enterprise-only. Those are precisely the controls an institutional IT review asks about. On the Free, Standard and Pro tiers you do not have them, which effectively settles the question for anything sensitive.
Watch what goes into the build prompt too. Describing your application to a hosted model sends that description to a third party. Do not paste real participant records, credentials, unpublished results or anything under an NDA into it.
Nothing here is validated. Anything under GxP, 21 CFR Part 11 or a comparable regime requires a validated system with documented evidence, and a generated application is not that and cannot be retrofitted into it.
Where it falls down
Complexity has a ceiling, and you hit it abruptly. The first version arrives impressively fast; successive changes get harder, and there is a characteristic point where asking for one more feature starts breaking two others. Recognise that point rather than fighting it — it usually means the problem has outgrown the approach and needs a real developer.
Credits go on iteration, not creation. Ten credits a month on the free tier sounds generous until you spend an afternoon refining wording and layout. Build the important thing first and explore later; the allowance rewards knowing what you want.
Security of what you deploy is yours. Generated applications can ship with weak authentication, permissive access rules or exposed endpoints. If the tool holds anything that matters, it needs review by someone qualified, and “the AI wrote it” is not a mitigation anyone will accept.
Maintenance is real. Dependencies age, security patches are needed, requirements change. Budget for it, or accept that the tool has a shelf life and set a review date — if nobody has used it in six months, retire it rather than leaving an unmaintained application holding data.
Institutional IT will want a say before it touches the network or handles institutional credentials. Involve them early rather than being told to switch it off after the group depends on it.
Build one operational tool on the free tier
Ten credits a month is enough to build something real. Start with a booking system or an inventory tracker — operational data, where the governance question does not arise — and export the code to a group repository as soon as it works.
Free tier · Standard from $17/mo annual
Build free on Emergent Opens on the vendor’s site · CASRAI referral link
Frequently asked questions
How much does Emergent cost?
Free at $0/month with 10 credits, Standard at $17/month billed annually with 100 credits, Pro at $167/month annually with 750 credits plus a 1M context window and custom agents, and Enterprise at custom pricing. No credit card is required for the free tier. Verified 18 August 2026.
Do I own the code Emergent generates?
Yes — you own the generated code, can push it to GitHub and can host it anywhere, on every tier including free. This is the most important feature for a research group, because it determines whether the tool survives the person who built it leaving.
What can a research group realistically build with it?
Equipment booking systems, sample and inventory trackers, internal request forms with a workflow, and reading dashboards over data you already have. The shape that works is a handful of screens, a simple data model, a known set of users, and no regulatory obligation attached.
Can I build a tool that holds participant data?
Not without your data protection officer and, for human-subjects research, your ethics committee reviewing it first. You would be creating a processing system on unassessed infrastructure with access controls nobody audited — and SSO, role-based access control, audit logs and VPC deployment are Enterprise-only, so lower tiers lack the controls an IT review expects.
What happens when the person who built the tool leaves?
That depends entirely on whether you exported the code. Do it as soon as the first working version exists — push it to a repository the group controls and record who maintains it in the handover documentation. Ten minutes then prevents the standard research-software failure where a working tool becomes an unmaintainable dependency.
Is Emergent suitable for regulated or validated systems?
No. Anything under GxP, 21 CFR Part 11 or a comparable regime requires a validated system with documented evidence of validation for its intended use, and a generated application cannot be retrofitted into that. Use a purpose-built regulated system for those requirements.
