Our pick · Verified 18 August 2026
Emergent — you own the code, and the free tier is enough to evaluate
Free tier · Standard from $17/mo annual
Two things separate Emergent for research use. You own the generated code and can host it anywhere, with GitHub integration — which matters enormously when the tool outlives the person who made it and someone else has to maintain it. And 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-handling rules before you build → — The single most important constraint: do not put participant data into a tool built this way without your DPO and ethics committee in the loop 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
- These tools turn a natural-language description into a working, deployed application — front end, database and hosting included.
- Emergent: Free (10 credits/mo), Standard $17/mo annual (100 credits), Pro $167/mo annual (750 credits, 1M context, custom agents), Enterprise custom. Verified 18 August 2026.
- The sweet spot is genuinely small internal tools. Anything handling identifiable participant data, or anything regulated, is out of scope without proper review.
- Code ownership is the question to ask first. A tool you cannot export becomes a dependency your group cannot maintain or leave.
- Budget maintenance time. Generated code is real code and needs updating, backing up and eventually handing over.
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 |
The Enterprise tier is the only one offering SSO, role-based access control, audit logs and VPC deployment — which are precisely the controls an institutional IT review will ask about for anything holding real data.
What these tools are genuinely good for
The realistic use case is the backlog of small internal tools that every research group has and none of them ever build, because each is a week or two of work and there is no week or two available.
Shared equipment booking. The perennial one. A calendar 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 that nobody trusts.
Sample and inventory tracking. Location, freezer, box, position, aliquot count, chain of custody. The default is a spreadsheet with a version-conflict problem and one person who understands it.
Internal request forms with a workflow attached. Core facility service requests, reagent ordering, access requests — anything currently living in an email thread with no status visible to the requester.
Reading dashboards over data you already have. A view of recruitment progress by site, or spend against budget, pulled from a source of truth that already exists.
Small public-facing pages with a form. Study information plus an expression-of-interest capture — provided the eligibility screening does not collect sensitive detail, on which see below.
The common shape: a handful of screens, a straightforward data model, a small known set of users, and no regulatory obligation attached. That is where this technology genuinely earns its place.
The data rules that are not optional
The failure mode with these tools is not that the code is bad. It is that they make it trivially easy to build something that should never have existed, 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, where human subjects are involved, your ethics committee having reviewed it. This is not a formality. You are 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 yourself and nobody audited. If it holds health data it may fall under HIPAA or GDPR special-category rules. If the study protocol specifies where data is held, building a shadow system outside that specification is a protocol deviation.
Assume institutional IT will need to review it before it touches anything on the network or handles institutional credentials. Better to involve them early than to be told to switch it off after the group has come to depend on it.
Check where data is stored. Default hosting may be outside your jurisdiction. For EU and UK institutions that is a transfer question with a documented answer required. Note that self-hosted database and VPC deployment are Enterprise-tier features here — the lower tiers do not give you that control.
Watch what goes into the prompt. Describing your application to a hosted model means the description reaches a third party. Do not paste real participant records, credentials, unpublished results or anything under an NDA into a build prompt.
The safe pattern that keeps almost all the value: build tools that handle operational data — bookings, inventory, equipment, workflow status, de-identified aggregates — and keep identifiable participant data in the systems already approved for it. That covers most of the backlog without touching the governance problem at all.
Where these tools fall down
Complexity has a ceiling, and you find it suddenly. 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 through it — it usually means the problem has outgrown the approach.
You are responsible for the security of what you deploy. Generated applications can and do ship with weak authentication, permissive access rules or exposed endpoints. If the tool holds anything that matters, it needs a security review by someone qualified, and “the AI wrote it” is not a mitigation anyone will accept.
Nothing here is validated. Anything falling under GxP, 21 CFR Part 11 or a similar regime needs a validated system with documented evidence. A generated application is not that, and cannot be made into one retrospectively.
Credits are consumed by iteration. The published allowances sound generous until you spend an afternoon refining. Build the important thing first rather than exploring at full price.
Maintenance is real and lands on you. Dependencies age, security patches are needed, requirements change. The postdoc who built it will leave. Decide in advance who maintains it and where the code lives — which is the practical reason code ownership and GitHub integration matter more than any feature on the list.
A sensible way to go about it
- Write the requirement down first, in a paragraph, before touching the tool. Who uses it, what they do, what data it holds, what happens to that data. This is also exactly what your DPO will ask for.
- Classify the data before you build. Operational data, go ahead. Anything identifiable or special-category, get review first.
- Build the smallest useful version. Resist the temptation to specify everything at once; the first version’s job is to tell you whether the approach fits.
- Test with real users early, which in practice means the lab manager or coordinator who will actually live in it.
- Export the code and put it in a repository the group controls, on day one rather than when someone leaves.
- Write down who maintains it and add it to the group’s handover documentation.
- Set a review date. If nobody has used it in six months, retire it rather than leaving an unmaintained application holding data.
Build one small thing on the free tier first
Ten credits a month is enough to build a real internal tool and discover whether this approach suits your problem. Start with something operational — a booking system or an inventory tracker — where the data governance question does not arise.
Free tier · Standard from $17/mo annual
Build free on Emergent Opens on the vendor’s site · CASRAI referral link
Frequently asked questions
What is an AI app builder?
A platform that turns a natural-language description of an application into a working, deployed system — user interface, database and hosting — through conversation rather than drag-and-drop or hand-written code. Emergent, for example, produces applications you own the code to and can host anywhere.
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 with SSO, RBAC, audit logs and VPC deployment. Verified 18 August 2026.
Can I use an AI app builder for participant data?
Not 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, with access controls nobody audited. If your protocol specifies where data is held, building outside that is a protocol deviation. Keep identifiable data in approved systems and use these tools for operational data instead.
What can research groups realistically build with these?
Equipment booking systems, sample and inventory trackers, internal request forms with a workflow, reading dashboards over existing data, and small public pages with a non-sensitive enquiry form. The shape that works is a handful of screens, a simple data model, a known set of users, and no regulatory obligation attached.
Do I own the code an AI app builder generates?
With Emergent, yes — you own the generated code, can push it to GitHub and can host it anywhere. This varies by vendor and is the first thing to check, because a tool you cannot export becomes a dependency your group can neither maintain nor leave when the person who built it moves on.
Are these tools 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 is not that and cannot be retrofitted into it. Use a purpose-built regulated system for those requirements.
