Configurable manufacturing software vs custom development
Compare configuration, integration and custom development using a real process-change test, with checks for permissions, existing jobs and future upgrades.
Configurable manufacturing software lets authorised people change supported fields, forms and workflow settings without changing the application’s source code. Custom development adds or changes software behaviour through engineering work. Neither label tells you whether a product fits your plant: the useful test is how it handles your next process change.
Bring a concrete example to the evaluation. A customer now requires an extra inspection value, a second reviewer and a different report field. Ask the supplier to make that change, explain its effect on existing jobs and show how it will be maintained.
Configuration, integration and custom development
These are different ways to meet a requirement. A single implementation may use all three.
| Approach | Suitable example | Ownership question |
|---|---|---|
| Configuration | Add a supported field, change a form or select an existing workflow option | Who can change it and how is it reviewed? |
| Integration | Exchange a defined order or invoice record with another system | Who handles mapping changes, failures and duplicate messages? |
| Custom development | Implement behaviour that the product does not currently provide | Who tests, maintains and supports the code? |
Configuration has limits. A field labelled “approved” does not create a real approval process unless the system checks authority and enforces the relevant transitions. A formula field does not establish support for every calculation your process needs.
Custom development is not automatically a private fork. It may be a supported extension or a change that becomes part of the maintained product. Ask which arrangement is proposed and what happens when the platform changes.
Start with a change you expect to make
In a hypothetical plant, a customer adds a requirement to record a coating measurement before release. The team needs a numeric value with a unit, an approved acceptance rule, an exception path and a place for the result in the report.
Demonstrate the complete change. Adding a box to the screen is only the beginning. Submit an empty value, an out-of-range value and a valid value. Check which role can change the rule and whether that role can also release the work. Open an older job to see how its record behaves.
This test is more revealing than asking whether the platform is “no-code”. It shows how much of the requirement is supported, which decisions remain yours and where engineering is still needed.
What Bulk exposes through settings
Bulk’s configurable platform includes settings for custom fields. Its custom-field settings support defined types and scopes, with separate permissions for creating, updating and deleting field definitions. The interface distinguishes fields shared within a site from fields limited to selected customers.
That is a specific capability you can evaluate. It does not mean every requested business rule can be implemented by an administrator, or that changing a field is harmless to existing records. Demonstrate the intended workflow, reports and permissions with the proposed field definition.
Bulk is an operating system for the plant, installed one app at a time. When your scope includes the commercial loop, examine the same change through order, production and invoicing rather than treating the floor form as an isolated screen.
Check the effect on existing work
A new required field raises an immediate question: what happens to jobs that were created before it existed? They may need a default, a deliberate backfill or a rule that applies only to new work. The correct choice depends on the record and process.
Changing a field type can be more consequential than changing its label. A value stored as text may not convert cleanly to a number. Removing an option may affect historical reports. Changing a route may require a decision about work already in progress.
Record the expected behaviour before applying the change. Keep representative old and new records in the acceptance test. Reversing a setting does not automatically reverse production decisions or repair data written while it was active.
Ask what an upgrade will require
Configuration can reduce the need to maintain separate application code, but configured workflows still need verification after relevant product changes. Ask for the supported upgrade path and responsibility for testing your critical routes.
For an integration, establish the record owner, direction of synchronisation and recovery behaviour. A successful first message is not a complete test. Include duplicate delivery, a rejected value and a temporary outage. Check current integration availability for the specific system; an API or logo alone does not prove a finished connector.
For custom code, agree the maintainer, tests, dependencies and support boundary. Compare those obligations with the cost of adapting the process or choosing another supported approach.
A practical buying decision
Score the demonstrated change against four questions: did it cover the whole requirement, did it preserve existing work, could the intended owner operate it, and is its maintenance responsibility clear?
Prefer a supported configuration where it meets the need. Use integration where records must cross systems. Choose engineering where the missing behaviour justifies its ongoing cost. The answer can differ between requirements in the same plant.
Bring two likely changes and one difficult exception to Bulk’s configuration discussion. If you operate several plants, use the multi-site rollout guide to decide which settings should be shared and which differences need local ownership.
