The Custom Factory Software Development Process: 7 Stages from Discovery to Go-Live

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.

Our approach is a systematic flow: first diagnosis, then architecture, then build, then measurement and scaling. In factory software we turn that flow into seven concrete stages. Deliveries go through a review step before release.

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 (on site in and around Gaziantep; elsewhere in Türkiye and abroad, discovery starts remotely and a visit is planned if needed), follows the chain from raw material intake through to dispatch, 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, widely used Turkish ERPs; 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, source code and data handed over to you as defined in the contract	Longer development, disciplined maintenance required
Hybrid (package core + custom modules)	When the core is standard but the edge processes are distinctive	Regulatory updates stay with the package, flexibility in the distinctive processes	Integration points must be designed well

In a hybrid set-up, the custom layer connects to your ERP through the routes its vendor supports (API, service layer or an approved import); it does not write directly into the ERP's database tables. The route depends on the version and licence and is agreed in writing during discovery.

The architecture plan also settles the integration points: e-document obligations set by GİB (the Turkish Revenue Administration): e-invoice, e-archive invoice, e-waybill and 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's 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 why we recommend the iterative model rather than fixed scope: the process becomes clear on the floor, not on paper. Every delivery goes through a review step before release.

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. For e-document obligations (e-invoice, e-archive invoice, e-waybill, e-ledger) and package updates, see our article on Türkiye's e-document package update; confirm scope and thresholds with your financial adviser. The e-document process runs through the API of the private integrator you have contracted (or, if you hold direct integration approval from GİB, through that route).

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:

1. Industrial experience: Is this a team that has understood the realities of production, shifts, stock and dispatch on site? Building marketing software and digitising a production line are different disciplines.
2. 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.
3. Source code and data: Does the contract set out in writing how the source code and your data will be handed over to you? This directly determines your dependency risk on the partner.
4. Maintenance and support: When regulations change or a fault appears, who responds and within what timeframe? Are the maintenance scope and response times written into the contract?
5. 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.

You can ask us these questions too. We can show this approach on a working example during discovery; we do not name clients without their consent.

Pan Innovation House's enterprise software branch, Pan Enterprise Solutions, combines web, mobile, API and AI automation capability with this industrial discipline in our custom software development service. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. You can also see our ERP software and production tracking (MES) pages. 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 and clarify the route that suits you best (off-the-shelf, hybrid or fully custom), get in touch with us. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.

Related guides:

• Custom ERP Software for Gaziantep Factories
• Custom CRM for Carpet and Machinery Factories
• Custom Software Development Service
• Digital Growth in Gaziantep