Custom ERP builds and module development across finance, inventory, supply chain, procurement, manufacturing, and order management. Integration into your existing stack, legacy-ERP migration, named tech lead, weekly demos.
ERP development means building the operational backbone that finance, inventory, procurement, manufacturing, and order teams all read from and write to. A custom or extended ERP earns its cost when the off-the-shelf platform forces you to bend your real process to its data model, when the per-module license fees outrun the build budget, or when a required workflow has no module at all. Below that bar, configure what you bought; above it, build.
When the way you cost a job, allocate inventory, or stage an approval is a genuine operating advantage, a packaged ERP flattens it into its own data model. Custom modules keep the process intact instead of forcing your team to work around the software every day.
Enterprise ERP pricing scales with named users, modules, and connected entities. Past a few dozen seats, a single high-friction module is often cheaper to build and own than to license for three years. The decision is a spreadsheet, not a sales call.
Some operations have a step the packaged ERP simply has no module for: a specialized fulfillment rule, a regulatory report, an industry-specific MRP variant. Bolting a custom module onto a healthy core beats abandoning the platform you already trust.
Most ERP work concentrates in six modules. Each has a different data model, a different risk profile, and a different integration surface. We scope and price against the module, not a generic hour bucket, and we build them so each can run standalone or join a connected platform later.
6-14 weeks
General ledger, accounts payable and receivable, multi-entity consolidation, and period close. This is the module where correctness is non-negotiable: every transaction is double-entry, every number reconciles, and the audit trail is append-only. We model money in integer minor units, never floats, and treat the ledger as an event log so a balance is always reconstructable. Tax logic and revenue recognition rules are documented in code, not buried in a spreadsheet macro.
5-12 weeks
Real-time stock levels across locations, lot and serial tracking, valuation methods (FIFO, weighted average, standard cost), and cycle counting. The hard problem is concurrency: two warehouses committing the same unit at the same instant. We solve it with row-level locking and reservation records in PostgreSQL, so the physical count and the system count never silently diverge. Barcode and RFID inputs feed the same reservation model the order module reads from.
6-12 weeks
Demand planning, supplier scorecards, lead-time tracking, and multi-echelon stock policy. The supply-chain module turns the raw signals from inventory and order management into reorder points and safety-stock targets your planners can actually trust. We expose every forecast assumption as an editable parameter, because a model nobody can adjust is a model nobody uses. Inbound logistics events arrive as webhooks and land in the same event log finance reconciles against.
5-10 weeks
Purchase requisitions, approval routing, three-way match (PO, receipt, invoice), and vendor management. Procurement is mostly about controls: who can request, who must approve, and what blocks an invoice from being paid. We build the approval matrix as data, not hardcoded rules, so finance can change a threshold without a deploy. Three-way match exceptions surface in a single queue instead of an inbox, and every override is logged with a reason and an approver.
8-18 weeks
Bills of material, work orders, capacity planning, and material requirements planning. MRP is the most computationally demanding ERP module: explode a multi-level BOM against on-hand stock, open POs, and a production calendar, then suggest what to make or buy and when. We run the planning engine as a background job with a deterministic, reproducible output, so a planner can re-run the same scenario and get the same answer. Shop-floor data collection feeds work-order progress back to inventory in real time.
5-12 weeks
Sales orders, fulfillment routing, returns, and the customer-facing status view. Order management is where the ERP touches revenue and the customer at the same time, so it carries the highest external risk of the six modules. Every state change (placed, allocated, picked, shipped, returned) is an event other modules subscribe to, which keeps inventory, finance, and supply chain in agreement without nightly batch reconciliation. For commerce-led operators this module connects directly to the storefront.
| module | owns | reads from | guards against |
|---|---|---|---|
| Finance | Ledger, AP/AR | Procurement, Orders | Numbers that do not reconcile |
| Inventory | Stock, valuation | Orders, Manufacturing | Phantom or oversold stock |
| Supply chain | Forecasts, policy | Inventory, Orders | Stockouts and dead stock |
| Procurement | POs, approvals | Supply chain, Finance | Unauthorized or duplicate spend |
| Manufacturing | BOMs, work orders | Inventory, Orders | Building what you cannot sell |
| Order management | Orders, fulfillment | Inventory, Finance | Promising what you cannot ship |
ERP projects fail in a recognizable way: scope balloons, the go-live date slips, and a one-year project becomes a two-year sunk cost. Four operating principles keep an engagement predictable. They are not marketing; they are the checkpoints that stop that exact failure pattern.
Every engagement has one named senior engineer who attends every call, writes the weekly status, and is accountable for the data model. No agency-side account-manager layer between you and the code, and no rotating cast of contractors who never see the whole system.
We ship one module to a usable state before starting the next, and every Friday there is a recorded walkthrough of real code with a written what-shipped/what-slipped summary. A big-bang ERP go-live is the riskiest pattern there is; incremental module delivery retires that risk early.
Engagements ship against a scoped requirements document tied to your real process maps. Any change beyond that document triggers a written change request with a cost and a timeline delta. ERP scope creep is the number-one budget killer; making every change explicit is how we keep it visible.
Every contract names who owns the code (you), who owns the database (you), and what handover looks like if you take the system in-house. Because an ERP is your operational backbone, lock-in here is far more dangerous than on a marketing site. No retainer traps, no ownership gray zones.
Migrating off a legacy or end-of-life ERP is the highest-stakes work we do: the data is your company's memory, and a botched cutover can stop shipping and stop billing on the same day. We never flip a switch over a weekend. We run the old and new systems in parallel, reconcile every record, and cut over only when the numbers agree for a full close cycle.
Two-week pass over the legacy schema, the undocumented customizations, and the data quality. We profile every table for nulls, orphans, and format drift, and produce a risk register before we touch a single migration script. Most legacy ERPs hide a decade of workarounds in places nobody remembers; the audit finds them first.
Every legacy field maps to a new field, gets transformed, or gets explicitly retired with a documented reason. Transformation logic lives in version-controlled, testable code, not a manual import wizard, so the same input always produces the same output and a failed run can be replayed.
Both systems run live for at least one full accounting period. Daily reconciliation reports flag any record where the old and new systems disagree, and we drive that delta to zero before anyone trusts the new numbers. This is the step that separates a clean migration from a six-month firefight.
Cutover happens on a planned date with a written rollback path and the legacy system kept read-only for a defined retention window. If anything fails the reconciliation gate, we do not go live. A go-live with a credible rollback plan is calm; one without is a gamble with your operations.
| path | best when | typical horizon | main risk |
|---|---|---|---|
| Configure / extend | Core ERP fits 80%+ of process | 2-8 weeks | Upgrade path breaks customizations |
| Custom modules | Core is fine; one or two gaps | 5-18 weeks/module | Integration drift with the core |
| Full custom ERP | No platform fits the operating model | 6-18 months | Scope and total cost of ownership |
| Migrate then extend | Legacy ERP is end-of-life | 3-9 months | Data reconciliation at cutover |
An ERP runs for a decade, so stack choice is a maintenance decision, not a fashion decision. We default to mature, hireable tools your future team can read on day one, and we integrate with the systems you already run rather than forcing a rip-and-replace.
| layer | default |
|---|---|
| Backend language | TypeScript / Python / Go |
| API layer | REST + typed schema |
| System of record | PostgreSQL |
| Event / job log | Postgres + Redis |
| Reporting DB | ClickHouse / BigQuery |
| Auth + RBAC | Clerk / Supabase / Auth0 |
| Finance billing | Stripe |
| Integrations | Webhooks + queues |
| Deploy | AWS / Vercel / on-prem |
| Observability | Sentry + audit log |
PostgreSQL handles the transactional core of every ERP module we build: strong consistency, row-level locking, and a mature ecosystem that finance and inventory both depend on. We treat the database as the system of record and design the schema first, because in an ERP the data model is the product. Security follows the OWASP ASVS baseline, with least-privilege access and an append-only audit trail on every financial record.
For integrations we lean on documented APIs and event queues rather than brittle screen-scraping or nightly CSV drops. Where you already run a platform like Odoo or SAP, we build against its supported integration surface and connect cloud infrastructure on AWS when the workload calls for it. We reach for a specialized tool only when a boring default provably fails a load test, and we document the reason every time with an architecture decision record (see the web.dev performance guidance we hold front-end dashboards to).
The questions operators ask most often before booking a scoping call: when custom ERP beats configuring a packaged one, which modules we build, how long a build takes, how migration works, how we handle security and audit, and how we price.
Three conditions usually justify custom ERP work. One, a core workflow is an operating advantage that a packaged data model would flatten. Two, the three-year license cost across modules and seats crosses the build-and-own budget. Three, a required step has no module on any platform you evaluated. If fewer than two hold, configure the ERP you bought or add a focused custom module to it. If two or more hold, building or substantially extending starts to pay off. Most operators land on custom modules around a healthy core, not a full from-scratch rebuild.
Six core modules: finance and accounting (general ledger, AP/AR, multi-entity close), inventory management (multi-location stock, lot and serial tracking, valuation), supply chain (demand planning, supplier scorecards, reorder policy), procurement (requisitions, approval routing, three-way match), manufacturing and MRP (bills of material, work orders, capacity planning), and order management (sales orders, fulfillment, returns). Each can ship standalone or join a connected platform, and we build the integrations and data layer that keep them in agreement without nightly batch reconciliation.
It depends on path. A single module runs 5 to 18 weeks depending on complexity, with MRP at the long end and inventory or procurement toward the shorter. A multi-module custom platform runs 6 to 18 months, delivered module by module so you get usable value before the whole thing is done. A legacy migration runs 3 to 9 months including the parallel-run period. Every engagement starts with a 2-week discovery sprint that produces process maps, a scoped requirements document, and a fixed-price proposal, so the timeline is grounded in your real process before any contract is signed.
In four phases and never as a weekend switch-flip. First, a two-week audit and data-profiling pass to find the orphans, nulls, and undocumented customizations. Second, version-controlled transformation rules that map every legacy field to a new field, transform it, or retire it with a documented reason. Third, a parallel run for at least one full accounting period with daily reconciliation reports driving every old-versus-new delta to zero. Fourth, a planned cutover with a written rollback path and the legacy system kept read-only for a defined retention window. If the reconciliation gate fails, we do not go live.
An ERP holds financial and operational data, so the security bar is high from day one. Every engagement starts with a threat model, a data-flow diagram, and a secret-management audit. We default to encryption at rest and in transit, least-privilege role-based access, and an append-only audit trail on every financial record so who-changed-what is always answerable. The OWASP ASVS Level 2 checklist is our baseline. For regulated operators we add SOC 2 gap analysis, GDPR records of processing, or PCI DSS scope reduction where order management touches card data, scoped to what your sector actually requires.
Every engagement is scoped. Discovery sprints run two weeks at a fixed price. Module builds and platform work are scoped against a written requirements document with a fixed bid plus an explicit change-request process. Migrations are scoped against the data-profiling audit, because the data quality drives most of the effort. Retainers for ongoing module work and support are monthly with a minimum and a cap. We do not publish tiered packages, because a single procurement module and a full multi-entity ERP platform sit at wildly different scopes. Book the scoping call; a written scope and quote land in 48 hours.
30-minute call to map the process, the modules in scope, and the migration risk. Written scope and fixed-price quote within two business days. No proposal decks, no sales theater.
Published .
