Custom ERP Development in Berlin: What It Costs, How Long It Takes, and What to Demand From a Partner
A Berlin manufacturer with 180 employees runs production planning in three Excel workbooks, invoices from a 2009 installation of a discontinued German ERP, and counts warehouse stock on paper. Twice a year somebody proposes SAP Business One or Microsoft Dynamics. Twice a year the licence quote arrives, the finance director goes quiet, and the spreadsheets survive another season.
That standoff is what drives most enquiries about custom ERP development in Berlin. It is rarely a wish for bespoke software as such. It is the recognition that a standard product would need so much configuration, so many workarounds, and so much per-seat licensing that it stops being the cheap option.
This guide is for the person who has to defend the decision internally: what a custom ERP costs, how long it takes, which parts are worth building rather than buying, where these projects fail, and what to put in the contract before anyone writes code.
What Custom ERP Development Actually Buys You
Three things, and usually only one is decisive.
Workflow fit. Standard ERP encodes a reference process. You either adopt it or pay consultants to bend the product toward yours. For commodity workflows that is fine. For the two or three processes that are the reason customers choose you, forcing them into a generic model is a direct hit to the thing you are good at.
No licence lock-in. Per-seat and per-module licensing scales with headcount, not with value. Double your warehouse staff and you double a cost line that has nothing to do with the software getting better. Custom shifts spend from a permanent licence to a one-off build plus a maintenance budget you control.
Data control. You own the schema, the database, and the export path. That matters for GDPR posture, EU hosting, and the day you leave.
The honest counterweight: if your processes are genuinely standard, buy standard. A distributor doing straightforward buy-and-sell with no unusual pricing logic should run a configured off-the-shelf product and spend the saved budget elsewhere. Custom ERP earns its cost when process differentiation is real, when licence costs already hurt, or when integration is the hard part either way.
The Four Modules German Mid-Size Companies Build Custom Most Often
Nobody should build all of ERP. The realistic pattern is a custom core around the differentiating processes, integrated with bought tools for everything else. Four modules come up repeatedly.
Inventory and warehouse management. Multi-location stock, batch and serial tracking, bin-level picking logic, and reservation rules. This is where standard products most often fall short, because picking strategy and stock reservation are where operational cleverness lives.
Order management. Quote to order to fulfilment, with customer-specific pricing, framework agreements, partial deliveries, and returns. Custom pricing logic is the most common reason a standard ERP configuration turns into a six-figure consulting engagement.
Invoicing and finance integration. The module with the least room for creativity and the most room for getting it wrong. In Germany that means a clean DATEV export path for your Steuerberater, structured e-invoicing in XRechnung or ZUGFeRD format under the EN 16931 standard, and GoBD-compliant record keeping: immutable postings, a complete audit trail, and a written Verfahrensdokumentation. Retention periods and e-invoicing obligation dates have moved more than once, so confirm current requirements with your Steuerberater rather than with a blog post.
HR and resource planning. Shift planning, capacity allocation, skills matrices, and time tracking that feeds payroll. Often the best value per euro, because the alternative is a manager maintaining a scheduling spreadsheet nobody else can read.
A sensible first release covers one or two of these and goes live before the others are started. Anything broader is a rewrite disguised as a project.
What Custom ERP Development in Berlin Costs
The ranges below are what we quote mid-size German clients at 2026 senior EU engineering rates. They come from our own projects, not survey data, and the spread within each band is wide for good reason.
| Scope | Typical range (EUR) | What it includes |
|---|---|---|
| Discovery and process mapping | 12,000 to 25,000 | Process interviews, data audit, integration inventory, architecture proposal, costed backlog |
| One core module, production ready | 40,000 to 90,000 | Build, tests, deployment pipeline, one integration, training material |
| First release, two to three integrated modules | 120,000 to 280,000 | The usual shape of a first go-live |
| Full four-module suite with legacy data migration | 300,000 to 600,000 and up | Multi-year programme, phased delivery |
| Annual run cost after go-live | 15 to 25 percent of build cost | Hosting, maintenance, support, small enhancements |
Four variables move a project within those bands.
Integration count. Each external system your ERP must talk to (webshop, DATEV, carriers, machine controllers, existing CRM) adds cost, and legacy systems with no documented API add considerably more. Integrations are where estimates are least reliable, which is why they belong in a time-and-materials envelope.
Data migration quality. Twenty years of inconsistent article numbers and duplicate customer records can cost more to clean than the module consuming them costs to build. Audit the data during discovery, not after the build starts.
Regulatory surface. Finance and personnel data raise the compliance bar, and with it the test and documentation effort.
Decision latency. The cheapest ERP projects have one empowered decision maker who answers within a day. The expensive ones route every question through a monthly steering committee.
Our post on custom software development cost, timeline, and ROI works through the same trade-offs outside the ERP context.
Timelines: What Each Phase Actually Takes
| Phase | Duration | Output |
|---|---|---|
| Discovery and process mapping | 3 to 6 weeks | Process models, data audit, architecture, costed backlog |
| Core build, first module | 3 to 5 months | Working module in staging, automated tests, CI pipeline |
| Integrations | 6 to 12 weeks, largely parallel | Live connections to DATEV, webshop, carriers, legacy systems |
| Data migration and dry runs | 4 to 8 weeks | Repeatable migration script, at least two full rehearsals |
| Rollout and parallel running | 4 to 12 weeks | Old and new systems in parallel, reconciliation reports |
| Stabilisation | 4 to 8 weeks | Defect burn-down, performance tuning, handover documentation |
A first usable release typically lands five to eight months after kickoff. Replacing an entrenched legacy ERP end to end runs twelve to eighteen months and should be delivered in slices. The strangler fig pattern is the right mental model: route one process at a time to the new system, keep the old one authoritative until the new one has proven itself, and never plan a single weekend cutover for a system that touches money.
Where ERP Projects Fail
Four failure modes account for most of the wreckage, and all are visible early.
Scope creep by adjacency. Somebody notices that while the team is rebuilding order management, it would be sensible to also fix the customer portal, the CRM sync, and reporting. Each addition is individually reasonable. Together they push go-live past the point where the sponsor's patience runs out. The defence is contractual: fixed module boundaries and a separately budgeted change pot that requires an explicit decision to spend.
Change management treated as training. The plant manager who kept a shadow spreadsheet through three previous rollouts will keep one through this one too, unless somebody addresses why. ERP projects fail on adoption far more often than on code. Name a business-side process owner per module, involve them from discovery, and train before go-live rather than during it.
Thin test coverage on the money paths. An ERP bug is a financial bug: a wrong tax rate, a double posting, a reservation that releases stock it should have held. Insist on high automated coverage for pricing, tax, stock movements, and postings, plus regression tests against a golden dataset of historical transactions with known correct outputs.
Underestimated data migration. The schedule risk discovered too late most often. Treat migration as a workstream with its own budget and rehearse it end to end at least twice against production-scale data before committing to a go-live date.
What to Demand From a Development Partner
Weak contracts are how good technical teams still produce bad outcomes. These terms are reasonable to insist on, and a partner who resists them is telling you something useful.
Discovery as a separate, cancellable contract. Pay for discovery on its own. At the end you should hold process models, a data audit, an architecture proposal, and a costed backlog you own outright and could hand to another supplier. If discovery shows that off-the-shelf is the better answer, a partner worth hiring will say so.
Source code and repository access from day one. Your organisation owns the repository. Commits land there continuously, not in a delivery zip at the end. This costs the supplier nothing if their work is sound.
Fixed price per module, time and materials for integrations. Fixed price works where scope is knowable. Integrations with undocumented legacy systems are not knowable, and a supplier who fixed-prices them has either padded heavily or will fight you over every change request.
Payment milestones tied to acceptance criteria. Each milestone needs written, testable criteria agreed before work starts. "Module complete" is not an acceptance criterion. "Picking list generates correctly for the twelve documented warehouse scenarios, verified against the golden dataset" is.
A defined support SLA with severity levels. Response time and resolution target are different commitments, and vendors sometimes quote the first while implying the second.
| Severity | Example | Response | Resolution target |
|---|---|---|---|
| S1 critical | Cannot invoice, cannot ship, data loss | 1 business hour | 4 business hours or documented workaround |
| S2 major | Core workflow degraded, no workaround | 4 business hours | 2 business days |
| S3 minor | Cosmetic or low-impact defect | 1 business day | Next scheduled release |
Agree whether the clock runs on business hours or around the clock, and price the difference before your first peak season rather than during it.
Exit and handover terms. A documented runbook, infrastructure as code, an onboarding guide for a new team, and a defined transition period. You should be able to leave. That freedom is what keeps the relationship healthy while you stay.
Our post on scope, SLAs, and proof in custom software services goes deeper on these clauses, and what German buyers expect from a software vendor covers the documentation expectations specific to the DACH market.
Symfony, Laravel, or Java Spring for the Backend
ERP is transactional, long-lived, and heavy on business rules. That narrows the field.
| Criterion | Symfony (PHP) | Laravel (PHP) | Spring Boot (Java) |
|---|---|---|---|
| Fit for complex domain logic | Strong: Doctrine ORM, DDD-friendly, explicit service layer | Moderate: Eloquent's active record pattern strains with rich domain models | Strong: mature enterprise patterns, strong typing |
| Long-term maintainability | High: strict LTS cadence, conservative deprecations | Moderate: faster-moving major versions | High: very stable, long support windows |
| Developer availability in Berlin | Good | Very good | Good, at a higher rate |
| Total cost of ownership | Lower | Lower | Higher: more infrastructure and more expensive engineers |
| Ecosystem for ERP concerns | Good: API Platform, Messenger, Workflow component | Adequate | Excellent for very large enterprises |
For a mid-size EU business, our recommendation is Symfony. Not because PHP is fashionable, but because Doctrine handles complex relational domain models well, Symfony's Workflow and Messenger components map cleanly onto ERP state machines and asynchronous posting queues, the LTS cadence is predictable enough to plan five years of maintenance around, and the Berlin hiring market is deep enough that you are not locked to one supplier.
Spring Boot is right at genuinely large scale or where a Java platform team already exists. Laravel suits simpler operational tools, but its active record pattern works against you once the domain model gets rich, which in ERP happens early. Our Berlin tech scene stack review covers what local teams are running.
Frequently Asked Questions
How much does custom ERP development in Berlin cost? Expect 12,000 to 25,000 EUR for discovery, 40,000 to 90,000 EUR per production-ready module, and 120,000 to 280,000 EUR for a first release covering two or three integrated modules. Budget a further 15 to 25 percent of build cost annually for hosting, support, and enhancements.
How long does a custom ERP project take? A first usable release usually lands five to eight months after kickoff. A full legacy replacement takes twelve to eighteen months and should be delivered in phases, not as a single cutover.
Is custom ERP cheaper than SAP or Microsoft Dynamics? Not at the point of purchase. It becomes cheaper over five years when per-seat licensing is significant, when a standard product needs heavy configuration, or when integration dominates the cost either way. Compare five-year total cost of ownership, not the initial quote.
Do we have to build every module ourselves? No. Build the modules carrying your differentiating processes, integrate bought or existing tools for the rest, and keep the boundaries explicit.
What does GoBD compliance mean for a custom ERP? Postings that cannot be silently altered, a traceable audit trail, controlled access, records kept for the statutory retention period, and a written Verfahrensdokumentation. Have your Steuerberater review the design before the finance module ships.
Where to Start
The highest-value next step is not a vendor demo. It is a short, paid discovery engagement producing process models, a data quality audit, an integration inventory, and a costed backlog you own regardless of who builds the system. That turns an ERP conversation from a leap of faith into a decision you can defend to a board.
Wolf-Tech builds and modernises operational software for mid-size European companies. Our custom software development, legacy code optimization, and tech stack strategy engagements cover this ground, including the unglamorous parts: data migration, DATEV and e-invoicing integration, and the test coverage that keeps a finance module trustworthy.
If you are weighing custom ERP against a standard product and want an independent read on which your situation calls for, write to hello@wolf-tech.io or visit wolf-tech.io. We will tell you if buying is the better answer.