Custom ERP and module development for finance, inventory, supply chain, procurement, manufacturing, and order management. Integration into your stack, legacy migration, named tech lead, weekly demos.
ERP development means building the operational backbone that your finance, inventory, procurement, manufacturing, and order teams all read from and write to. A custom ERP earns its cost when the packaged platform forces you to bend your real process to its data model, when per-module license fees outrun your build budget, or when a workflow has no module at all.
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 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. The ledger works as an event log, so any balance is always reconstructable. Tax logic and revenue recognition rules live in code, not spreadsheet macros.
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 claiming the same unit at once. We solve it with row-level locking and reservation records in PostgreSQL. Physical count and system count stay in sync. 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. This module turns signals from inventory and order management into reorder points and safety-stock targets your planners can trust. Every forecast assumption is an editable parameter: 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 about controls: who can request, who must approve, and what blocks payment. 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 one queue. Every override is logged with a reason and approver.
8-18 weeks
Bills of material, work orders, capacity planning, and material requirements planning. MRP is the most computationally demanding 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. The planning engine runs as a background job with deterministic output: a planner re-runs the same scenario and gets the same answer. Shop-floor data feeds work-order progress back to inventory in real time.
5-12 weeks
Sales orders, fulfillment routing, returns, and customer-facing status. Order management touches revenue and the customer at once, so it carries the highest external risk. Every state change (placed, allocated, picked, shipped, returned) is an event other modules subscribe to. Inventory, finance, and supply chain stay 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 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, undocumented customizations, and data quality. We profile every table for nulls, orphans, and format drift. A risk register is produced before touching a single migration script. Most legacy ERPs hide a decade of workarounds; the audit finds them first.
Every legacy field maps to a new field, transforms, or retires with a documented reason. Transformation logic lives in version-controlled, testable code, not a manual import wizard. Same input always produces the same output. 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. We drive that delta to zero before anyone trusts the new numbers. This step separates a clean migration from a six-month firefight.
Cutover happens on a planned date with a written rollback path. The legacy system stays 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: strong consistency, row-level locking, and a mature ecosystem that finance and inventory depend on. We treat the database as the system of record. Data model is designed first, because in an ERP the data model is the product. Security follows the OWASP ASVS baseline: least-privilege access and an append-only audit trail on every financial record.
For integrations we use documented APIs and event queues, not brittle screen-scraping or nightly CSV drops. Where you run Odoo or SAP, we build against its supported surface and connect AWS when the workload calls for it. We reach for a specialized tool only when a boring default provably fails a load test. Each time, we document the reason 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 work. First, a core workflow is an operating advantage that a packaged data model would flatten. Second, the three-year license cost across modules and seats exceeds the build-and-own budget. Third, a required step has no module on any platform you evaluated. If two or more of these hold, building or extending starts to pay off.
If fewer than two hold, configure what you bought or add a focused custom module. 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 ships standalone or joins a connected platform. We build the integrations and data layer that keep them in agreement without nightly batch reconciliation.
It depends on the path. A single module takes 5 to 18 weeks depending on complexity: MRP is longer, inventory or procurement are shorter. A multi-module platform runs 6 to 18 months, delivered module by module so you get usable value before it's done. A legacy migration runs 3 to 9 months including parallel-run.
Every engagement starts with a 2-week discovery sprint that produces process maps, a scoped requirements document, and a fixed-price proposal. The timeline is grounded in your real process before any contract is signed.
In four phases, never as a weekend switch. First, a two-week audit and data-profiling pass to find orphans, nulls, and undocumented customizations. Second, version-controlled transformation rules that map every legacy field, transform it, or retire it with a reason. Third, a parallel run for at least one full accounting period with daily reconciliation reports. We drive every old-versus-new delta to zero.
Fourth, a planned cutover with a written rollback path and the legacy system read-only for a defined 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, data-flow diagram, and 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. Who-changed-what is always answerable. OWASP ASVS Level 2 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. We scope it 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 and explicit change-request process. Migrations are scoped against the data-profiling audit: data quality drives most effort. Retainers for ongoing work and support are monthly with a minimum and cap.
We don't publish tiered packages because a single procurement module and a full multi-entity platform sit at wildly different scopes. Book the call. A written scope and quote land in 48 hours.
30-minute call to map your 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 .
Pinch, scroll or double-tap to zoom · drag to pan
Share your name and email so we can follow up.
Please enter your name and a valid email.
