Home / FAQs / Software project start-up and program selection
QUESTION & ANSWER

Choose Low Code Open Source or Custom Development

Low code is suitable for processes that are clear, changeable and platform-capable to cover higher internal applications; open source systems are suitable for mature-area products, which can meet demand through configuration and secondary development; customize the development of projects that are suitable for differentiated processes, complex integration, performance or higher product control requirements. The selection is made with a comparison of the total cost and exit capacity for three to five years, rather than with the first price only. Enterprises can also use combination routes, allowing different technologies to assume the most appropriate business boundary.

Answer the question.

First, give conclusions that can be used for decision-making

The minimum code is to confirm authorization, export and platform lock-in; open source checks for licences, communities, upgrades and secondary boundaries; customizes to focus on engineering quality, personnel continuity and code take-over.

DECISION FACTORS

What conditions need to be identified before judgement is made?

The same question may have different answers under different business, data and project phases. It is suggested that the following conditions be checked and that the common findings on the web be incorporated into their own projects.

The extent to which core processes match standard productsFuture change frequency and in-house maintenance capacityDelegation of authority, cloud resources, upgrades and long-term costsSource code, data, interfaces and portability
ACTION STEPS

Suggested order of advance

01

First, we'll be clear about the target and the border.

Define business requirements, differences and non-functional requirements.

02

Validation Key Dependence

Validation of the coverage of the platform, open source and customization programmes.

03

Development of assessable outcomes

Cost estimates for construction, subscription, upgrade and maintenance for three to five years.

04

Make sure you decide the next step with the real results.

Select a group that is acceptable, scalable and has an exit path.

PRACTICAL EXAMPLE

How do you understand it in the actual business?

Example used to illustrate the method of judgement

The business approval process can be built quickly with low-coded, client services can be based on open source work list systems, and unique price engines are customized and developed and connected through API. The combination approach is often more secure than imposing a technology to cover all needs.

COMMON RISKS

The easiest pit to step on.

Low code as zero development and zero maintenance

Use open source system without regard to licence and upgrade costs

Custom development has no documentation, testing and take-over requirements

ACCEPTANCE

How should we end up receiving and confirming?

The technical selection report should include functional coverage, gaps, prototype results, authorization, performance, safety, integration, maintenance and exit options.

When preparing to communicate with suppliers or internal teams, it is recommended that current processes, representative samples, existing systems, planning time and budget levels be brought. First, the unknown items are clearly marked, and then the decision is made to use diagnostics, PoC, fixed-range projects or ongoing research and development, which is usually more reliable than a direct demand for a price and duration without borders.

Your project conditions are different from the examples above?

Operational objectives, existing systems, sample and planned time could be collated before consultants could make preliminary judgements in relation to actual boundaries.

Associate project consultants