ERP System Development for Business
We design and build ERP systems around the processes of a specific company: production, warehouse, finance, orders, and reporting — in a single environment with roles and access permissions. Based in Almaty, we run projects across Kazakhstan: from architecture to ongoing support.
- Stock
- Finance
- Production
When does a business need a custom ERP system?
A custom ERP makes sense when a company's records are scattered across spreadsheets and separate programs: production, warehouse, finance, and orders live in different places, data is reconciled by hand, and management never sees the full picture. An ERP system brings these processes into a single environment with roles, statuses, and reporting built on live data.
Who a custom ERP is for
Manufacturing companies
Orders, shop floor, material consumption rates, cost, and shipping — in one system instead of scattered spreadsheets. You can see workload and deadlines for every order.
Trade and distribution
Warehouse, purchasing, stock levels across branches, and settlements with suppliers. The system itself shows what is running low in the warehouse and which orders are stuck.
Companies that have outgrown Excel
Records have spread across dozens of spreadsheets and messengers, and manual-entry errors have started costing money. An ERP pulls the data into one environment with change history and assigned owners.
Businesses running 1C for accounting
1C covers accounting, but not day-to-day operations: orders, production, statuses. An ERP complements it and keeps the data in sync, eliminating double entry.
What problems an ERP system solves
How does an ERP help manage production?
An ERP links the order, the production job, and material consumption: you can see shop-floor workload, deadlines for every order, and actual cost. Plan is compared against fact without manual summaries.
What does an ERP do for the warehouse?
The warehouse module tracks stock in real time: receiving, reserves against orders, transfers between warehouses, stocktaking. Purchasing relies on accurate stock levels rather than the storekeeper's memory.
How does an ERP bring order to finances?
The system tracks cash flow, settlements with suppliers and customers, cost, and margin by order. The financial picture is built from primary transactions, not from spreadsheets reconciled at the end of the month.
Why do order statuses matter in an ERP?
Every order moves through a configured chain of statuses — from request to shipping and payment. At each stage the owner and deadline are visible, and stuck orders can be found in seconds.
What does management see in ERP reports?
Reports are built on the system's live data: revenue, workload, stock, receivables — broken down by period, department, and employee. No waiting for someone to compile a summary by hand.
What ERP development includes
items
- Process discovery and system architecture design
- Data model and business logic built around your processes
- Modules: production, warehouse, finance, orders, staff
- Roles and access permissions for every department
- Order status chains and approval workflows
- Reporting and dashboards for management
- Integrations: 1C, banks, payment services, external APIs
- QA: testing business logic and access permissions
- Data migration, staff training, department-by-department launch
- Ongoing support and roadmap-driven development
How much ERP costs: InterLAB references
We roll the system out in stages: the first phase solves the main pain, other modules follow the roadmap.
| Format | What is included | Reference | Timeline |
|---|---|---|---|
| First phase | 1–2 processes (e.g. warehouse and sales), roles, reports, 1C sync | from 5 million ₸ | 2–4 months |
| Turnkey ERP | 4–6 modules, roles and permissions, dashboards, integrations, data migration | from 10 million ₸ | 4–8 months |
| Support | Updates, monitoring, backups, roadmap improvements | from 300,000 ₸ per month | after launch |
These are ranges, not a price list: we give an itemised estimate by phase after a brief and a process review. The price grows with the number of modules, roles, integrations and the amount of data to migrate.
Contract, payment and warranty
The same terms for every B2B project: payments are tied to accepted results, and a stage price does not change after it starts.
| Term | How we work |
|---|---|
| Payment for smaller projects | Projects up to 3 million ₸ and the MVP sprint: 50% upfront, 50% after acceptance |
| Payment for larger projects | ERP, CRM, SaaS, portals — in stages of 1–2 months: 30% before a stage, 70% after the stage is accepted and signed off |
| Stage price | Fixed before the start. New requirements are estimated separately and taken on only with your approval |
| Warranty | 6 months after acceptance: we fix defects in our code free of charge — whenever the system does not work as agreed |
| Not covered by the warranty | New features and changed requirements, as well as failures caused by changes in third-party systems (a 1C update, a new bank or service API) — that is support |
| Code and access | Owned by the client from the first commit: repository, servers and keys are on your accounts. NDA on your template or ours |
The terms are fixed in the contract before work begins.
ERP modules: what they cover and what they connect to
A typical module map, not an off-the-shelf product: the set and boundaries of modules are defined during discovery. The first phase usually covers 1–2 processes; other modules are added along the roadmap.
| Module | What it covers | Connected to |
|---|---|---|
| Sales and orders | Quotes and invoices, price lists and client-specific terms, shipment and payment tracking | CRM, warehouse, finance; orders from the website and Kaspi |
| CRM | Clients, contacts and deals, communication history, tasks and reminders for managers | Sales and orders, email and messengers; AmoCRM or Bitrix24 if a CRM already runs separately |
| Warehouse and purchasing | Supplier purchasing, reorder requests at minimum stock, batches and expiry dates, bin-location storage | Sales (reservations against orders), production (consumption and output), finance (supplier payments) |
| Production | Bills of materials and routings, production orders, output and scrap tracking | Orders (what to produce), warehouse (materials and finished goods), finance (cost of goods) |
| Finance | Payment calendar, departmental budgets, payments on orders and to suppliers, management profit report | Bank statements, payment services, 1C (accounting) |
| HR | Employees and departments, schedules and timesheets, output, granting and revoking access on hiring and departure | Production and sales (output and targets), 1C (payroll and HR records) |
| Dashboards and analytics | A home screen with metrics for each role, plan vs. actual, drill-down from any figure to the source documents | All modules; export to Excel and BI systems |
Modules share one database: a document is entered once and is visible in every module that needs it. If some processes already run in 1C or an off-the-shelf CRM, the ERP module does not duplicate them but exchanges data with them.
Roles and permissions, approvals, automation: what works across all modules
These cross-cutting mechanisms are built into the architecture from the first phase: adding them to a running system costs more than designing them up front.
Roles and access permissions
Permissions are set by role and department: a storekeeper sees their own warehouse, a manager sees their own clients, a branch head sees their own branch. Who can create, post and cancel documents is configured separately.
Approvals
A discount above the threshold, a purchase over budget or a shipment to a client with outstanding debt goes to the responsible person for approval. The decision and comment are saved on the document.
Automated actions
The system handles repetitive steps itself: it reserves stock when an order is confirmed, assigns a task to the warehouse, generates an invoice and notifies the client of status changes.
Audit log and period closing
Every change is recorded: who, when, what it was and what it became. A closed period is protected from edits — errors are fixed with a separate adjustment, not by rewriting figures retroactively.
System API
The website, mobile app, branches and partner systems work with ERP data through a documented API. Access uses keys with limited permissions, and every call is logged.
Data migration: how we move off the old system
Data migration is a separate stage of the plan, not the last day before launch. The earlier problems in the source data surface, the cheaper they are to fix.
- 01
Inventory of sources
We map where the data lives today: Excel spreadsheets, 1C, the old program, CRM exports. For each entity — clients, products, stock, amounts owed — we record the source and the person responsible.
- 02
Cleaning and mapping
We remove duplicates, bring reference data into one format and map fields between the old and new systems. Disputed records are resolved by an employee who knows the data, not by a script.
- 03
Trial migration
We load the data onto a test environment and reconcile control figures: item counts, stock by warehouse, amounts owed. Discrepancies are fixed before launch.
- 04
Cut-over date
We set the date as of which stock and balances are fixed. The final migration follows the tested scenario — the same one used in the trial run.
- 05
Old system in read-only mode
By agreement, the old system stays available for reading and reconciliation for a while. It is switched off once the new system's reports match the familiar figures.
The volume and quality of the source data affect the timeline and the estimate, so we assess them during discovery.
Useful before we talk
How ERP development works
- 01
Brief and discovery
We look at how the company currently handles orders, warehouse, and finances, and record the bottlenecks and goals. Time and cost estimate after the brief.
- 02
Design
Architecture, data model, roles, and status chains. We sign off on prototypes of the key screens before development starts — changes are cheaper at this stage.
- 03
Development in phases
We split the system into modules: the first phase to go live is the one that fixes the biggest pain point. Every two weeks — a demo of working functionality.
- 04
Launch and data migration
We migrate reference data and stock balances, train staff, and bring departments online one at a time — without stopping the company's work.
- 05
Support
Monitoring, backups, improvements, and roadmap-driven development. The system grows with your processes: new modules, reports, integrations.
Get your project assessed before development starts
Describe the task in the form below — we reply within a business hour and suggest the next step: a call, a review or an estimate.
Architecture and technology
We build ERP systems as web applications: the system runs in a browser on any device, requires no installation, and updates centrally. The backend on Node.js and PostgreSQL is designed for growing data volumes and user counts — scaling will not require a rewrite. Roles and access permissions are built in at the architecture level, while strict typing and QA lower the cost of an error in your records.
- Next.js
- React
- TypeScript
- Node.js
- PostgreSQL
- Redis
- WebSocket
- Docker
- CI/CD
Integrations: 1C, banks, APIs
An ERP rarely lives on its own. We set up an exchange with 1C: reference data, documents, and stock balances stay in sync without double entry — accounting keeps working in its familiar environment. We connect banks, payment services, Kaspi, and messengers; when needed, we design the system's own API for branches and partners.
1C, Kaspi, Banking APIs, WhatsApp, Telegram, REST API, Webhooks, Excel import/export
InterLAB projects in this area
Real work with a dated status: what's live, what's still in development, where it's a demo.
status as of Oct 12, 2026
Questions about ERP development
InterLAB references: a first phase (1–2 processes, 1C sync) starts from 5 million ₸ and takes 2–4 months; a turnkey ERP with 4–6 modules starts from 10 million ₸ and takes 4–8 months; support starts from 300,000 ₸ per month. These are ranges, not a price list: we give an itemised estimate by phase after a brief and a process review. The system can be rolled out in stages — no need to pay for the whole scope at once.
Off-the-shelf systems dictate their own processes — the company adapts to them and pays for modules it does not need. A custom ERP mirrors your processes: roles, statuses, documents, and reports are designed around how the business actually works.
Yes. Typically 1C remains the accounting system, while the ERP covers operations: orders, warehouse, production. An exchange between the two systems ensures every piece of data is entered only once.
Not necessarily. If sales are simple, clients and deals live in the ERP's own CRM module — no second system and no sync. If your sales team already works in AmoCRM or Bitrix24 and it suits them, the CRM stays: the ERP receives won deals from it and sends back order and payment statuses. A separate custom CRM makes sense when sales are a complex process in their own right, with a pipeline of their own.
The operational side, yes: employees and departments, schedules, timesheets, output, access rights. Payroll, taxes and statutory HR reporting usually stay in 1C or the accounting system — the ERP passes timesheets and output there so they are not entered twice.
It depends on the scope. The first phase — the module that fixes the biggest pain point — goes live before the full system, so the business sees results before the project ends. The stage-by-stage plan is set in a roadmap after discovery.
The client: the repository lives in your organization, the infrastructure runs on your accounts, and the documentation is handed over. Changing vendors will not stop the system.
The system moves into support: monitoring, backups, improvements, and roadmap-driven development. An ERP is a living product that changes along with the company's processes.
Related services
Got a project?
We'll scope and estimate it — for free.
Tell us about the product or the problem. After reviewing the task we'll come back with an architecture, a timeline and a price for the first version.
- Scope and risks estimated before we start
- NDA — yours or ours
- Work starts within a week