Managing inventory, supplier orders and renovation projects at the same time, with spreadsheets and an inbox ?
At first, it holds together.
And then, one day, delivery notes get lost in email threads, inventories no longer match, stockouts hit in the middle of a project, and invoicing takes three days to reconstruct.
At KERN-IT, we worked with a Belgian startup based in Charleroi for five years, building IKOMOB, a custom inventory management software that brings together warehouse logistics and renovation project tracking in a single platform.
Five years on, IKOMOB has become the digital core of their business.
Here is how. And why a custom build was the only coherent answer.
A hybrid business that off-the-shelf ERPs simply miss
Our client is a young Belgian company active in renovation and real-estate asset management. Their daily life mixes several jobs at once : supplier purchasing, warehouse movements, projects to coordinate, subcontractors to manage, end clients to inform.
This kind of flow diversity is the norm in startups that grow fast.
It is also exactly what makes market ERPs hard to use in this context. Their modules are designed for established organisations, with homogeneous and stable processes. Not for a startup still inventing its own playbook week by week.
In 2019, the system was running on Excel, email and shared folders
When the project started, our client ran the business the way many growing companies do :
- spreadsheets for stock, orders and inventories,
- Word documents for delivery notes to job sites,
- email as the tracking system for subcontractor exchanges,
- several shared folders for project documentation.
This setup is viable at a small scale. And contrary to a common assumption, it is not a bad starting point. It is actually a strong sign of operational maturity, as we explain in turn your Excel into a platform.
The issue is not Excel. The issue is the moment Excel stops being enough.
And that moment always comes faster than expected.
Why a market ERP could not hold
Before writing any code, we honestly mapped what the market offered.
Generic WMS, Warehouse Management Systems, cover warehouse logistics well. But they ignore the project dimension.
Construction ERPs cover projects. But they are rigid on fine-grained inventory and expensive to configure for a young structure.
All-in-one suites like Odoo demand that the business bends to the software's logic. At the scale of a startup still building its processes, that costs dearly in training, in customisation, and in frustration. We expand on this in Odoo, an excellent ERP if you give it its proper place.
The choice became simple, once put clearly : build custom software, shaped around the team's actual processes, with a modular architecture designed to grow.
IKOMOB, a digital core designed for the business
IKOMOB is a web platform accessible from any browser. It articulates six core modules, designed to work together without ever forcing a rigid usage.
A product catalogue built for sellers and project managers alike
Every product has a complete record : name, internal reference, supplier reference, brand, description, picture, storage area.
Three price levels are tracked : supplier price, unit price, sale price. Installation or assembly cost is stored separately. This is what makes it possible to compute the real cost of a project without confusing materials and labour.
Each record also carries the packaging unit, the reorder threshold, and the latest physical inventory count with its date.
Multi-warehouse, and a stock figure that never lies
In IKOMOB, stock is not a counter you increment by hand.
It is a value computed in real time from the complete history of movements.
This architectural choice removes an entire family of bookkeeping bugs. Everything is reconstructible. No movement is silent.
At any moment, you can answer the simple question : how did this stock figure get here ? Without guessing.
The four-document workflow
This is IKOMOB's business differentiator.
Logistics are structured into four distinct document types. Each has its validation cycle (draft, then validated), and each is composed of multi-product lines with quantities.
- The supplier order is the purchase issued to a supplier.
- The receipt order records the physical reception of products.
- The internal order moves stock out of the warehouse to a project or to maintenance.
- The delivery order tracks the outbound delivery to the job site or the client.
This separation may look bureaucratic. From the inside, it is what allows the team to reconcile their numbers without pain : what was ordered, what was received, what went to the job site, what was delivered to the client.
Every gap is immediately visible. No one chases a lost document anymore.
Sites, contracts and BOMs
A site in IKOMOB represents a real-estate asset tracked by the client.
Address, status, owner, dates, total estimated budget. And a level of detail that fits the renovation business : gas, electricity and water meters with serial numbers, EAN and rating, primary and secondary.
Each site holds its documents, contracts and projects.
A project contract models operational reality : link between site, contractor, supplier and end client. The bill of materials, the BOM, is priced and accompanied by its document. Payments are staged : first deposit, final balance, with amounts and paid status.
And an audit log tracks every BOM change. With timestamp, and user. So that the history of an estimate is never lost.
Planning, tasks and assignments
The planning is structured by phases and by configurable task categories.
Every task carries its dates (start, end, requested delivery, estimated delivery), its priority, its business status, its on-site status. A flag controls its visibility on the client side, to show only what is relevant in an external portal.
The assignment module is the piece that links stock to project : product, project, quantity, zone. This is what lets a site manager know exactly what should go where, and what lets the inventory manager prepare the matching delivery orders.
Stock and project are no longer two worlds. They are the same movement.
Financial reports
Each contract generates one or more financial reports that consolidate the updated BOM, total work completed, total paid, balance due, invoiced and paid statuses, and free notes.
Coupled with on-site reports including photos, this gives the client a 360-degree view of every project's financial health. In real time.
Tech serves the business, not the other way around
At KERN-IT, we do not believe technology is an end in itself.
IKOMOB runs on a mature and proven stack : Python, PostgreSQL, React. No fashion, no technological bet.
The real work is not in choosing these bricks. It is in the way they are assembled around the client's actual business, over time, without accumulating technical debt and without massive rewrites.
This is exactly what we describe in whyPython is a strong choice for your project and in PostgreSQL, an essentialdatabase.
Our method : step by step, without rigidity
IKOMOB was not delivered in one shot.
The project followed our usual approach, in several phases over five years : first the technical foundation and the product catalogue, then the document workflow, then the sites and contracts module, then the planning and assignments, and finally the financial reports and the audit log.
Every phase went into production as soon as it was useful.
This way of operating, incremental and pragmatic, lets the startup use the platform from the first weeks. Lets it evolve with the reality of the field. And avoids the classic trap of the big bang, where you build for a year before discovering the need has changed.
It is also what allows custom software to hold over time. Without rewrites. Without painful migrations. And that is exactly the subject of application maintenance, which we cover in detail in why custom software without maintenance loses its value.
Five years later
IKOMOB has become the central nervous system of the client's activity.
- More than five years of continuous use, without rewrite, without painful migration.
- Six interconnected business modules, from product catalogue to financial reports.
- Four document types structuring the flow from warehouse to job site.
- Total traceability of stock movements, never reconstructed by hand.
- Integration with other client platforms, sharing the same backend to avoid duplicating data.
- A dedicated KERN-IT team over the long term, ensuring the continuity of domain knowledge.
No spectacular revenue figure to brag about. Just a sober observation : the business runs, without friction, for five years.
This is what we call a digital core that holds.
Why custom software rather than a generic SaaS
The return on investment of custom software for a startup rests on three points.
First, you do not bend your business to a vendor. It is the other way around. When you discover mid-course that a workflow must change, the software follows. No vendor contract to renegotiate, no third-party roadmap to wait for.
Second, there is no hidden configuration cost. Configuring a market ERP over five years often costs more than a well-scoped custom build. Especially when the business is hybrid, like IKOMOB.
Third, you own the code and the data. No vendor dependency, no risk of end-of-support or unilateral pricing change. This is the very definition of a durable digital asset.
Three simple principles. But this is exactly what market ERPs cannot offer to a startup still inventing its own playbook.
Recurring questions
Why build custom inventory management software rather than use an off-the-shelf ERP ?
Standard ERPs fit organisations with stable, homogeneous processes. For a startup with a hybrid business mixing stock and projects, the hidden cost of configuration and customisation quickly exceeds the cost of a custom build that fits the actual processes and grows with them.
How long does it take to build custom inventory management software ?
A first usable version ships in three to six months depending on complexity. The step-by-step approach puts the platform in users' hands within the first weeks, and lets it grow with feedback from the field. IKOMOB started this way in 2019.
Is custom software suitable for a startup ?
Yes, provided it is scoped pragmatically : modular architecture, mature stack, short-term scope. IKOMOB is the proof. Started light in 2019, it grew over five years without a rewrite.
How does maintenance work for custom software over time ?
With a stable technical partner who knows the code and the business. A predictable yearly envelope, and a dedicated team that ensures the continuity of domain knowledge. This is what application maintenance really means : not a cost endured, an investment.
Does the client own the code ?
Yes, fully. No proprietary lock at KERN-IT. The client owns their code and their data. They can, in theory, walk away with it at any moment.
In conclusion
Custom inventory management software is not a matter of technology.
It is a matter of fidelity to the actual business, of long-term mastery, and of architecture that grows without debt. The rest (Python, PostgreSQL, React, whichever bricks you prefer) is just a means.
At KERN-IT, we build this kind of digital core for more than ten years, for Belgian startups and SMBs that do not fit the boxes of a standard ERP.
If that sounds like your situation, you know where to find us.
