Home / Product development / Custom ERP software development
Your buyers check stock in one spreadsheet and prices in another, or you pay for a large ERP and still run purchasing around it. We build ERP modules one at a time around your own items, suppliers, locations and approval limits, sync availability to your sales channels, and hand finished entries to the accounting software you keep. Coding agents help write the screens, imports and reconciliation checks; senior engineers write the stock, cost and approval rules.
A buyer checks stock in a spreadsheet, the agreed price in a supplier’s email and the approval in a manager’s inbox. The warehouse learns what is coming when the lorry arrives, and finance types the order again from the invoice. With one record per item, supplier and price, each step starts from the one before, and every stock figure can be traced.
A buyer, a storekeeper and a finance clerk will each describe a different process. These six conversations settle which one the modules follow, and which item list is the real one.
How a need becomes a purchase order, a delivery and an entry in the books today, who touches it at each step, and where the same figures are typed twice.
Which list of items, units, suppliers and prices is the real one, where the copies disagree, and who may change a price or add a supplier.
Where stock is held and counted, what counts as reserved or available to sell, and what should happen when an item drops below its reorder point.
Which purchases need a signature, up to what amount each buyer and manager may approve, and who signs when the usual approver is away.
The tools that stay, such as accounting software, an online shop or a booking engine, what each sends and receives, and which one has the last word on each figure.
A named list, such as the stock spreadsheet, the approval email chain and the invoices re-keyed at month-end, each with an owner who confirms when it is no longer used.
On an ERP module, coding agents take the volume: order and receipt screens, supplier imports, reconciliation scripts and reports. Senior engineers write the reservation, costing and approval rules, because a wrong formula there flows into every stock value and month-end report after it, and a leaking approval limit lets an order out unsigned.
AI-native product developmentAgents help write the import and reconciliation scripts, so every item, supplier and opening balance is compared with the old system, not a sample, before anyone relies on the new figures.
Faster builds make a module-by-module rollout affordable: purchasing goes live while the old system still runs stock and invoicing, and the two are reconciled until the next module takes over.
How stock is reserved, valued and costed is written by a senior engineer and tested against last year’s transactions, because a wrong formula spreads into every report after it.
Agents turn a year of your supplier invoices, with partial deliveries, price changes and returns, into test cases, and a senior engineer reviews each matching rule against them.
Stock valuation and reorder runs are load-tested on years of real transactions, so month-end reports are ready when finance starts closing, not hours after.
Six situations, from a stock spreadsheet to a second site or sales channel.
The spreadsheets become the migration source. We trace where each figure comes from and who updates it, and the first module replaces the sheet people argue about most, usually stock or purchase orders.
If the team works around most of its modules, we replace the ones they avoid, keep those that do their job, and connect old and new while both run. If configuration would fix it, we say so.
Growth tends to show in purchasing first: more suppliers, more orders, more people approving. We start there, with item and supplier records that the stock module reuses when it follows.
The undocumented adjustments are the risk. We export years of transactions, trace each manual correction to the person who makes it, and write the rule down before anything moves.
We read its stock and costing logic first and put tests around the reports finance signs. Those keep working while the code underneath changes, one module at a time.
Locations are in the stock model from the first module, so a new warehouse or shop starts as configuration. The real work is its own reorder rules, suppliers, lead times and channel sync.
Five stages. Each ends in something finance or the warehouse can check: screens tried, an import reconciled, a month closed on both systems.
A buyer, a storekeeper and someone from finance walk a purchase order, a goods receipt and a stock count through clickable screens before any code is written.
FigmaItem, supplier and stock data is imported and reconciled in every sprint, so migration problems surface while the screens are still being built, not in the week of the switch.
.NET or Node.js, React, PostgreSQLFinance closes one month on both systems. Stock, open orders and totals must match, and every difference is traced to its cause before a cut-over date is set.
Reconciliation reportsOpening balances and open purchase orders move on an agreed date, approval limits are set per person, and a security review runs before the old system stops taking entries.
Migration scripts, security reviewThe first module’s records stay as they are. The next module adds its own screens and rules on top of them, and the old system loses another job.
Exception and usage reportsEvery module writes to the same stock ledger and reads the same item and supplier records, so those shared parts are built once, with the first module.
By a buyer, or by a reorder rule when stock runs low
On hand, on order, and the supplier’s current price
Signed off when the amount is over the requester’s limit
To the supplier by email, portal or API
Counted against the order; shortfalls stay open
Invoice matched, entry exported, stock value updated
Supplier lead times and shortfalls reset reorder points
Items, units, suppliers and price lists kept in one place with a history of every price change, imported from your spreadsheets with each conflict listed for a person to settle.
A ledger by item and location that records every movement, from received and reserved to picked, counted and adjusted, so any stock figure can be traced to its cause.
Rules by amount, category and person, a delegate for each approver who is away, and a record of who approved which order, at what amount and when.
Availability and orders synced with your online shop, booking or warehouse systems through their APIs, with retries and a log of every message, so a stopped sync is noticed the same day.
Each supplier invoice is checked against its order and what arrived, then exported in the format your accounting software imports, so there is never a second set of books.
.NET or Node.js services, React front ends and PostgreSQL, kept in your repository and hosted with the cloud provider you choose, under an account your company holds.
None of the three is a full ERP. Each covers one part an ERP needs: availability kept in step across sales channels, supplier ordering for HoReCa buyers, and reporting across a hotel’s operations.
Complete software buildHotel-Spider
A booking engine, a central reservation system holding availability and prices, and a channel manager that syncs booking data to every connected portal. Our senior team has full responsibility for development and delivery, and advises on architecture.
Read the Hotel-Spider case studyIt depends most on migration: how many items, suppliers and years of history move, and how clean they are. Then come the connected systems and approval rules. Set it against what the current setup costs you in licences, plugins and hours spent re-typing orders. Each module gets a written figure after discovery, so you can weigh one against the other before you commit.
Often, yes. If your purchasing and stock work much like other companies’ in your sector, a standard ERP costs less to run, and we will say so. Custom modules earn their cost where your process is the advantage, or where you pay for a large ERP, use a fraction of it and run the rest in spreadsheets.
The one where people re-type the most and make the most mistakes today, as long as later modules can build on its records. That is usually purchasing or stock. Reporting is rarely the right start: a report built on item and stock records nobody trusts only repeats their errors faster.
When a month-end closes the same on both systems. The date follows your closing calendar and how clean the item and supplier lists are, more than the screens, which agents help build quickly. The plan after discovery names the month the parallel run starts and the month the old system stops taking entries for that module.
It works with it. The books stay in the accounting software your finance team uses today, with its tax rules. The modules export matched invoices, stock value and cost of goods in the import format it already accepts. Online shops, booking engines and warehouse tools sync through their APIs, and a tool without an API gets a scheduled file exchange instead.
In rehearsals. A test import of items, suppliers, open orders and opening balances runs early and is reconciled line by line against the old system. Conflicts, such as one supplier under three names, are listed for a person to settle. The final import repeats the same scripts on cut-over day, after a month-end both systems agree on.
Yes. Locations are part of the stock model from the first module, so a new warehouse or shop is set up rather than built. Transactions pile up fastest, so closed periods are archived by year and daily screens read only current stock and open orders. Receiving and picking stay as quick in the fifth year as in the first.
You do. IP assignment is part of the contract. The code sits in your repository and every stock movement in a database under your hosting account, so nothing runs on accounts of ours. Approvals and price changes are logged with who made them, which helps when an auditor asks how a stock value was reached.
Small changes, such as a new supplier file format, another location or a changed approval limit, ship as they come up, built by the engineer who wrote the stock rules. The next module is scoped and quoted once you choose it, and works on the same records, so the old system is retired one job at a time.
The sales side that feeds the modules orders, agents for the paperwork between systems, and a developer for the integrations.
Send a photo of the stock spreadsheet, or tell us which ERP you pay for and what your buyers still do outside it.
In the first call we name the module we would start with and the spreadsheet it would retire. If a standard ERP would serve you better, that is what we recommend.
We sign an NDA before discussing your data in detail. We reply within 24 hours.
