1C-Bitrix Development: What Goes Into Choosing the Platform
Architectural Decisions That Shape Your Budget for Years
The most expensive mistake in a Bitrix project is picking the wrong edition. A client buys "Business" and six months later discovers that a multi-regional catalog with personalized pricing requires "Business Enterprise." The difference isn't just the license fee — it's an entirely different data storage architecture, a different approach to clustering, a different performance ceiling. Migrating between editions on a live project with 80,000 products and 200 daily orders isn't "upgrading the license." It's a full-blown engineering project spanning 3-6 weeks.
But the edition is only part of the story. Infoblocks — Bitrix's core mechanism for content storage — have a structural limitation. Every element property is a row in b_iblock_element_property, and when filtering a catalog, MySQL builds a JOIN for each property in the filter. With 5,000 products, this works. At 50,000, catalog queries take 3-8 seconds. At 200,000, the site collapses under any filtered request.
Starting with Bitrix D7, highload blocks appeared: properties are stored in a flat table with columns instead of an EAV table. Filtering by 10 parameters — a single query, no JOINs. But highload blocks don't support versioning, built-in SEO properties, or the familiar infoblock events. Choosing between classic infoblocks and highload blocks is an architectural decision made at the start, and reworking it on a live project costs more than spending two days on analysis upfront.
We begin every project with a future load audit. How many products now, how many in a year. Concurrent visitors. Required filters. Multi-warehouse needs. The architecture follows from the answers — not the other way around.
Common Pitfalls in Bitrix E-Commerce
E-commerce is the most frequent request. And the most underestimated in complexity.
The sale module in Bitrix is powerful but convoluted. Cart, order, payment, delivery — four subsystems, each with its own API. Since version 17.0, orders moved to the D7 core (\Bitrix\Sale\Order), but half the marketplace modules still use the legacy CSaleOrder. The result: conflicts during checkout customization, especially when third-party delivery or payment modules are involved.
A real example: a client connected a CDEK delivery module and a YooKassa payment module. Individually — fine. Together, with a specific combination (pickup + QR payment), the order was created with zero delivery cost, even though the correct amount showed on screen. The cause: both modules overrode the OnSaleComponentOrderResultPrepared handler, and the call order depended on sorting in b_module_to_module. The fix took thirty minutes. Finding the cause took two days.
Another systemic issue — catalog page performance. The standard catalog.section component executes 40 to 120 SQL queries per page, depending on the number of properties, SKUs, and price types. Composite cache helps for anonymous users, but authenticated users see personalized prices — every request hits the database. We solve this by pre-caching price matrices in Redis and serving them via AJAX after page load.
Bitrix24, CRM, and Business Process Automation
Corporate portals and CRM on Bitrix24 are a separate track. Different specifics: REST API with rate limits of 2 requests per second for on-premise (50/sec for Enterprise), business processes on a visual editor that breaks on complex branching, and external service integrations via webhooks.
We frequently connect Bitrix24 with 1C:Enterprise. Counterparties, invoices, reconciliation acts — bidirectional sync. Managers work in CRM, accounting works in 1C, data stays consistent. Under the hood, it's REST API plus custom handlers on the 1C side, with Redis queues buffering peak loads.
Security: Not Optional
The proactive protection module (security) covers the basics: WAF, session protection, activity monitoring. But it won't catch vulnerabilities in custom code or outdated marketplace modules. We run security audits separately: checking for SQL injection in custom components, XSS in templates, CSRF in forms, file permissions on the server.
A frequent finding — backup files in the public directory. bitrix/backup/ with a full database dump, accessible by direct URL. Or bitrix/.settings.php with the database password, served up when nginx is misconfigured.
Migration, Support, SEO
Migrating to Bitrix from other CMS platforms (WordPress, OpenCart, custom solutions) takes 2 to 8 weeks depending on content volume and business logic complexity. Preserving URL structure and 301 redirects is critical — lose them and SEO rankings reset to zero.
Support isn't just "fix a bug." Bitrix updates ship frequently, and each update can break custom components. We maintain a registry of customizations per project and verify compatibility before every update.
SEO in Bitrix is its own discipline. The seo module handles sitemap.xml generation, meta tags, and canonical URLs. But serious SEO requires Schema.org structured data, Core Web Vitals optimization (LCP, CLS, INP), and server-side caching configuration. Stock Bitrix serves HTML with inline styles and scripts, killing PageSpeed scores — we rewrite templates for async loading and extract CSS into separate files.
How We Estimate Projects
Every project starts with an audit of the current state (for existing sites) or a requirements analysis (for greenfield projects). The stages:
- Requirements gathering — business needs, integrations, catalog scale
- Technical design — edition selection, data architecture, infrastructure
- Effort estimation — task-level decomposition with hourly estimates
- Development — two-week iterations with a demo after each
- Testing — functional, load, security checks
- Launch and stabilization — first 2-4 weeks post-launch under intensive monitoring
Cost is calculated individually after requirements analysis.
| Project Type | Estimated Timeline |
|---|---|
| Corporate website | 3-6 weeks |
| Online store up to 10,000 SKUs | 6-12 weeks |
| Large e-commerce with integrations | 3-6 months |
| Bitrix24 CRM implementation | 2-8 weeks |
| Migration from another CMS | 2-8 weeks |
| Security and performance audit | 3-10 days |