How to Build an ERP System from Scratch Without Losing Control

If you want to build an ERP system from scratch, do not begin bytrying to reproduce finance, CRM, inventory, purchasing, manufacturing,projects and reporting at once.

Begin with one bounded business problem and a small platformfoundation. Build an end-to-end process that real users can operate.Prove the data model, permissions, audit, integration and deploymentapproach. Add another module only after the first one worksreliably.

An ERP is not simply a collection of database forms. It is along-lived operational platform that coordinates people, transactions,rules and records across an organisation. Building one can provide anexcellent fit, but it also creates permanent responsibility forsecurity, accounting integrity, upgrades, support and change.

This guide gives developers and technical founders a practicalsequence for building ERP software while avoiding the most commonarchitectural traps.

Should you build your ownERP system?

The first design decision is whether custom ERP development isjustified.

Building may make sense when:

• A distinctive operational process creates real business value.
• Standard products require persistent, expensive workarounds.
• Integration with specialist equipment or systems is central.
• The organisation needs control over source code, deployment orfuture changes.
• The aim is to create a commercial ERP product or reusable industryplatform.
• A narrow operational application can grow gradually into a broadersystem.

Buying or configuring existing software is usually better when:

• Processes are common and the business can adopt a standardmodel.
• Accounting, payroll or regulatory localisation is the primaryneed.
• The organisation lacks a permanent product and engineeringteam.
• A suitable supported product already meets most requirements.
• The project is driven mainly by frustration with one implementationrather than a genuine product gap.

Custom ERP software is not finished at launch. Someone must ownpriorities, incidents, vulnerabilities, data, integrations, releases andeventual replacement for as long as the organisation depends on it.

Why building ERPfrom scratch is difficult

ERP combines several forms of complexity.

Business complexity

An apparently simple order can depend on customer status, addresses,products, units, prices, discounts, tax, credit, stock, purchasing,fulfilment, invoicing and accounting.

Exceptions are often more important than the normal path: partialdeliveries, returns, substitutions, cancelled lines, retrospectivecorrections and disputed invoices.

Data complexity

ERP data must preserve history while remaining useful for currentoperations. A customer may change address, a product may change taxcategory and a price list may expire. Historical transactions must stillshow what applied at the time.

Integration complexity

The system may connect with banks, ecommerce, CRM, payroll,logistics, manufacturing equipment, local legacy software and reportingplatforms. Each connection has its own availability, identity anddata-quality behaviour.

Operational complexity

ERP software becomes essential to daily work. The team needsmonitoring, backups, recovery, support, audit and controlleddeployment—not only working features.

Change complexity

The system must evolve without losing data integrity or making everycustomer implementation a permanent fork.

That final problem is where platform design, metadata and adisciplined extension model become important.

A realistic ERP developmentroadmap

The steps overlap, but they should be completed in a deliberateorder.

StagePrimary result1. Define the purposeClear problem, target users and success measures2. Select the first processOne bounded, valuable operational slice3. Model data and rulesExplicit domain concepts and ownership4. Design the platform foundationShared identity, permissions, audit and configuration5. Choose the architectureModule boundaries and deployment approach6. Build the first moduleWorking end-to-end business process7. Integrate and migrateControlled connection to real systems and data8. Test and secureEvidence that the system behaves reliably9. Launch and operateSupported production service10. Expand carefullyReusable modules and stable extension contracts11. Build an ecosystemOptional marketplace after the platform matures

Step 1: Define what the ERPis for

“Build an ERP” is too broad to guide a project.

Write a product statement that identifies:

• Target organisations.
• Initial business problem.
• Intended users.
• Existing systems it will replace or complement.
• Distinctive value.
• Deployment and ownership expectations.
• Success measures.

For example:

Create an order and production-planning system for smallmade-to-order manufacturers that currently coordinate quotations,materials and workshop capacity in spreadsheets.

This is specific enough to investigate. A plan to create “a modernERP for every business” is not.

Interview users andobserve real work

Speak with sales, operations, finance, management and the people whocorrect mistakes. Follow real transactions from start to finish.

Document:

• Normal process.
• Important exceptions.
• Information created and consumed.
• Decisions and approvals.
• Duplicate entry and manual reconciliation.
• Unofficial spreadsheets and workarounds.
• Consequences when something goes wrong.

Requirements should determine the application. Do not begin with ademonstration of your chosen framework or a predesigned dashboard.

Step 2: Choose thefirst bounded process

The first release should be useful but narrow. Good candidates haveclear users, data and outcomes.

Examples include:

• Enquiry to quotation.
• Purchase request to approved purchase order.
• Stock receipt and put-away.
• Service request to completed job.
• Timesheet to project-cost update.
• Sales order to warehouse allocation.

Avoid starting with the general ledger unless the product'sdistinctive purpose is accounting and the team has strong accountingexpertise. Financial posting, tax, periods, corrections and reportingcarry high consequences.

Build an end-to-end slice

Do not deliver all database tables first and interfaces later. Builda thin but operational path:

1. Create the business record.
2. Validate it.
3. Apply permissions and rules.
4. Move it through a real state change.
5. Record history.
6. Produce an operational output.
7. Make failure visible.

This tests the architecture earlier than an impressive collection ofdisconnected screens.

Step 3: Model the ERP domain

Begin with business language, not generic technical abstractions.

For each concept, define:

• Meaning.
• Identifier.
• Important attributes.
• Relationships.
• Lifecycle and states.
• Invariants and rules.
• Owner.
• Historical behaviour.
• Access restrictions.

Distinguishentities from documents and events

• Entity: something with continuing identity, such asa customer or product.
• Business document: a record of an intention ortransaction, such as an order or invoice.
• Event: a fact that occurred, such asOrderConfirmed or GoodsReceived.
• Reference data: controlled values such as units,currencies or tax codes.
• Snapshot: values copied to preserve historicalcontext.

Do not design the schema as if every current attribute should alwaysbe joined from a master table. A confirmed order may need to preserveits address, description, price, currency and tax treatment even aftermaster data changes.

Use stable identifiers

Separate internal identity from user-facing numbers. An order canhave an immutable technical identifier and a formatted business numberthat follows company-specific rules.

Avoid using names, email addresses or externally controlled codes asprimary identities.

Make units and moneyexplicit

Store currency with monetary values. Define rounding, precision andcalculation order. Model quantities with units and conversionsdeliberately.

These details affect totals, stock and accounting. They should not bedelegated to whatever numeric type is easiest in the firstprototype.

Step 4: Designthe minimum platform foundation

Several concerns recur in every ERP module. Build them once, but keepthe first version restrained.

Identity and access

Define users, roles and organisational context. Permissions maydepend on company, location, department, record ownership, amount andprocess state.

Enforce permissions in application services and APIs—not only byhiding interface controls.

Organisation and tenancy

Decide whether the ERP serves one organisation, multiple legalentities or multiple customer tenants. This choice affects nearly everyquery and permission.

Do not add multi-tenancy speculatively. If it is required, design andtest isolation from the beginning.

Audit and history

Record meaningful actions: creation, state changes, approvals,adjustments, imports and permission changes. Store who, when, what andwhy.

Configuration

Separate values that vary between organisations or deployments fromsource code. Validate configuration and keep secrets out of applicationdefinitions.

The Twelve-Factor Appmethodology treats deployment-specific values such as service locationsand credentials as configuration rather than code.

Workflow and business rules

Keep decisions, validations and task coordination visible. Do nothide every rule in generic “before save” hooks.

Import and export

Data entry cannot be the only route into the system. Providevalidated imports, error reporting and complete export from an earlystage.

Background work

Long-running imports, notifications, document generation andintegrations need queues or scheduled jobs with retry, monitoring andidempotency.

Step 5: Choose an ERParchitecture

Start with clear modules inside the simplest reliable deployment.

Modular monolith as astarting point

A modular monolith keeps modules within one deployable applicationwhile enforcing boundaries in code and data access.

It provides:

• Simpler deployment and diagnosis.
• Straightforward transactions.
• Lower operational overhead.
• A route to extract selected services later.

The architecture still needs module ownership. Sales should notupdate inventory or finance tables directly.

When to use separateservices

Extract a service when there is a demonstrated need for:

• Independent release cadence.
• Separate scaling.
• Strong security or failure isolation.
• A distinct technology requirement.
• Clear team ownership.
• Reuse beyond the ERP application.

Microservices create network, versioning, observability anddistributed-consistency work. They are not a shortcut to modularity.

Define module contracts

Each module should publish supported operations and events. Othermodules must not depend on its internal tables or private code.

For example, inventory may expose ReserveStock andpublish StockReserved. The sales module should not set aquantity column in an inventory table.

Step 6: Build the first ERPmodule

Implement the selected process using a vertical slice.

Application services

Create explicit use cases such as:

• Create quotation.
• Add quotation line.
• Submit for approval.
• Accept quotation.
• Convert to order.

Each operation should validate permission, current state and businessrules.

State transitions

Avoid allowing users or APIs to write arbitrary status values. Definevalid transitions and the conditions for each one.

For example:

Draft → Submitted → Approved → Accepted → Converted

Include rejection, cancellation and revision paths.

Task-oriented interface

Design screens around work rather than tables. A quotation workspacemay combine customer context, line items, margin warnings, approvalstate, communication and next action.

Generic forms are useful, but the important task may require apurpose-built view.

Automated tests

Create tests for:

• Business-rule boundaries.
• Permission combinations.
• State transitions.
• Totals and rounding.
• Duplicate requests.
• Integration failure.
• Audit history.
• Data migration.

Tie test examples to documented business rules so that businessowners can confirm intent.

Step 7: Design APIs andevents

ERP modules and external systems need stable contracts.

Prefer businessoperations to table APIs

POST /orders/{id}/confirm communicates a businessaction. A generic update of the order's status field bypasses importantvalidation and audit.

The OpenAPI Specificationprovides a formal standard for describing HTTP APIs. Use a documentedcontract for endpoints, schemas, errors and authentication, but governthe business meaning separately.

Publish events aftercommitted facts

An OrderConfirmed event should be published only whenconfirmation is durable. Consumers must handle duplicate delivery andtemporary ordering differences.

Use stable event identifiers and record processing so that retry doesnot create duplicate stock, invoices or notifications.

Version contracts

Prefer additive evolution where possible. Track deployed versions andconsumers. Provide deprecation periods and migration guidance.

Step 8: Integrateexisting and legacy systems

List every system that supplies or consumes important data.

For each integration, define:

• Owner and support contact.
• Interface: API, message, file, database or local agent.
• Data direction and frequency.
• Source of truth.
• Mapping and identifiers.
• Authentication and network boundaries.
• Expected volume.
• Error, retry and reconciliation.
• Monitoring and operational responsibility.

Systems without APIs

Legacy software may support scheduled CSV or XML exchange, reportingviews, controlled database reads or desktop automation.

Prefer supported file or data interfaces. Avoid direct databasewrites unless explicitly supported, because they can bypass validationand corrupt internal assumptions.

Keep each legacy adapter outside the core domain model. Translateexternal terms and identifiers at the boundary.

Step 9: Plan data migrationearly

Migration is not a final import script. Existing data shapes designdecisions.

Profile real source data for:

• Missing required values.
• Duplicate customers and suppliers.
• Reused or ambiguous identifiers.
• Invalid dates and status combinations.
• Obsolete records.
• Free text representing structured information.
• Historical transactions that do not fit the new model.

Agree what will be cleansed, transformed, merged, archived orexcluded.

Reconcile every migration

Use counts, totals and business control values. For stock, comparequantities by item and location. For receivables, compare customerbalances and overall totals. For orders, compare open values and statusdistributions.

Run migration repeatedly in test environments. A production cutovershould use a rehearsed process, not a new script.

Step 10: Build securityinto the ERP

ERP security includes more than login.

Address:

• Account lifecycle and recovery.
• Company, location and record access.
• Function and field permissions.
• Separation of duties.
• Approval limits.
• Sensitive exports.
• Service accounts and integration credentials.
• Audit, alerting and incident investigation.
• Dependency and extension security.
• Backup and recovery.

The NIST SecureSoftware Development Framework provides high-levelsecure-development practices that can be integrated into differentlifecycles. The OWASPApplication Security Verification Standard provides a structuredbasis for defining and testing web-application security controls.

Use risk and data sensitivity to set the required assurance. Do notclaim enterprise security because a framework's default authenticationworks.

Step 11: Test theERP as an operational system

ERP testing must cover complete business scenarios.

Include:

• Normal end-to-end processes.
• Exceptions and reversals.
• Permissions and separation of duties.
• Concurrent changes.
• Integration delays and failure.
• Duplicate messages and retries.
• Imports, exports and reconciliation.
• Historical date and period behaviour.
• Performance with representative data volumes.
• Backup restoration.
• Accessibility and usability.
• Upgrade and rollback.

Test irreversible-lookingactions

Users will post, ship, invoice and adjust records incorrectly. Decidewhether the system reverses, amends or cancels each transaction whilepreserving history.

Avoid silent deletion of posted business records.

Step 12: Launch a supportedproduct

Before production, establish:

• Product owner and decision authority.
• User support and escalation.
• Monitoring and alert ownership.
• Backup and restoration procedures.
• Incident response.
• Release approval and rollback.
• Training and task guidance.
• Data retention and export.
• Infrastructure and dependency updates.

Start with a pilot team or controlled process where possible. Observereal work and fix operational gaps before adding more scope.

Measure business outcomes as well as uptime: transaction completion,rework, delays, reconciliation differences and user adoption.

Step13: Add modules without creating a monolith of dependencies

When the first module is stable, choose the next capability based onbusiness value and architectural learning.

Before adding it, define:

• Domain boundary.
• Data ownership.
• Required shared services.
• Synchronous operations.
• Published and consumed events.
• Reporting requirements.
• Permissions.
• Migration and integration.

Use explicit contracts. Do not let the convenience of one databaseturn every module into a shared collection of tables.

Buildaccounting integration before full accounting

Many custom ERP projects can initially integrate with an establishedaccounting package rather than implement a general ledger, tax, paymentsand statutory reporting.

Send controlled business transactions or summaries and reconcilethem. Build full accounting only when it is central to the product andthe team has the required domain expertise.

Step 14: Designconfiguration and extensions

Every implementation will differ. Decide how changes arerepresented.

ChangeExampleMechanismSettingApproval amount or number formatValidated configurationMetadata customisationAdditional field, rule, state or viewVersioned application definitionCode extensionSpecialist calculation or protocolSupported plugin or external service

Avoid customer-specific changes to core code. They create forks thatbecome harder to secure and upgrade.

An extension contract should define identity, compatibility,dependencies, permissions, migrations, configuration, events, removaland diagnostics.

Step 15: Considermetadata-driven development

ERP repeats many structures:

• Entities and relationships.
• Fields and validation.
• Lists, forms and searches.
• Permissions.
• States and workflows.
• Imports and exports.
• APIs and events.
• Audit and history.

Representing these as metadata can allow shared platform services torender or generate consistent behaviour.

For example, one field definition might inform storage, validation,interface controls, API schema, import mapping, permissions and auditdisplay.

Metadata needs the same discipline as code:

• Documented schema.
• Type validation.
• Source control.
• Versioning and migration.
• Testing.
• Debugging tools.
• Extension points for cases the model cannot express.

Otherwise, the metadata becomes an undocumented programminglanguage.

Step 16:Use AI as an assistant, not the product owner

AI can help:

• Draft data models and requirements.
• Generate repetitive code and tests.
• Suggest mappings for imports.
• Summarise logs and documentation.
• Create prototype screens.
• Identify missing cases in rules.

It cannot take accountable ownership of:

• Business policy.
• Accounting treatment.
• Permission decisions.
• Data retention.
• Migration acceptance.
• Operational risk.

Generated output must be reviewed and tested. AI becomes more usefulwhen it works against a structured application model and explicit rulesrather than a series of unrelated prompts.

Should you build an ERPmarketplace?

A module marketplace can help developers distribute extensions andbusinesses assemble solutions. It is also a security, compatibility andgovernance system.

Do not build an ERP marketplace alongside the first module. Firstestablish:

• Stable platform APIs and extension contracts.
• Module manifests and dependency rules.
• Semantic or clearly defined compatibility versions.
• Installation, migration and removal behaviour.
• Permission declarations.
• Package signing and provenance.
• Security review and vulnerability response.
• Licence and commercial terms.
• Support and dispute responsibilities.
• Test environments and quality criteria.

A catalogue of downloads is not yet a safe marketplace. The ecosystemdepends on trust in both the platform and its extension lifecycle.

HowSevenlake aims to make ERP development more practical

Building an entire ERP independently requires years of work becauseevery project needs common foundations as well as specialised businesslogic.

Sevenlake is exploring an open-source, metadata-first platformintended to provide more of that shared foundation for ERP, CRM andcustom operational applications.

The planned direction includes:

• Metadata-driven application definitions.
• User interfaces generated or rendered from metadata.
• Reusable and composable modules and templates.
• AI-assisted creation and customisation from businessrequirements.
• Extensibility for developers.
• Data import and export.
• API-based interoperability.
• A goal of cloud or self-hosted deployment choice.
• A future marketplace for modules, templates and extensions.

The intended developer proposition is to work at a higher level:define entities, relationships, rules, permissions, workflows and viewswhile reusing platform services for common application behaviour.

That does not remove the hard parts of ERP development. Developersand business specialists still need to understand processes, model data,govern rules, secure operations, integrate systems and test realoutcomes.

Sevenlake is currently at the vision and architecture stage, movingtowards a proof of concept. The runtime, UI renderer, modules, SDK, APIreference and marketplace remain planned rather than available. Itcannot yet be used to build a production ERP system.

Frequently asked questions

How do you build anERP system from scratch?

Define a narrow target problem, select one bounded process, model itsdata and rules, build the minimum shared platform services, deliver anend-to-end module, integrate real data, test and operate it reliably,then expand through controlled module contracts.

How long does ittake to build an ERP system?

There is no responsible universal estimate. A narrow internal modulemay be delivered in months, while a broad, supported ERP product is amulti-year undertaking. Scope, domain complexity, accounting,localisation, integrations, migration and operational requirements drivethe timescale.

How much does itcost to build your own ERP?

Cost includes product management, analysis, design, development,testing, migration, infrastructure, security, support and ongoingchange. Compare lifecycle cost with configuring or extending existingsystems—not only initial programming cost.

Which ERP module shouldbe built first?

Choose a process with clear users, value and boundaries that teststhe architecture without carrying the highest possible regulatory orfinancial risk. The right first module depends on the product'sdistinctive purpose.

Should an ERP usemicroservices?

Only where independent deployment, scaling, isolation or teamownership justifies the operational cost. A modular monolith is often astrong starting point.

Which database is best for anERP?

The answer depends on transaction requirements, reporting, scale,operations and team skills. Relational databases are a common fit forstructured ERP transactions, but the architecture should not makeunsupported claims that one database suits every module anddeployment.

Can AI build an ERP system?

AI can accelerate analysis, code, tests, documentation andconfiguration. It does not replace domain expertise, accountabledecisions, security engineering, migration or production support.

Is it worth building anERP marketplace?

Only after the platform has stable extension contracts, compatibilitymanagement, package security, governance and enough users and developersto support an ecosystem.

Build one reliablebusiness capability first

The fastest route to a failed ERP is trying to build everything.

Begin with one process that matters. Make its data, rules andownership explicit. Build a small reusable foundation. Deliver acomplete operational slice and run it with real users. Let evidencedetermine the next module.

Sevenlake is being developed around the idea that ERP developersshould not need to recreate the same application foundations repeatedly.If you are interested in helping shape that open, metadata-firstdirection, explore Sevenlakefor developers, view thepublic roadmap or followdevelopment on GitHub.