Cost, limits, and knowing when to stop
Two things end no-code projects: a bill nobody predicted, and a ceiling nobody recognised. Both are avoidable with arithmetic done in advance, and this lesson is that arithmetic.
How each block is priced
Configured assistants cost per seat. Everyone using one needs a paid plan, and usage draws on each person's own limits. The failure mode is not a surprise invoice — it is your heaviest users hitting caps mid-afternoon and quietly going back to doing it by hand.
Automations cost per task, where a task is usually one step in one run. This is the one that surprises people, because the multiplication is invisible while you are building. An automation with six steps, triggered forty times a day, is 240 tasks a day and roughly 7,200 a month — comfortably past the free tier of every platform and into a real subscription. Count your steps and multiply before you build, not after.
Document chatbots cost per document, per query, per seat, or some blend. The variable that grows is the corpus, and the moment worth watching is when someone decides to sync the entire shared drive.
Model usage inside automations is billed by the amount of text processed. It is genuinely cheap per call and stops being cheap when a step feeds an entire document into a model on every run. Passing only what the step needs is a habit that costs nothing and saves a surprising amount.
The costs that never appear on an invoice
Review time is the big one, and lesson 5 already made you measure it. An automation that saves thirty minutes and adds ten minutes of checking saves twenty, and if you budgeted for thirty you will be disappointed by a tool that is working correctly.
Maintenance. Things upstream change. Assume a couple of hours a month per significant automation, and notice when the number climbs — rising maintenance is the clearest early signal of the ceiling.
The knowledge cost of one builder. If one person built everything and only that person understands it, the organisation is one resignation away from a system nobody can fix. Lesson 6's shared folder is the cheap insurance.
The signals that you have outgrown no-code
Six of them. Any two together mean it is time for a conversation with a developer, and recognising them early is worth more than the tools themselves.
Your automation has more than about a dozen steps with several branches. Complex logic in a visual builder becomes unreadable and untestable far faster than in code.
You are working around the platform rather than with it. Three steps to do something one line would express is the tell.
Volume is climbing and per-task pricing is now a real line item. There is a crossover where a small deployed service is cheaper than the automation platform, and it arrives sooner than people expect.
You need guarantees. Uptime, latency, auditability, or a specific data-residency requirement. No-code platforms mostly cannot give you these in the form a compliance review wants.
Several tools now depend on each other. When automation C breaks because someone changed automation A, you have a system, and systems need version control and testing rather than a canvas.
It became load-bearing. The honest one. When a client-facing process would stop if your automation stopped, it deserves the engineering that anything load-bearing gets.
None of these mean you were wrong to start here. Building it in no-code is how you found out precisely what to specify, which is most of the cost of the eventual real version — and a specification proven by six months of daily use is worth considerably more than one written in a meeting.
What Studio Kalpa actually spends
Two paid seats for the designers who use the brief writer, one automation platform subscription, one document-chat tool for the archive. It replaced roughly fifteen hours a week of copying, drafting, and searching across nine people.
Rohit's own view is worth quoting: the enquiry automation is the one he would rebuild properly if the studio doubled, because it is the one that touches clients. The brief writer and the archive chatbot he would leave exactly as they are, forever, because they help people do work rather than doing work themselves — and that distinction, in the end, is the one that determines what needs engineering.
Do this today: count the steps in your automation, multiply by how often it will run in a month, and look up where that lands on your platform's pricing. Do it now rather than in month three.