Differences from full-scratch development

A similar term is "full scratch development." Generally, scratch development refers to developing something from scratch while making some use of existing frameworks and libraries, whereas full scratch development refers to avoiding the use of frameworks and templates as much as possible and implementing a wider range of things from scratch.

However, since this distinction varies depending on the organization and vendor, it's best to clarify in advance "how much of the work will be considered in-house development" when placing an order or getting a quote to prevent misunderstandings later on.

1. High degree of flexibility allows for the creation of original systems.

With scratch development, you can freely design the required functions, screens, and integration methods with other systems without being constrained by the specifications of existing products.

We can flexibly accommodate situations where the business content is unique or where features not available in existing packages are required.

2. Can be fully adapted to your company's workflow.

In package development, requests can only be incorporated within a certain set of predetermined specifications.

On the other hand, with custom development, you can create a user-friendly system tailored to your company's business processes and operational rules.

3. It leads to differentiation and competitiveness from other companies.

Because you can implement unique features and UI/UX, it becomes easier to create services and operational efficiencies that other companies don't offer, leading to the creation of a competitive advantage.

This high degree of flexibility is particularly valuable in areas that are fundamental to the business, such as core systems.

1. Development costs and time tend to be high.

Because the design and implementation are done from scratch, development costs and time tend to be higher compared to package development.

The process from requirements definition to going live tends to be lengthy, requiring careful planning while assessing the return on investment.

2. Risks of reliance on specific individuals and black Box specifications

Because it is a system with proprietary specifications, there is a tendency for knowledge to be concentrated in the hands of the vendor and engineers who were in charge of its development.

As a result, there is a risk that specifications will become a black Box due to personnel changes or resignations, so it is necessary to consider documentation and the design of a maintenance system as well.

3. Difficulty in defining requirements and securing IT personnel.

The success or failure of development from scratch largely depends on the accuracy of the requirements definition.

However, companies often lack personnel who possess both on-site operational knowledge and expertise in both IT and OT, and it's not uncommon for them to stumble at the requirements definition stage.

Due to these cost and organizational hurdles, many companies are unsure whether to continue relying on outsourcing or to move towards in-house production. For more information on the reasons why DX promotion in the manufacturing industry is not progressing as expected, please also see the following article.

• Why isn't DX progressing in the manufacturing industry? We'll explain the challenges and obstacles to DX and data utilization based on case studies.

Companies with unique business processes and special requirements

Companies with industry-specific business practices or unique production and logistics flows that are not found in other companies often cannot be adequately addressed by existing packages, and this is where custom development comes into play.

If you need functionality that cannot be supported by existing packages

In areas where customization is difficult due to the limitations of packaged products, such as integration with existing core systems or specific production and quality control requirements, there are many functions that can only be realized through scratch development.

Thoroughly define the requirements.

In development from scratch, the accuracy with which on-site operations are articulated during the requirements definition phase greatly influences the subsequent design and development quality. It is crucial for the on-site departments and the IT department to work closely together and start development with no discrepancies in understanding.

Choose a reliable development partner

Because development from scratch tends to be a long-term project, choosing a partner who can provide consistent support from requirements definition to design, implementation, operation, and maintenance is key to success.

Choose a company with a support system that understands IT and OT.

In manufacturing system development, an understanding of operational technology (OT), such as production equipment and control systems, is essential, as well as information systems (IT).

What is the low-code development platform "Mendix"?

Mendix is an enterprise-grade low-code development platform provided by Siemens AG, covering everything from requirements analysis to development and post-release operation within a single environment.

By utilizing a low-code development platform like Mendix, you can build systems with the flexibility to design applications tailored to your business needs, without the development effort required for development from scratch.

Instead of rebuilding the core system from scratch, a growing trend is to utilize existing core systems such as ERP and MES, positioning Mendix as a layer around them to flexibly absorb changes in on-site operations and unique requirements. This approach is valued because it avoids frequent changes to the core system, allowing for maintainability while adapting to on-site needs.

Combining the freedom of scratch development with the speed of package development.

This allows on-site staff without programming skills to participate in development, leading to reduced development costs for IT engineers, shorter development periods, and increased in-house development.

For companies that want uniqueness but don't have the time and cost to develop from scratch, this can be a viable option.

If you are considering improving inefficient business processes that rely on paper and Excel, or promoting DX through in-house development, please consider low-code development as an option alongside scratch development. Specific methods for business process improvement are also introduced in the following document.

See other Mendix use cases here.

*Registration required for viewing/downloading

Request PDF download

Mendix is just one option among many low-code development platforms. For those who would like to compare it with other manufacturing DX tools such as ERP, PLM, and MES, please also refer to the following.

• 12 Manufacturing DX Tools: How to Choose by Type (PLM, MES, ERP, OT) and Common Implementation Failures

If you're unsure whether custom development or package development is right for your company, please consult with Macnica, including exploring the option of low-code development.