Work that breaks between systems,
connected into one
operational ledger
We design purchasing, sales, inventory and shipping workflows along with master data and permissions, then build a custom ERP and its operating interfaces. What a package can handle and what needs separate development are separated first.
role based permissions
in processing order
acceptance criteria agreed
into retain or replace
Spreadsheets still hold,
but the package does not fit
Inventory only one person understands
When receipts, shipments and stock are reconciled in spreadsheets, the rules stay in one person's head. The broken step is only investigated after a number turns out wrong.
Procedures configuration cannot hold
A standard package starts quickly, but unique ordering, approval and shipping procedures, or per-account terms, rarely fit inside its configuration limits.
Data that breaks between systems
When sales, inventory and shipping live in separate tools, the same record is entered twice and exceptions like cancellations, returns and corrections are handled from memory.
Assess, design, build, migrate:
scope is separated first
Assess the work
We review the ERP, spreadsheets and tools in use today and the teams that own them, then map the main workflows from order through receipt and shipping, including exceptions.
Design master data and permissions
We design item and account master data, workflow states and role based access. This is where the scope to keep in the package and the scope to build is separated.
Build the operating screens
Purchasing, sales, inventory and shipping screens are built in the order the people using them actually work. The Bespokit generation pipeline and standard modules are referenced so common functionality is not rebuilt from scratch.
Migrate, review, operate
The migration scope and responsibility for existing data, the terms for external APIs, and acceptance criteria are agreed, then the system goes through user review before it is operated.
What every operation needs
is checked as standard modules first
These are the work areas reviewed alongside your build scope. The modules actually included and their order are confirmed after the assessment.
Purchasing
Purchase orders, expected receipts, purchase prices and supplier terms managed as workflow states.
Sales orders
Quotes and orders connected to shipping instructions, per-account pricing and approval steps.
Inventory
Receipt and shipment history, warehouse locations, safety stock and the bill of materials tracked in one inventory ledger.
Shipping
The flow from shipping instruction through invoice to delivery status, kept connected.
Master data and access
Item, account and unit master data with role based access scope managed in one place.
Views and reports
Stock levels and work in progress presented in the screens operators use every day.
With ERP, separating scope comes
before adding features
When a package comes first
If accounting, tax and standard purchasing, sales and inventory are the centre of the work, the package's features and configuration range are checked first. The comparison includes the cost of rebuilding what it already solves.
When custom development is worth reviewing
If you have unique ordering, approval or shipping procedures, or data breaks between systems, separate modules and integrations are reviewed. Keeping the existing ERP and building only what is missing is also a candidate.
What to settle before the contract
Item and account master data, cancellation, return and correction scenarios, responsibility for data migration, terms for external APIs, and acceptance criteria. Whether accounting and tax functionality is included is agreed separately, and no project assumes every ERP function is delivered as a set.
Scope we have delivered
in our own projects
These are the scopes actually covered in published cases and Packs. It does not mean the same scope is delivered in every project.
Sales, inventory and shipping unified
The whole process from sales through shipping was unified into a single ERP. This is the scope delivered in the ASICLAND semiconductor ERP build, covering UX/UI planning and front and back end development.
Receipts, warehouses, safety stock
Receipts and shipments, warehouse locations, safety stock and the bill of materials connected to track stock levels. If inventory is the starting point, the Inventory Pack configuration can be reviewed first.
Build only what is missing
Keeping the current ERP and building only the missing work as separate modules is also reviewed. Scope is set after checking the target system's API, data access rights and synchronisation conditions.
Frequently asked questions
The conditions people check most often before adopting.
How is ERPkit different from a packaged ERP?
ERPkit is not a finished package being sold. It is a build approach that assesses your work and then designs and develops only the scope you need. If accounting, tax and standard purchasing, sales and inventory are the centre of the work, we point you at comparing a package's features and configuration range first.
Can we keep our existing ERP and build only inventory?
That can be reviewed. We confirm the existing product's API and data access rights, which system owns the inventory ledger, the synchronisation interval and the recovery conditions on failure, then set the scope of a separate module. We do not guarantee integration with a specific product without checking it.
Is accounting and tax functionality included?
It is agreed separately. Scope carrying statutory requirements, such as vouchers, tax invoices and closing, is often better kept in an existing package or external service. Whether it is included, and how it is integrated, is confirmed against your operating rules in a consultation.
How are timeline and cost decided?
They are estimated from the number of users and teams, the workflow stages, screens, data migration, external integrations, and the scope of acceptance, training and operational support. We do not quote a flat cost or duration before reviewing your current records and priorities.
Who is responsible for data migration?
The project contract separates responsibility for providing the source records, cleaning them, converting them and verifying the result. Cleaning that needs business judgement, such as item and account master data, is done with your team, and the acceptance criteria for the migrated result are agreed together.
Let us start from how
your work flows today
After reviewing the tools you use, your main workflows and the exceptions, we propose the first build scope and acceptance criteria.