Pick the shape before you pick the vendor
Each of these is genuinely good at something. Boards make work visible. Bases make structured work easy to reshape. An ERP standardizes the processes that should be standard. Custom software has no ceiling. Bondi is for company-specific operations that need production-grade data, permissions and change control without a ground-up build. Choosing the wrong shape costs far more than choosing the wrong vendor inside the right one.
Why the shape decision is the expensive one
Most system decisions get argued at the vendor level — this tool or that one — when the costly mistake happens one level up. A board tool asked to hold a relational operation, or an ERP asked to hold a differentiated one, does not fail on day one. It fails in month nine, once the data is already in it and the workarounds have been built around it.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
One team needs flexibility and another needs control
Sales wants to change the fields this week; finance needs last quarter to still add up. A single tool that satisfies both is rare, and picking one usually means the other team quietly builds a spreadsheet.
-
Internal work and external access share one dataset
Customers, suppliers or subcontractors need to see and do something on the same records your team works on. That requirement quickly outgrows a share link, and it is the point where the shapes diverge most.
-
The process changes faster than the system can
You know how you want to work next quarter, and the honest estimate for changing the system is longer than the quarter.
-
Point tools have created duplicate identifiers
The same customer has three IDs across three tools, and somebody reconciles them. Every extra tool adds another mapping to maintain.
-
Nobody can name the system of record
Ask where the authoritative version of an order lives and you get a discussion rather than an answer. That is a shape problem, not a configuration problem.
What each shape is built around
Read the option you are considering, then read the "Where it stops" row twice. Every shape has a breaking point, including this one.
| What you are deciding | Work boards Built around visible work | Flexible bases Built around reshapeable tables | ERP module Built around a standard process | Custom software Built around your specification | Bondi Built around a database you own |
|---|---|---|---|---|---|
| The unit it revolves around | An item moving through a pipeline | A record in a base you can reshape | A document in the vendor's schema | Whatever you specify | A row in a relational schema other objects point at |
| Strongest when | Coordination is the job and everyone may see everything | The structure is still being discovered | The process should match the industry standard | The software itself is the product you sell | The operation is specific to you and keeps changing |
| Where the data sits | Inside the product, reachable through its API | Inside the product, reachable through its API | In the vendor's database, on the vendor's model | In a database you build and maintain | A dedicated PostgreSQL database per environment, with import and export |
| How access is scoped | By container, with item-level rules on enterprise tiers | By container and field, with record filters set per interface | Deeply, and configured by a specialist | However you build it | Role, screen and action on Standard; record and field on Pro |
| What an external user costs | Often free guest access on mid-tier plans, scoped to whole shared boards | A seat, a free read-only share, or a paid portal add-on | Usually a separate portal product | A second application to build | Nothing per identity on Pro — no Portal-count or external-user seat limit |
| How a change reaches production | Applied to the live board | Applied live, or staged in a sandbox on higher plans | Through a customization cycle | Through a developer and a release | Published from Development to Production, with version history and restore (Pro) |
| Where it stops | When one object has to be authoritative across many boards | When base boundaries stop matching business boundaries | When the process is the thing you compete on | When the backlog is forms and rules rather than novel behavior | When nobody inside the company will own the system |
A comparison of design centers, not a feature scorecard. Where this site states a specific third-party behavior, it is limited to that vendor's own documentation and the date noted in Sources.
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
Score four dimensions, not a feature list
Data complexity, workflow variability, permission depth, and external access. A feature checklist is always won by whoever wrote the checklist; these four are the axes on which the five shapes actually differ.
- 02
Assign a system of record object by object
Customer, order, invoice, item, shipment — one owner each, written down. "One system for everything" is a slogan. The useful version is a clear boundary per object, with an integration across it.
- 03
Separate the standard from the differentiated
The parts of your operation that look like everyone else's belong in something standard and supported. The parts that do not are the entire reason a platform exists.
- 04
Prototype the exceptions, not the happy path
All five options handle the happy path in a demo. Take the rush order, the partial delivery, the client on different terms, and run those.
- 05
Ask who changes it in month nine
Each shape has a different answer — anyone, a specialist, a developer, a partner — and that answer determines the real cost of ownership more than the license line does.
Where this leaves Bondi
Where Bondi fits
Bondi sits between the flexible work tools and a bespoke or heavily customized enterprise system. The data model, screens, permissions, workflows, APIs and agents are built together and versioned together, on a PostgreSQL database you own. It is not a board tool, and it does not ship an industry's standard modules.
- A dedicated PostgreSQL database per environment, with data import and export
- Automation metered as max(1, ceil(billable Actions / 20)), published so you can model it yourself
- External Portals, record- and field-level permissions and Development → Production publishing on Pro
The other half of the answer
When Bondi is the wrong answer
- A shared board genuinely covers the work, and the process is not going to change
- You need packaged software with your industry's statutory forms already in it
- The software itself is the product you sell
- Nobody inside the company will own the system after launch
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Does Bondi replace an ERP?
Sometimes, for a bounded operational domain. Often it should not. A finance or manufacturing ERP can stay the system of record for the authoritative transactions while Bondi runs the differentiated workflows around it.
Can Bondi run alongside monday.com or Airtable?
Yes. monday.com is a built-in provider with typed actions and triggers; Airtable is reached through the HTTP node or a custom integration against its API. Either way, a coordination tool can stay in place for the job it does well while Bondi owns the data and the workflows that need tighter control.
Which of the five is cheapest?
Over one year, usually a board or a base — lowest license cost, shortest setup. Over three, usually whichever option your own team can change without hiring someone, because that is the cost that repeats. The seat price is the easiest number to compare and the least likely to decide it.
What if we choose wrong?
Weight your decision toward the option whose data you can get back out. Bondi runs on a dedicated PostgreSQL database with data import and export, and an owner-level SQL export of the whole thing on Pro — which is precisely what makes it survivable to be wrong.
Sources
- monday.com — Automations and integrations pricing checked 2026-08-03
- monday.com — Pricing for guests checked 2026-09-25
- monday.com — Board permissions on Enterprise (item visibility by creator or assignee) checked 2026-09-25
- Airtable — Field and table editing permissions checked 2026-08-03
- Airtable — Interface Designer permissions checked 2026-09-25
- Airtable — App sandbox checked 2026-09-25
- Airtable — Using Airtable Portals for external collaborators checked 2026-09-25
- Airtable — Getting started with automations checked 2026-08-21
- 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.