What makes one production-ready
Every internal app builder will produce a convincing first screen. Whether one is production-ready for you depends on four things a demo will not show: who owns the data and how it comes back out, whether the access policy also binds automations and agents, how a change reaches production and how it is undone, and who is able to make that change in a year.
Load-bearing sooner than planned
An internal tool becomes load-bearing faster than anybody plans for. Once a team's day depends on it, every question skipped during evaluation — export, permissions, deployment, ownership — becomes urgent at the same moment, and usually during an incident.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
The first app was easy, the second one is bespoke
Every integration after the demo needs custom work, and the speed advantage that won the evaluation quietly disappears.
-
Production is edited directly
There is no environment, no review and no way back, on a system a team now depends on to do its day.
-
External workflows need a second product
The builder covers internal screens, and anything customer-facing is a separate purchase with a separate identity model to keep in step.
-
Agents and automations bypass the policy
They run with elevated rights because scoping them properly was never supported, so the tightest permission in the system is the one a machine ignores.
-
Cost is a conversation, not a formula
You cannot model next year's bill from published rules, which means you cannot plan for it — you can only find out.
Six questions, and what a thin answer sounds like
Ask these in the evaluation, not after. "A thin answer sounds like" is what you hear when a platform has not solved it yet — including, in the last row, from us.
| What you are deciding | A thin answer sounds like What to listen for | Bondi's answer What is actually included |
|---|---|---|
| Where does the data live, and how do we get it out? | "You can use our API." | A dedicated PostgreSQL database per environment, with data import and export, and a full SQL export of it on Pro |
| Does the access policy bind automations and agents? | "Automations run with admin rights." | Service Accounts on Pro give machine identities their own scoped access under the same permission model |
| How does a change reach production? | "You edit it and it is live." | Development → Production publishing, with approvals, version history and restore on Pro |
| What does an external user cost? | "They need a seat." | External Portals on Pro, with no Portal-count or external-user seat limit |
| What does it cost when usage grows? | "Talk to sales." | Published metering: max(1, ceil(billable Actions / 20)), $0.02 per extra Production Run from the Wallet, and stackable capacity packs |
| What is not included? | Silence. | SSO and SCIM are not available yet; they are next on the identity roadmap. There is no live Postgres connection string — the Pro capability is a full SQL export, and BI read replicas are Enterprise. MCP is in controlled beta and enabled workspace by workspace. Custom domains and full white-labeling are not currently included. There are no published customer references yet. |
"A thin answer sounds like" describes a category of answer, not a specific vendor. The last row applies the same test to Bondi.
How to evaluate it
Five steps, in order. Each one produces something you can put in front of other people rather than an opinion you have to defend.
- 01
Prototype a whole workflow, not a screen
Permissions, an exception path, a live integration, and one real change published to production. A CRUD screen proves nothing that will matter in month six.
- 02
Test the export before you test the features
Ask for your data back in a form you could load somewhere else. The answer tells you what the rest of the relationship is going to look like.
- 03
Ask what the machines are allowed to do
Human and machine identity should share one policy. Two policies means one of them is wrong, and it is usually the one nobody reviews.
- 04
Make them show you a rollback
Not a backup — a specific change, published, then undone, with the system still working afterward.
- 05
Check it against a published standard
OWASP's Application Security Verification Standard gives you access-control, session and logging requirements to test against, which is a better checklist than the one the vendor supplies.
Where this leaves Bondi
Where Bondi fits
Bondi puts the Builder, applications, data, workflows, agents, integrations, portals and the deployment controls in one platform, on a database you own. The controls that decide production readiness — record- and field-level permissions, Service Accounts, external Portals, Development → Production publishing with version history and version restore, and MCP in controlled beta — are all on Pro.
- The 30-day trial runs Pro capabilities on Standard quotas for up to 3 users, with no card, so the controls can be tested before the decision
- $24 per seat per month on Standard and $49 on Pro, with a three-seat minimum
- Audit history for 90 days on Standard and 365 days on Pro
The other half of the answer
When Bondi is the wrong answer
- You need one throwaway internal screen and nothing after it
- SSO or SCIM is a requirement today — neither is available yet
- The tool has to run inside your own network
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Is speed the right selection criterion?
It is a real one, and it is not the deciding one. Time-to-first-screen is easy to measure and easy to win. Time-to-safe-change is the number you live with.
What should a proof of concept include?
One complete workflow: permissions, an exception path, a live integration, and one screen or workflow change published to production and then restored to its previous version. A platform that cannot do all four has told you something a feature list would have hidden.
How do we compare cost fairly?
Only against published rules. Bondi publishes its seat prices, the max(1, ceil(billable Actions / 20)) Run formula, the $0.02 over-capacity rate and the capacity packs, so you can model your own busiest month before buying rather than after.
Can we try the production controls before paying?
Yes. The 30-day trial runs Pro capabilities on Standard quotas for up to 3 users, with no card, and that includes the permission and publishing behavior rather than only the screen builder.
Sources
- OWASP — Application Security Verification Standard checked 2026-08-03
Claims about third-party products are limited to what these documents state on the date shown. Where a document is silent, this guide describes the product's design center rather than asserting a limit.