Bitrix24 Vibecode App Development: How ACP Group Builds and Audits AI Apps

When Does a Custom Vibecode App Make Sense?

A custom Alaio Vibecode app is justified when the task goes beyond what Bitrix24 can handle through configuration alone - typically when external users need access, calculations are too complex for standard fields and robots, or two-way sync with an outside system requires its own logic.

Before commissioning any app, check whether the job can be done with native Bitrix24 tools. Funnels with non-standard stages, Smart Processes for asset tracking, and most sales-automation routines are pure configuration. Robots and triggers cover the bulk of deal-level automation. Custom dashboards often come together in the built-in BI Builder without a single line of code. An unnecessary app only adds maintenance overhead.

Build a custom app when at least one of these is true:

• External users (clients, contractors, patients) need a dedicated interface without gaining access to the internal portal
• Calculation logic is too complex for standard fields and automation rules
• You need to aggregate data from multiple external sources in one view
• Two-way sync with an outside system requires a bespoke integration scenario

For everything else, configuration is faster, cheaper and easier to hand over.

As the official Bitrix24 guidance states, Alaio Vibecode "works best for quick internal apps, idea testing, and tools that solve immediate team needs" and "does not replace development for every task" (helpdesk.bitrix24.com).

---

Eight App Types We Build Most Often

These eight categories cover the majority of Vibecode app requests we see in practice - from client-facing portals to AI-powered call analysis - and each one falls outside what standard Bitrix24 configuration can deliver on its own.

Client self-service portal

Companies with repeat corporate clients need a portal where customers check request status, download documents and submit new requests - without receiving internal CRM access. A Vibecode app with one-time-code login solves this cleanly.

Document recognition and matching

Finance, legal and procurement teams spend hours manually checking invoices and contracts. An app accepts a scan or photo, extracts structured data and matches it against the CRM record - counterparty, amount, reference numbers.

Company policy bot

New employees and line managers ask the same questions repeatedly. A bot trained on internal policy documents answers instantly and reduces load on HR. The knowledge base stays editable as policies change.

Call analysis app

CoPilot in CRM already transcribes calls, summarises them and checks them against a script. A Vibecode app is useful when you need your own criteria or reports: it scores the call against criteria you define and writes the result directly into the deal card. See also our AI Call Analysis service.

Management analytics dashboard

When you need metrics across multiple funnels, multiple legal entities, or combined with external data, native reports hit their limits. A custom dashboard aggregates the right numbers on one screen without exporting to spreadsheets.

Estimate calculator in the deal card

A manager fills in parameters - area, materials, labour - and sees the total calculated by the company's own formula, directly inside the deal card. This removes manual errors and speeds up quote preparation.

Incoming request processor

Requests arrive from websites, messengers, email and marketplaces - each with a different data structure. An app normalises the data, deduplicates, sets priorities and creates the correct CRM entity with pre-filled fields.

Online booking with resource grid

Service businesses (studios, clinics, fitness centres) need client booking that accounts for both specialist availability and physical resources (room, equipment). The app shows the live schedule, accepts the booking and creates a calendar event without administrator involvement.

---

How ACP Group Works: From Discovery to Handover

ACP Group follows a five-stage process - discovery, build, audit, handover, support - so that every Vibecode app entering production has documented architecture, tested backups and a named internal owner on the client side.

Every request starts with a pre-development question: can this be solved through configuration? Only if the answer is no do we proceed.

A task moves from initial description to a deployed app through the following steps:

A client request is evaluated, built as a working version, validated against real portal data, checked for permissions and data handling, deployed to an isolated server, embedded in the portal interface, and handed over with backups and architecture documentation.

What ACP Group provides at each stage:

What the client provides:

• A clear description of the current situation and the bottleneck
• Access to the Bitrix24 portal in read mode for the audit phase
• A named internal owner who understands the app's logic and can approve changes
• Up-to-date reference data (price lists, policy documents) if the app depends on them

Two apps that look identical in a brief can differ significantly in effort depending on whether CRM data is clean and structured, how many external sources are involved, whether the app writes to CRM or only reads, and whether external users need access.

---

From Prototype to Production: When to Rebuild vs Refine

A prototype built in a dialogue with an AI coding tool proves the concept but rarely meets production standards - the most common gaps are missing access controls, no error handling, no caching and no documented architecture.

Arriving at a partner with "we built it ourselves but something is wrong" is a normal situation. Slow performance, conflicts with other modules, escalating maintenance cost - these are the signals that a prototype has hit its ceiling.

When to refine an existing prototype:

• Performance issues come from request patterns (loops without batching, no caching) - fixable in place
• Error handling is missing but the underlying architecture is sound
• Keys have excessive permissions but the logic is correct

When to rebuild:

• Access controls were never designed in - layering them on top without refactoring is not reliable
• Data is stored in an app-internal database rather than native Bitrix24 entities (deals, Smart Processes, custom fields) - this breaks native reports, robots and triggers
• The core request pattern is N+1 queries in a loop - a structural problem, not a tweak

A real example from partner experience: an app built through an AI dialogue responded in 30-40 seconds per action. After rewriting the data-fetch logic to use direct REST calls with batching, response time dropped to 2-3 seconds. The platform was not the bottleneck - the architecture was.

---

Go-Live Audit: 20-Point Checklist

Every Vibecode app that writes to CRM, handles personal data or serves more than three concurrent users should pass a structured pre-launch audit - skipping this step is where silent data corruption and portal slowdowns originate.

Based on our experience auditing Vibecode apps and the platform's own guidance, here is the checklist we run before any production launch:

Keys and permissions

• 1. Key type is correct: vibe_api_ for single-user personal apps; vibe_app_ for team apps where each user acts under their own permissions
• 2. Key is read-only where the app only needs to display data - write operations blocked at the Vibecode layer before reaching Bitrix24
• 3. Scopes are minimised to only the Bitrix24 services the app actually uses; default "all scopes" has been trimmed
• 4. Key has an expiry set (30-365 days) rather than no-expiry, with a rotation plan
• 5. Key is stored in environment variables, not in source code, a repository or chat history
• 6. If the app needs new permissions, a new key is issued - scopes are fixed when a key is created

Data writes and personal data

• 7. All CRM write operations verify the current user's permissions before executing
• 8. Write operations are idempotent - a duplicate request does not create a duplicate record
• 9. The app reads only the specific fields it needs, not entire CRM cards
• 10. If the app stores data outside the portal (its own database or a third-party service), this is documented and assessed against applicable data-protection requirements (e.g. UAE PDPL, LGPD, GDPR)

Error handling and logging

• 11. Users see a clear message on failure - no blank screens, no raw stack traces
• 12. All errors are logged to a retrievable log
• 13. Cache is not overwritten by an empty API response on failure (which would serve stale empty data as current)

Portal load

• 14. No N+1 query loops (e.g. "fetch all deals then query each individually") - batch API calls used instead
• 15. Results are cached with an appropriate TTL; data is not re-fetched on every render
• 16. Concurrent-user behaviour has been tested - the app does not cause portal slowdowns when several staff use it simultaneously

Backups and ownership

• 17. A backup of the app's code and data exists, and a restore has been successfully tested on a test environment
• 18. Source code is saved in a repository or external location, not only on the platform server
• 19. A rollback path is defined: how to revert to the previous version if a critical bug appears after go-live
• 20. A named internal owner is assigned - a specific person who understands the app's logic and has authority over its development

Three questions that make audit scope clear: Does the app write to CRM? Does it process personal data? Will more than three users work in it simultaneously? One "yes" is enough to warrant a full audit before go-live.

---

Security Controls for Vibecode Apps

The core security argument for Vibecode is layered: read-only mode blocks writes at the platform level before they reach Bitrix24, Black Hole servers have no public IP address, every key can be revoked instantly, and all changes are logged - but these controls only work if they are deliberately configured.

An AI agent with full API access operates in a loop and can touch hundreds of CRM records in a single run. Tracing exactly which records an agent overwrote can be difficult after the fact. Rolling back from a backup destroys all data created since the last snapshot. The principle of least privilege is not optional hygiene here - it is the primary control.

Key incident response: if a key is compromised, revoke it immediately via the API-keys section - revocation takes effect instantly. Check your app's logs for suspicious activity in the preceding hours. Create a new key and update it in every location that used the old one.

Team-level policy recommendations:

• Default all new keys to read-only; grant write access explicitly per request
• One agent, one key - never share a key across multiple apps
• Rotate keys every 90-180 days even without an incident
• Enable 2FA on the Bitrix24 account - sign-in to Vibecode goes through your Bitrix24 account
• Review the key activity log periodically for anomalous spikes or off-hours activity
• On employee departure: deactivate the Bitrix24 account AND explicitly revoke any individual Vibecode keys they created

For broader Bitrix24 security practices, see our self-hosted security hardening checklist.

---

What Stays on the Client Side After Handover

Three responsibilities remain with the client after handover: keeping a named internal owner, maintaining reference data the app depends on, and treating any extension as a separate scoped project.

An app handed over is not a finished product - it is a living tool. The following stay on the client's side:

• Named solution owner. A specific person inside the company who understands the app's logic and has authority to commission changes. Without this, updates stall because no one can approve a scope.
• Reference data currency. If the app uses a price list, policy document or lookup table, those need updating as the business changes. Stale inputs produce wrong outputs.
• Extension decisions. An app that works well on one task often gets requests to expand. Each extension is a separate project with its own assessment - not a free addition to the original build.

If the employee who built an app leaves, the handover depends on documentation: Vibecode keys are bound to a specific Bitrix24 account and user, so the new owner needs new keys, the old ones must be revoked, and the inventory questions from the audit section still apply.

If post-launch questions or minor fixes arise, these are handled through a technical support arrangement. Larger changes are scoped as new projects.

For a sense of typical implementation effort across Bitrix24 modules, see Bitrix24 implementation hours by module.

---

Why Work With a Partner on Vibecode Development?

According to the official Bitrix24 partner guide, "a partner can help you define the task, build the app in Alaio Vibecode, test the scenario, and deliver a ready-to-use tool" (helpdesk.bitrix24.com) - the value is not the code generation itself, which anyone can trigger, but the judgement about what to build and the audit before it touches live data.

The platform lowers the barrier to building - in practice, simple apps come together for almost anyone, while larger "all-in-one" solutions often stall at the architecture stage. The pattern we see most often: a prototype works on test data, gets deployed to production, and then overwrites CRM fields without permission checks or takes the portal offline under concurrent load.

ACP Group builds, audits and hardens Vibecode apps. Our work includes:

• Pre-development assessment: configuration vs. Vibecode vs. classic REST API development
• App build using Claude Code, Codex or Cursor with the Vibecode API
• Pre-launch audit against the 20-point checklist above
• Refactoring or rebuild where the prototype architecture cannot be extended safely
• Handover package: architecture document, key documentation, backup verification, named owner setup
• Ongoing support and extension management

For pricing and scope, visit acp-24.com or reach us at info@acp-24.com or WhatsApp +971 55 780 1481. We consult in English and Portuguese.

You may also find it useful to compare when to implement with a Gold partner vs. DIY before deciding on your approach.