The Custom Factory Software Development Process: 7 Stages from Discovery to Go-Live
Custom factory software (ERP, CRM, MES) development: seven stages from discovery to go-live, production risks, cost expectations and picking a software partner.
At shift changeover, the production manager of a carpet factory is rushing about with a schedule filled in with coloured pens; the dispatch supervisor is trying to reconcile three separate Excel files; and the accounts team is keying the same order into the GİB (Turkish Revenue Administration) portal for a second time by hand. Production does not stop, but small losses accumulate every day: a length entered incorrectly, a batch that slips through, a proforma that goes out late. What this factory needs is not to "buy software" but to connect the reality on the shop floor to a digital backbone. This is exactly where the custom factory software development process begins — and it is not a matter of tinkering at the edges, but of seven disciplined stages from discovery to go-live.
In this guide we explain how a custom ERP, CRM or production tracking (MES) system is delivered end to end for a manufacturing plant, the factory-specific risks at each stage, how to set realistic cost and timeline expectations, and the criteria for choosing the right software partner.
Why a Process Rather Than "Install a Package and Be Done"?
Installing an off-the-shelf ERP package is often a few weeks of implementation work. But if your factory has business rules of its own — production by length and design in carpets, project-specific manufacturing in machinery, batch and shelf-life logic in food — then instead of forcing the package, the process has to be built around those rules. Custom software puts these processes, the ones that do not come out of the box, at the centre.
Pan Innovation House's approach is not a chain of coincidences but a systematic flow. The Pan Growth System philosophy runs simply: first diagnosis, then architecture, then build, then measurement and scaling. In factory software we turn that philosophy into seven concrete stages. Four-eyes approval is applied before every delivery, which means no module reaches the shop floor having passed under a single pair of eyes. Internally we call this the Pan Standard.
Stage 1 — Discovery and Process Analysis (On-Site Observation)
Software is understood on the shop floor, not in the meeting room. At this stage the team comes to the factory, follows the chain from raw material intake through to dispatch in person, and talks to operators, the warehouse supervisor and the sales team. The aim is not to capture "what should happen" but what actually happens.
Outputs: the current process flow diagram, a bottleneck map, and a list of the factory's own business rules.
Factory-specific risk: Production cannot stop. Observation has to be done without burdening the shift or slowing the line. The process as described and the process as practised are also often different; the truth behind "we always do it this way" is only visible on the floor.
Stage 2 — Requirements and Process Mapping
The raw information gathered on site turns into structured requirements here. Which modules there will be, who touches which screen, which report goes to whom — all of it becomes clear. As processes are mapped, the current flow and the target flow are placed side by side; the gap between them defines the project's real scope.
Factory-specific risk: Shift work. What the day team needs may differ from what the night team needs. The multi-currency, multi-language needs of a sales unit working with export customers must be put on the table at this stage; a "small" currency rule added later can affect the architecture from the ground up.
Stage 3 — Architecture and Technology Selection
The most critical decision is taken here: fully custom or hybrid? In most factories the most sustainable answer is hybrid — an off-the-shelf ERP stays as the core, while the factory-specific processes are completed with custom software and integration.
| Approach | When it fits | Advantages | Points to watch |
|---|---|---|---|
| Off-the-shelf package (Logo/Netsis, SAP B1, Dynamics, Odoo/ERPNext) | When processes are close to the standard | Fast implementation, regulatory updates come from the vendor | Strain on processes outside the package, limits to customisation |
| Fully custom software | When the process is highly specific to the factory | Exact fit, full flexibility, you hold the source code | Longer development, disciplined maintenance required |
| Hybrid (package core + custom modules) | When the core is standard but the edge processes are distinctive | Regulatory assurance plus freedom in the distinctive processes | Integration points must be designed well |
The architecture plan also settles the integration points: GİB e-transformation (e-invoice, e-archive invoice, e-waybill, e-ledger), machine and MES connections, banking, shipping and any e-commerce channels. The API architecture is set up so that these points speak to one another around a single data model.
Factory-specific risk: Older machines may not give up data. It may not be possible to pull data automatically from machines with no PLC or sensor infrastructure; in that case realistic bridges such as barcode terminals or operator entry are built into the architecture from the start.
Stage 4 — MVP and Prioritisation
Building everything at once inflates both risk and cost. Instead we separate the "must have" from the "later" and define the smallest core that will create value on the floor — the MVP. Typically the day-to-day processes that keep the plant breathing, such as opening and closing work orders and recording stock movements, come first; advanced costing or comprehensive analytics dashboards are left to later waves.
Factory-specific risk: Scope creep. The pressure of "while we are building software anyway, let us add this too" derails even the most disciplined project. Clear prioritisation is the project's shield against that pressure.
Stage 5 — Iterative Development
Modules are delivered in waves rather than all at once. Every module is trialled early on the floor; a real operator tries it with real data and gives feedback. This iterative rhythm means mistakes are caught before they grow. The model of delivering "everything together in six months" under a fixed-scope contract almost always collides with reality in a live environment such as a factory.
That is precisely why Pan Innovation House argues for the iterative model rather than fixed scope: the process becomes clear on the floor, not on paper. Four-eyes approval is in force before every delivery.
Factory-specific risk: Adoption by shop floor users. In a busy, shift-based environment, nobody uses a screen that is complicated. The interface has to be designed for fast use, with gloved hands, on a noisy line.
Stage 6 — Integration and Data Migration
This is where the software starts talking to other systems and legacy data is moved across. GİB e-transformation integration is a legal requirement here rather than a choice: for businesses above a certain turnover threshold, e-invoice, e-archive invoice, e-waybill and e-ledger are mandatory, and the thresholds are being lowered in stages. It is sensible to confirm the current threshold with your accountant. The overwhelming majority of Gaziantep factories with high production and export volumes fall within this scope.
Conceptually, the skeleton of a custom integration looks like this:
Sales / CRM → Order → ERP (work order + stock) → MES (shop floor)
↓
e-Transformation integrator (GİB)
↓
Banking · Shipping · E-commerce · Reporting
Factory-specific risk: Data migration is the riskiest step in most projects. Data accumulated over years in Excel and in legacy software is usually inconsistent; the same customer sits under three different spellings, the same product under two different codes. Cleaning and validation before the migration is the quietest but most critical task in the project.
Stage 7 — Testing, Go-Live, Training and Maintenance
The final stage hands the software over to real life. After thorough testing, go-live is usually phased — rather than moving the whole factory to the new system overnight, one line or one warehouse goes first. Operator, warehouse and sales teams are trained, with repeat sessions planned around the shift pattern. After go-live the work continues with maintenance and support: regulatory updates, improvements as the operation scales, and new requirements.
Factory-specific risk: Continuity. The transition has to happen without stopping production. That is why the old and the new system often run in parallel for a short period; as confidence builds, the old system is retired.
Summary of the Stages
| Stage | Main output | Expected duration (general) |
|---|---|---|
| 1. Discovery and process analysis | Process map, bottleneck list | Short, intensive on-site work |
| 2. Requirements and mapping | Structured requirements document | Short to medium |
| 3. Architecture and technology | Architecture plan, integration points | Medium |
| 4. MVP and prioritisation | Priority matrix, MVP definition | Short |
| 5. Iterative development | Working software, module by module | The longest phase of the project |
| 6. Integration and data migration | Connected systems, migrated data | Medium to long (risky) |
| 7. Testing, go-live, maintenance | Live system, trained team | Phased plus ongoing |
We do not quote duration figures, because the real timeline depends on scope, on the number of integrations and on data quality. A firm date given for a project whose scope has not been settled is usually a promise that does not hold.
How to Set Realistic Cost and Timeline Expectations
The most common disappointment in factory software is a fixed price and date given up front that then falls apart on site. The cause is not bad faith; it is the nature of the process. Because scope becomes clear on the floor, the fixed-scope model usually forces a compromise on either quality or budget.
The sound approach is this:
- Cost and timeline are discussed together with scope, not as an abstract figure.
- The MVP is put into service first, so the investment starts to show value early rather than only at the end.
- Replanning happens as the project progresses; each wave makes the next one more predictable.
- Maintenance and regulatory support are part of the plan from the outset, not a "cost that appears later".
In an industrial centre such as Gaziantep, with its dense manufacturing and export fabric, working with a partner who knows the region's business rhythm strengthens that predictability. We describe our way of working in Gaziantep on a separate page.
Criteria for Choosing the Right Software Partner
The wrong partner will slowly drive even the best architecture into a dead end. Weigh these criteria in your choice:
- Industrial experience: Is this a team that has understood the realities of production, shifts, stock and dispatch on site? Building marketing software and digitalising a production line are different disciplines.
- Maintainable code: Can the code that is written be read and extended by another developer tomorrow? "It works but nobody understands it" becomes a trap over time.
- Source code ownership: Do you own the source code of the custom software you commissioned? This directly determines your dependency risk on the partner.
- Maintenance and SLA: When regulations change or a fault appears, who responds and within what timeframe? Is there a written service level commitment?
- Key-person risk: Are you dependent on one individual or on an organisation? Team, process and documentation are what keep the project running when one person leaves.
Pan Innovation House's custom software development service combines web, mobile, API and AI automation capability with this industrial discipline; source code ownership and Pan Standard four-eyes approval are the foundations of the approach. The same integration logic applies when you want to connect your production line to external channels, for example to e-commerce solutions.
Conclusion: Software Is a Process, Not a Product
Custom factory software is not a box taken off a shelf; it is a seven-stage journey that starts on the shop floor and moves in a disciplined way towards go-live. Discovery shows you the reality, architecture settles the right decision, the MVP creates value early, iterative development catches mistakes while they are small, integration and data migration proceed patiently, and go-live is achieved without stopping production. You discuss scope rather than figures, and establish a predictable rhythm rather than a fixed promise. Walk this path with that discipline and the software becomes the factory's backbone rather than its burden.
To look at your factory's processes together on site and clarify the route that suits you best — off-the-shelf, hybrid or fully custom — get in touch with us. The first conversation will show you which stage you need to start from.
Related guides: