Starting point
The client runs a services business and managed it through a system built on a no-code / low-code platform (Studio Manager). The system handled schedules, employee payouts, payments, and notifications. On paper everything worked. In practice — the system generated problems the platform vendors couldn’t solve.
Problem
The client reached out with one bug: "employees can withdraw their salary several times." The audit showed it was the tip of the iceberg.
- Withdrawals without control: The system generated a withdrawal confirmation and moved it to history — but didn’t reset the employee balance. Clicking "Withdraw" a second time — the system allowed it.
- OAuth without verification: Google login gave instant access to the system. No waiting room, no admin confirmation. Anyone could walk in.
- Telegram cut off: The platform’s built-in middleware blocked webhooks from the Telegram API (non-standard payload structure). The company lost notifications.
- Double-billing: The daily-fees algorithm (Tax/Restaurant) duplicated costs under specific date combinations — a classic edge case that manual testing didn’t catch.
Diagnosis
I started with a code and data-flow audit. The no-code platform restricted access to the "raw" code, so I had to reconstruct the logic from visual configuration and logs. The key was understanding where the platform ends and real engineering has to begin.
For Telegram — I tested the API directly (curl + Postman) to prove the problem sat in the platform’s middleware, not in the Telegram API.
Solution
1. Atomic withdrawals
I rewrote the withdrawal logic so that the balance reset and the history-record creation happen in a single database transaction. If any step fails — the whole operation rolls back. Double-withdrawal is no longer possible.
2. External microservice on Deno Deploy
Rather than fighting the platform’s middleware limitations, I built a lightweight microservice on Deno Deploy that receives webhooks from Telegram, validates the payload, and forwards the data to the system in a format the platform accepts. Independent, serverless, zero maintenance cost.
3. RBAC — 3-tier access control
Introduced a flow: new user → waiting room → admin verification → role assignment
→ access. Three states: pending, verified,
active. No user reaches the system without a conscious admin
decision.
4. Rewritten transactional logic
Full rewrite of the daily-fees algorithm. Added safeguards against double-charging (idempotency check on date + type + employee combination) plus an audit panel where the owner sees every operation with timestamp and source.
Result
The system has been running stably since deployment. The owner has full control over access, withdrawals, and fees. Telegram delivers notifications again. The audit panel provides the transparency that was previously missing.
Takeaways
No-code platforms are great for fast prototyping. But once the system starts handling real money, personal data, and security processes — you need an engineer who understands what happens "under the hood."
It’s not about throwing out no-code. It’s about knowing where "clicking things together" ends and engineering begins.