Every limit worth knowing on this platform returns 200 OK and carries on.

It can replace more of a small business's stack than its critics think, and it fails in a more dangerous way than its fans admit. The dangerous part is not the missing features. It is that most of its real limits return 200 OK and carry on as though the thing you asked for happened.

We build on it daily. This is the list we wish someone had handed us, and every item on it is something we measured rather than read.

01 / The patternThe pattern that governs everything below

Software usually fails loudly. You send a bad request, you get an error, you fix it.

Several of this platform's most consequential behaviours do the opposite. The request succeeds. The response says success. A version number increments. And the thing you changed is unchanged.

If you take one thing from this page: on this platform, verify by reading the value back from the surface a customer actually sees. Not from the response. Not from the builder preview. From the live page, the live record, the live bill.

02 / The silent onesThe silent ones, worst first

1. A published blog post's body cannot be edited. The update call accepts the content, returns success with a fresh version ID, moves the updated timestamp ... and keeps the old body. The response even echoes the OLD content back at you, so you cannot detect it from the response either. Changing one sentence in a published article costs a slug move, a fresh creation at the canonical URL, and a sitemap re-push, with the real URL 404ing for the seconds in between.

Practical consequence: on this platform, write the article as if it is being carved, because it is. Everything caught before publication is cheap. Everything caught after is not.

2. There is no delete for blog posts. Archiving is the only removal and it leaves residue. Publishing is close to irreversible.

3. A checkout switch that reads as "make every line mandatory" actually charges only the first product. With multi-product select disabled, both product lines still render on the page, the checkboxes disappear, and the order total silently contains only the first item. The customer reads a line saying "$100 per month", is never charged for it, and no subscription is created.

It looks correct on screen. It is the single most dangerous setting on the element, and it was live on our own site before we caught it.

4. A setup fee is charged and never labelled. A recurring price can carry a setup fee, the renderer sums it into the total correctly... and the string that explains it exists only in a different part of the product, not in the checkout renderer. So the buyer sees "$100 per month" and a total of $600 with nothing on the page accounting for the other $500. Either supply that sentence yourself or take the two charges separately.

5. A product change does not reach the live page until the page is republished. And the builder cannot show you the mismatch, because it renders a placeholder line at a placeholder price regardless of what the real products are.

6. Weekend availability is accepted and then ignored. The calendar API accepts both weekend days in the open-hours configuration, stores them, and reads them back correctly. The availability engine then returns zero bookable slots for those days. Weekdays work normally. The configuration looks right and the calendar offers nothing.

7. Terms links on a new order form point at example.com out of the box. Enabling the terms checkbox without replacing them ships a live checkout that links a customer to a placeholder domain.

8. A blog is a separate site as far as your code is concerned. It inherits none of the head or body code from the main site, so it ships with no cookie banner and no links to your privacy or terms pages unless you paste them in separately. Everything looks fine, because everything looks fine.

03 / The other directionThe things it does that people assume it cannot

Three corrections in the other direction, because a limits page that only lists limits is just a competitor's blog post.

Calendar settings constrain the public booking widget, not your staff. Slot duration, intervals, buffers and opening hours shape what a VISITOR is offered. They place no constraint on an appointment created by an admin or through the API. We tested it: 90-minute and 25-minute bookings on a 50-minute calendar, an 08:07 start against a 15-minute grid, a 22:00 booking outside opening hours, a booking on a day the calendar was closed, deliberate double-bookings, and free-text appointments with no service attached. All succeeded.

This is the difference between "the platform cannot replace their booking system" and "it replaces it exactly". Any business whose reception books manually in the back office behaves this way, and the calendar configuration is almost irrelevant to them. Check how the client actually books before designing around it.

Custom objects and custom dashboards are on every plan. Both were once higher-tier. Both are not. Nobody needs to upgrade for them, and nobody should be designing custom-field workarounds to simulate them.

Workflow logic is readable in full. The list endpoint returns metadata only and cannot tell you whether a workflow contains anything at all, which trips up most tooling built against it. The full step tree, triggers and conditions are available through the platform's own internal interface, which is how we audit a client's automations without asking anyone for a screenshot.

04 / Where it stopsWhere it genuinely stops

Short, because these are the honest structural ones rather than bugs.

• No permission scope exists for the knowledge base. You cannot give a client editable control of what their bot knows without giving them the bot. The only design that works is keeping the knowledge in a document they own and syncing it in.
• Some bot types cannot be pinned to a specific AI model at all. The API refuses the field outright depending on how the bot was built, which means those bots are exposed to the vendor swapping the model underneath them, with no lever available to anyone.
• The blog container itself cannot be created through the API. One manual step, every time.

05 / If you are buyingWhat this means if you are buying

Three consequences, and only the third one is about the platform.

1. Ask any agency what they VERIFY, not what they build. On a platform where the failure mode is a successful-looking response, "we tested it" has to mean "we read it back off the live page". That is a different sentence and it is worth making someone say it.
2. Assume the checkout is wrong until money has moved through it. Put a real card through your own order form before you send a customer to it. It costs the price of your cheapest product.
3. The platform is not the risk. Unverified work on it is. We are not warning you off it, we build on it by choice. But an agency that has not met the list above has not been paying attention, and the items on it are the ones that quietly cost money rather than the ones that throw errors.