DEV Community: Nebosa Company

Your data should outlive my company

Nebosa Company — Tue, 06 Oct 2026 07:00:00 +0000

On 4 August 2026 Airtable was bought by Bending Spoons for $1.285bn.

I am not going to tell you what happens to your bill. I don't know, and neither
does anyone else writing about it. What I will say is that the
acquirer has a public record: Evernote went from 341 people to 60 inside twelve
months and the free plan was curtailed; WeTransfer saw staff cut and free limits
tightened; TechCrunch traced the same cycle across five of their purchases.

I build a competing product, so discount me accordingly. But the question stands
whether you ever talk to me or not, and it isn't really about Airtable. It's
this: if the company holding your operational data changed its mind about you
tomorrow, what would you actually do?

For most teams the honest answer is "export a CSV and hope." That is the problem
I have spent this year on.

The product tour, silent by design. Full-resolution video.

What "keep your own data" has to mean

It is a phrase every vendor uses and almost none of them mean, because meaning
it is expensive. Here is the version I hold myself to.

It has to run without me. Not "we offer an enterprise self-hosted tier." Not
"contact sales." The whole install is:

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

One container: the database, the API and the app together. Thirty days on the
Business tier, then a licence — a signed file checked against a key inside the
image, so nothing phones home to ask my permission to keep working. If I am hit
by a bus, the licence you hold keeps working until the date printed in it, and
your data stays readable and exportable after that with no licence at all.

It has to be truthful about telemetry. There is a crash reporter and there
are product analytics in the box. I would rather describe that accurately than
write "no telemetry" and have you find the consent banner yourself. The crash
pipeline stays inert until you set a key. The analytics ask first, honour Do Not
Track, and post to your own instance rather than to me. The prompt the product
actually shows on first run says it records page names and actions — never your
data, never your record contents — and if you press No thanks, nothing is
recorded and it does not ask again.

It has to be checkable rather than promised. Two scripts ship in the box:

bash scripts/rls-test.sh
bash scripts/tenant-isolation-test.sh

The second one proves two tenants cannot see each other in both modes — shared
database and database-per-tenant. You run it against your own install. You don't
take my word for the isolation, and you shouldn't.

The product this is attached to

None of the above matters if what you are self-hosting is a toy. The application
I use to test this is a plant-wide manufacturing ERP: employees and gate entry,
shifts and vacation, working stands, SOPs, items, bill of materials, warehouses
and inventory, suppliers, purchase orders, customers, sales and production
orders, quality, repairs, forwarders and shipments. Twenty-two pages, eleven
workflows, one workspace.

Four things in there worth a technical reader's attention.

Field types that refuse bad input

Your database lets you type an IBAN wrong. So does every spreadsheet-shaped tool
I have compared against — they store it as single-line text and hope, and you
find out the money is gone about a week later. There are 90 field
types here and 59 of them refuse malformed input by format
or checksum.

Eleven of those are enforced in the database itself rather than in the browser:
IBAN and LEI by ISO 7064 mod-97, ISIN and card numbers and IMEI by Luhn, the VIN
transliteration, ISBN-10, ISBN-13 and the bare ISBN, EAN-13, UPC. Those hold
when the row arrives through the REST API, a webhook, or an importer at 3am with
no browser in the loop.

The rest — VAT, MIC, ICD-10, SNOMED, NDC, HS codes, UN/LOCODE — validate as you
type, and that is deliberate rather than unfinished. Their rules are national
registries and revisable code lists. A regex that is subtly wrong at the
database level rejects a real customer's valid identifier with no way around it.
A mod-97 cannot be subtly wrong. Narrow and correct beats broad and approximate
on the write path.

A dashboard is just a page

There is no separate BI product bolted on the side. A page is a stack of
elements, and there are 48 of them — table, list, gallery, kanban,
calendar, chart, form, gantt, timeline, pivot and the rest. You drop a number
tile on a page, point it at a table and an aggregate, and that is your
dashboard. The morning-meeting screen for the ERP above is three number tiles
and a chart: order book, output and stock, on one page.

Every chart type and every view is on the Free tier. That is an easier promise
to keep when the charts are not a separate product with their own margin to
defend.

Automations you can audit

Rules are the part of a low-code tool that rots quietly. Somebody builds one,
leaves, and two years later nobody can say what fires, or whether it still does.

So the workflow list is workspace-wide rather than buried one table at a time.
Each rule shows its trigger, its condition, the app and table it belongs to,
whether it is on — and the part I care about most, whether it has ever run.
"Never used" is a badge on the row, not something you go digging through logs to
work out. The rules marked that way are the ones worth deleting, and the page
turns that into a five-second judgement instead of an afternoon.

A seam for agents instead of a fight with them

"AI will make no-code obsolete" is half right: generating an interface is nearly
free now, and the moat no-code had in 2019 is gone. The half that is not right
is that your data still has to live somewhere — with permissions, with a backup
you have actually tested, with something stopping the malformed row, with an
audit trail when someone asks who changed the price. AI does not remove that. It
makes it easier to skip until it hurts.

So there is an MCP server in the box, over stdio and HTTP. Your database becomes
a tool the agent holds, scoped by row-level security, rather than something
reached through a scraped API key.

The AI meter I deleted

On the 4th of August I deleted our AI billing meter. Not disabled — deleted.
There is no credit balance in the product, nothing to debit, and no code path
that can refuse your AI call to protect my margin.

To be precise, because someone will eventually read the code and I would rather
they find me accurate than clever: usage is still recorded. Which model ran,
for which feature, on whose behalf, and how many tokens your provider counted.
That row exists so an admin can check it against their own provider invoice.
Recording is not metering — nothing in that row decides whether your next
operation is allowed, and no number in it is a price.

The reason is that I could not find an honest version of the alternative. Every
AI credit pack I priced came out as a markup on someone else's model, dressed up
as a feature. You would be paying me to pass your prompt along. So instead:
bring your own key. Your provider, your rate, your bill. I never see it and I
take no cut, on every plan including Free.

The one thing that can stop an AI call is a spend cap you set and you raise, so
a runaway workflow cannot burn through your provider key at 3am. I do not earn a
penny from it firing.

This removes a revenue line most of my category treats as core. I would rather
explain that to an investor than explain a credit pack to a customer.

What I don't have

I am one engineer, and the fastest way to lose a technical reader is to let them
discover a gap I hid.

We are not SOC 2 certified. Not ISO 27001. No HIPAA BAA. The test suite
fails the build if those words appear on the homepage, which was deliberate. If
a certificate is a hard gate for you this quarter, I am the wrong call this
quarter, and I will tell you that on the first call rather than the fifth.

What exists instead is measurement, and you can read the recordings:

Run	Result	Measured
Disaster recovery	RTO 9.4s, RPO 120 rows, restore verified by checksum	1 August, due a re-run
Noisy-neighbour fairness	One tenant under a 3,000-request storm from another ran at 0.89x its own quiet p99	September 2026
Load	p50 37ms, p99 43ms, zero errors over 500 requests	September 2026

An older load run on a smaller database read p50 6ms. I am quoting the slower
number because it is the current one.

The repository is private while this is early. So "run the isolation test
yourself" today means asking me for access rather than a public clone. That is a
decision I intend to reverse, not a permanent one, and I would rather say it
plainly than link you into a 404.

It is one person. That is the risk you take on, and it is exactly why the
self-hosted path above is not a marketing tier. It is the answer to the obvious
objection.

If you want to look

There are no seat minimums, no charge for read-only viewers, no charge for the
people who use the apps you publish, and no view or chart type held behind a
tier.

If you are weighing a move this quarter, the useful ten minutes is not reading
this post — it is opening your current bill and counting how many editors you
pay for versus how many actually edit. Almost nobody knows that number offhand.

And if you want to test the switching cost rather than guess at it: send me your
gnarliest formula from Airtable, monday, ClickUp, Smartsheet, Quickbase, Notion
or AppSheet. 7 dialects are understood inbound, 279 functions on this
side to land them in. I will paste it in and screen-record what happens —
working or not. I will show you the failures too. Those are more useful to me
than the wins.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

The seat minimum is a pricing decision, and you are paying for it

Nebosa Company — Tue, 29 Sep 2026 07:00:00 +0000

Here is a thing that is easy to miss when you compare pricing pages: the number
on the page is the rate, not the bill.

Two of the biggest tools in this category will not sell you exactly the number
of seats you have.

The product tour, silent by design. Full-resolution video.

monday.com sells in blocks of five, with a floor of three

The Pro plan is $19 per editor per month. But the smallest purchase is
3 seats, and above that it is sold in blocks of 5.

So if your team is six people, you do not buy six seats. You buy ten.

Editors you have	Seats monday bills	Monthly	Effective rate per real editor
1	5	$95	$95.00
6	10	$190	$31.67
11	15	$285	$25.91
16	20	$380	$23.75

Every one of those rows is a real invoice, and every figure in the table came
out of the function our own pricing page bills against rather than out of my
head. At six editors you pay for ten at $19 each, so the rate per person
you actually have is $19 on the pricing page and $31.67 in practice —
67% higher.

Note the first row. The floor is 3 seats but the block size is
5, so a single editor is rounded up to 5 rather than
to the floor. The two rules compound; they do not overlap.

Quickbase will not sell you fewer than twenty

The Team plan is $35 per user per month with a floor of
20 users. That is the entry price of the product, and it is the
entry price whether you are twenty people or three.

For a team of five evaluating it, the pricing page says $35 and the
invoice says $700 a month — 20 seats at $35,
four times the people you have. That is not a trick; it is on their page. But it
is the number that decides whether you can pilot the thing, and it is not the
number anyone quotes in a meeting.

Why vendors do this

Not out of malice. Seat floors and buckets do three things for a vendor:

They raise average contract value without raising the advertised rate, which is the number that gets compared.
They make small accounts profitable to support.
They create a step function, so growth produces revenue in jumps rather than smoothly.

The third is the one to watch, because it means your bill moves when you hire
your eleventh editor and does not move when you hire your twelfth.

What Appdor does

No minimum, and no buckets. You are billed for the editors you have, viewers are
free and unlimited, and the plan does not decide which of the product you may
use — all 48 page elements, 25 chart types and
24 dashboard widgets are in every tier.

⚠️ That is a pricing commitment, not a claim of being cheapest. For a large team
on an annual deal, a competitor's negotiated rate may well beat our list price.
What we are saying is narrower and checkable: you will not be invoiced for
seats you do not have.

If you want the comparison for your own headcount rather than a table of
somebody else's, the migration calculator on the pricing page does the
arithmetic — including the floors and the buckets, because a saving computed
against the advertised rate rather than the real invoice would be the same
sleight of hand this post is about.

The wider point

Seat rules are the clearest example of something true across this whole
category: the pricing page is a marketing surface and the invoice is the
product. When you evaluate any of these tools, price the invoice for the team
you actually have, at the size you expect to be in a year, with the features you
will actually need — and check which of those features is a tier.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

The container was running software nobody built

Nebosa Company — Tue, 22 Sep 2026 17:08:24 +0000

A deploy that silently does nothing is worse than a deploy that fails, and we shipped two flavours of it before either one announced itself.

The first one: a deploy with an expiry date

The fast dev loop is to tar a built dist/ into /usr/share/nginx/html of a running container. It works. The page updates, the change is live, and the loop is seconds instead of minutes.

It survives docker restart. It does not survive a docker compose up -d that recreates the container, because the new container comes up from the image, and everything deployed that way reverts to whatever the image was built with.

Nothing errors when this happens. No log line, no failed request; the app simply becomes an older app, and every measurement taken afterwards is of software nobody built.

It cost one session a reskin, a glyph set and two bug fixes on 2026-08-27. It was noticed only because the served bundle hash changed — not because anything complained.

The second one: a recreate is not a rebuild

The subtler version has no hot-patching in it at all.

Measured the same day: the running image had been built the previous evening and carried 19 supervisord programs against the tree's 20. The missing one was cert-watch, the certificate-expiry watcher. So on a deployment serving portal custom domains, the alarm for a certificate about to expire was not running — and the image's own healthcheck was one probe short of being able to notice that it wasn't.

The instinct here is --force-recreate, and it does not help. It recreates the container from the same image. Only docker compose build produces a new one. The distance between those two commands is one word, and the feedback that tells them apart is nothing at all: docker ps, docker inspect and the health status all look identical either way.

Why "it looks fine" is not evidence

Both failures share a shape worth naming, because it generalises past Docker.

A deployment has two states that present identically to every casual check: running what you built, and running something older that still starts cleanly. Nothing in the second state is broken enough to complain. The process is up. The healthcheck passes — it is the old healthcheck, and it passes honestly. Requests return 200. The only difference is that the thing answering them is not the thing in your tree.

The measurement is what gives the game away, in both directions. A bundle budget that improved without anybody optimising anything. A test that started passing without anybody fixing it. Both of those are the same report: you are measuring a build you did not make.

What we do about it

Three things, none of them clever.

Name the fast path as a dev loop, in the script itself. scripts/deploy-to-container.sh opens with the line NOT A DEPLOY. See docs/deployment.md — a release is an image. This is the dev loop. A comment is not a gate, but the cost of this failure is entirely in the belief that a deploy happened, so the belief is what to attack.

Have a command that answers "what is actually running". node scripts/env-preflight.mjs diffs the container's [program:] set against docker/supervisord.conf and names the programs that are missing. That is the check that catches the 19-against-20 case, and it exists because nothing in Docker's own output does.

Give the database question its own tool, with three outcomes. npm run ops:drift compares the init files against the database you are serving from, and it reports IN SYNC (0), DRIFT (1) or NOT MEASURED (2) when the database could not be read. The third one matters more than it looks: an unmeasured state must never be readable as a good one. Most tooling folds "I couldn't check" into "fine", which is how you end up trusting a green light that was never on.

The rule this leaves us with

If you recreate the container, redeploy. And if a number moves in a direction nobody worked for, check which build is serving before you believe it.

That is not a Docker lesson. It is what happens any time the artefact you deploy and the artefact you edit are two different objects, and only one of them is on screen.

Appdor vs Airtable: the same job, a different bill and a different address

Nebosa Company — Tue, 22 Sep 2026 07:00:00 +0000

Airtable made this category. If you are reading this you have probably built
something real in it, it probably works, and the question is not whether
Airtable is good software. It is whether the two things it cannot change about
itself matter to you.

Those two things are where your rows live and what the second year costs.

The product tour, silent by design. Full-resolution video.

Where the rows live

Airtable is a hosted product. Your data is in their infrastructure, and the
answer to "which sub-processors touch our production records" is their list, not
yours.

Appdor is a work OS that sits on top of a Postgres database rather than
inside a vendor's. The database is the system of record, it is ordinary
Postgres, and you can point psql at it. The whole install is:

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

For a lot of teams that difference is worth nothing, and I would rather say so
than pretend otherwise. It becomes worth something the first time a customer
contract names a jurisdiction, an auditor asks for the schema, or somebody wants
a read-replica for the warehouse team.

What the second year costs

This is the part that surprises people, because it is not the sticker price.

Airtable's Team plan is $20 per editor per month on annual billing;
Business is $45. The jump between them is the interesting number:
it is a 125% increase, and the features that force it — field-level
permissions, SAML, admin controls, more records per base — are the ones a team
needs precisely when it has stopped being a pilot.

	Airtable	Appdor
Entry paid tier	$20 per editor / month	see the pricing page
Next tier up	$45 per editor / month	one step, not a cliff
Views behind a plan	Gantt and timeline are paid tiers	all 12, every plan
Charts behind a plan	extensions vary by tier	all 25, every plan
Records per base	capped, and the cap is a tier feature	your Postgres
Read-only viewers	free	free
Self-hosting	not offered	the same build you would pay us to host

The row that matters most is the one about views. Appdor ships 12 view
types, 48 page elements, 25 chart types and
24 dashboard widgets, and none of them is a plan tier. The
plan decides seats, support and who runs the servers. It does not decide which
of the product you are allowed to use.

What Airtable does that we do not

A comparison post that finds nothing good to say about the other product is an
advertisement, so:

The ecosystem. Airtable's marketplace, its extension gallery and the sheer number of people who already know it are real advantages, and a smaller product does not have them.
Interface Designer is mature and has had years of polish.
Sync from other bases is a first-class feature there.

If those are load-bearing for you, that is a reasonable reason to stay.

The migration, honestly

Your rows will move. Every tool in this category exports CSV and the rows come
out fine.

What does not come out is the logic — the formula columns are the part that
stalls migrations, because an export gives you the last computed value and loses
the expression that produced it. Appdor reads 7 competitor formula
dialects, Airtable's among them, and recompiles the expression rather than
freezing its output. That is covered properly in its own post.

It is not a promise that every expression survives. A function with no
counterpart is reported rather than guessed at, and that list of refusals is
your real migration backlog.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

What happens when the vendor changes the deal

Nebosa Company — Fri, 18 Sep 2026 14:13:12 +0000

In January 2026 SmartSuite withdrew its free plan. Existing free workspaces kept
working until July, and then they expired.

I want to be careful here, because this is the kind of story that gets told
unfairly. SmartSuite did nothing dishonest. They gave six months' notice, the
plan was free, and no company owes anyone a free tier forever. Their paid plans
start at $30 per editor per month for Professional and the
product is well regarded.

The point is not that they behaved badly. The point is that it was entirely
their decision to make, and everyone whose team ran on that plan found out
what that meant on the same day.

The thing you are actually buying

When you adopt a hosted work OS you are buying two different things and only one
of them is on the pricing page.

The first is the software: views, automations, formulas, permissions. That is
what you evaluate.

The second is a standing dependency on someone else's commercial decisions —
their pricing, their packaging, their roadmap, their acquisition, their
continued existence. That one is not on the page, has no SLA, and is the one
that decides whether the thing you built is still there in three years.

Nothing about this is unique to SmartSuite. In the last few years this category
has produced:

free tiers withdrawn;
entry plans repriced;
features moved up a tier, so the same workflow costs more without changing;
AI sold as a separate meter on top of the seat you already bought;
companies acquired, and their products folded into someone else's roadmap.

None of that is misconduct. All of it is a vendor doing what a vendor is allowed
to do with a product it owns and hosts.

The product tour, silent by design. Full-resolution video.

What changes if you can run it yourself

Appdor is a work OS on top of a Postgres database rather than inside a vendor's.
The whole install is:

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

That does not make us immune to being a company that makes decisions. We can
change our pricing too. What it changes is what happens to you if we do:

The database is ordinary Postgres and you can point psql at it. Your data does not need our cooperation to be readable.
The build you self-host is the same build we host, on the same plans. There is no licence server to call and no activation: a licence is a signed file checked offline against a key inside the image. Thirty days to try it, then a licence to keep editing — and reads and exports never lock.
Nothing is behind a plan. All 48 page elements, 25 chart types and 24 dashboard widgets ship in every tier, so there is no ladder for a feature you already use to be moved up.
If you want to leave, the exit is a pg_dump rather than a support ticket.

⚠️ That is a smaller claim than "you are safe", and I would rather make the
smaller one. Self-hosting moves a risk; it does not delete it. You now own
backups, upgrades and uptime. For a lot of teams that trade is not worth it, and
the hosted option exists for exactly that reason.

The question to actually ask

Not "is this vendor trustworthy". They usually are, and it does not help you
anyway — the SmartSuite decision was made by people acting reasonably.

Ask instead: if this vendor changed the deal tomorrow, what would it cost us
to say no?

For most hosted tools the honest answer is "a migration we do not have time
for", which is another way of saying the deal cannot be refused. If the answer
is "we keep running the build we already have, on our own hardware, while we
decide" — that is a different position to negotiate from.

Originally published at appdor.com. I build Appdor, so weigh accordingly.

Your spreadsheet-database can run on hardware you already own

Nebosa Company — Fri, 18 Sep 2026 14:11:14 +0000

Every spreadsheet-database product on the market will tell you your data is
safe. Almost none of them will tell you where it is.

That distinction stops being philosophical the first time somebody in
procurement asks which sub-processors touch your production records, or the
first time a customer's contract says the row has to stay inside a particular
jurisdiction. At that point "safe" is not an answer. "It is in a Postgres
instance on hardware you control, and here is the connection string" is.

The product tour, silent by design. Full-resolution video.

What running it yourself actually means here

Appdor is a work OS that sits on top of a Postgres database rather than
inside a vendor's. The database is the system of record, it is ordinary
Postgres, and you can point psql at it.

curl -fsSL https://get.appdor.com/appdor-latest.tar.gz | docker load
curl -fsSLO https://get.appdor.com/docker-compose.yml
docker run --rm ghcr.io/nebosa-company/appdor generate-keys > .env
docker compose up -d

That is the whole installation. There is no licence server to call and no
activation step: a licence is a signed file, checked against a key that is
already inside the image, so nothing phones home. You get thirty days on the
Business tier to decide; after that the install keeps every read and every
export but stops taking edits until a licence is in. What it never does is
quietly switch a feature off because it noticed it was running outside a
hosted plan.

The consequences are worth being precise about, because "self-hostable" is a
word that has been used loosely enough to mean nothing:

The schema is yours. Tables are tables. A migration you write by hand, a read-replica you attach, a nightly pg_dump into your own object store — all of it works, because there is no proprietary storage layer between the product and the database.
The product does not phone home. No telemetry endpoint and no licence check. The application and marketing bundles are served from the origin you deployed — no CDN. One exception, stated because you would otherwise find it in a network tab: the Map element fetches its basemap tiles from OpenStreetMap's servers by default, which tells that host a viewer's IP address and roughly where they are looking. It is one setting (tileUrl) pointed at your own tile server, and nothing else changes.
Nothing is gated. All 48 page elements, 25 chart types and 24 dashboard widgets are present in the build you just started. There is no plan that unlocks them.

The part that usually breaks

Most migrations off a hosted spreadsheet-database do not fail on the data. They
fail on the logic — the several hundred formula cells somebody wrote over
three years, in a dialect that only exists inside one vendor's product.

Appdor reads 7 formula dialects and transpiles them into its own. That
is a separate piece of work with its own article, but it is the reason this
particular migration is finishable rather than merely startable.

What you should check before believing any of this

Reasonable scepticism about a self-hosting claim looks like this, and all four
are things you can verify yourself in about twenty minutes:

Bring it up with the network disconnected after the images are pulled. If it needs the internet to run, that is where you will find out.
Connect to the database directly and read a record you created in the UI. If you cannot, the storage is not really Postgres.
Grep the built assets for absolute http(s) URLs. Third-party requests are not a matter of policy; they are a matter of fact.
Turn off a feature's network path and see whether the feature admits it.

The fourth is the one that separates products that are honest from products
that are merely quiet.

Where this leaves you

If you are running a spreadsheet-database today and the answer to "where does
this row live" is a vendor's region list, you have a dependency you did not
choose and cannot audit. Running the same class of tool on your own Postgres
turns that into a deployment decision — which is the kind of problem your
infrastructure team already knows how to have.

The product is free to run on your own hardware, and it is available in
36 languages.

Originally published at appdor.com. I build Appdor, so weigh accordingly.