Workcube custom development: a separate module, standard code untouched
Version 1.0 — Last updated:
How do you customise Workcube without breaking its standard code? Gramoni packages customer-specific code as a separate module, so Workcube's standard code is never modified. Development uses CFML (ColdBox, Lucee, Adobe ColdFusion), TypeScript (NestJS, React), PostgreSQL, MSSQL, MySQL, PWA and REST. The same team quotes the project, writes the code and takes it live.
Workcube custom development means writing customer-specific code where Workcube's standard screens do not cover a need. Gramoni, a Turkey-based Workcube partner, packages that code as a separate module, so the standard code of Workcube, a Turkish ERP platform, stays untouched. Five of Gramoni's own products also run on Workcube.
How we work
The same team quotes the project, writes the code and takes it live. We work to four principles:
- Every claim has a record behind it.
- You approve.
- We never modify Workcube's standard code.
- Scope is measurable.
Custom development starts where a need cannot be met with Workcube's own settings and screens. Configuration of settings and screens belongs to Workcube ERP consulting and implementation.
Changing standard code vs. a separate module
| Modifying standard code | Separate module (Gramoni's approach) | |
|---|---|---|
| Where the customer-specific code lives | Inside Workcube's standard files | In its own module, outside the standard files |
| Workcube's standard code | Changed | Unchanged |
| At update time | Changes have to be found in the updated standard files and carried over again | The custom code is not inside the standard files, so there is nothing to find there |
Technology
- CFML: ColdBox, Lucee, Adobe ColdFusion
- TypeScript: NestJS, React
- Databases: PostgreSQL, MSSQL, MySQL
- Apps and interfaces: PWA, REST
Beyond Workcube
Gramoni does not only work on Workcube. It also builds custom software outside Workcube, and its AI and automation work does not require Workcube. We can run projects in English and deliver projects outside Turkey.
For ready-made needs on Workcube, our products have their own pages: Wodiba, WAMS Logistics and manufacturing solutions for Workcube.
Why leaving standard code untouched matters
After go-live, software lives in maintenance. The international standard for that process is ISO/IEC/IEEE 14764:2022, which gives guidance for software maintenance and defines its types. For ERP, the process also includes upgrading to the vendor's new releases (Ng, Gable and Chan, 2003).
Research shows that where custom code lives makes a difference:
- Different kinds of tailoring carry different risks. Brehm, Heinzl and Markus (2001) describe ERP tailoring as a spectrum between setting parameters (configuration) and changing the code (modification). Changing ERP code, they note, is usually strongly discouraged by vendors and implementation consultants, and the choice has important implications for implementation risk and for how hard upgrades become.
- Customisation can pay off, but must be weighed against maintenance. Light (2001) studied customisations in two ERP projects. Most organisations reshape their processes to fit the software so as not to lose the vendor's maintenance and development support, yet some customisation is typically still needed. The study concludes that customisations can bring real benefits, but each one needs careful thought about its impact on future maintenance.
- Maintenance and upgrades are expensive. Ng, Gable and Chan (2003) report annual ERP maintenance costs of roughly 25% of the initial implementation cost, and upgrade costs of as much as 25–33% of the initial implementation.
- Customisation is a double-edged sword. A 2023 literature review by Hansen, Haddara and Langseth finds customisation is generally viewed negatively because it can affect the system's future updates and upgrades, yet it is unavoidable for some organisations and can give a competitive edge when it supports a non-standard, competitive process.
Software engineering calls this build-up technical debt. Ward Cunningham, who used the metaphor in 1992, compared shipping first-time code to going into debt: a little debt speeds development as long as it is paid back promptly with a rewrite, and every minute spent on not-quite-right code counts as interest on that debt.
Our conclusion is simple: if the need is real, we write custom code, but in its own module rather than inside Workcube's standard files. That keeps what is specific to you apart from the code Workcube updates.
Frequently asked questions
Does custom development change Workcube's standard code?
No. Customer-specific code is packaged as a separate module, and Workcube's standard code is not modified. Protecting the standard code is one of Gramoni's working principles.
What happens to our custom code when Workcube is updated?
The custom code lives in its own module, not inside Workcube's standard files. So your customer-specific changes do not have to be found inside updated standard files, and an update does not overwrite them there.
Which technologies do you use?
CFML (ColdBox, Lucee, Adobe ColdFusion), TypeScript (NestJS, React), the PostgreSQL, MSSQL and MySQL databases, PWA and REST.
Who quotes the work and who writes the code?
The same team. The people who quote the project also write the code and take it live; the work is not handed between teams.
Do you build software outside Workcube?
Yes. Gramoni also builds custom software beyond Workcube, and its AI and automation work does not require Workcube.
Can the project be run in English?
Yes. Gramoni can run projects in English and can deliver projects outside Turkey.
Sources
- ISO/IEC/IEEE 14764:2022 — Software engineering — Software life cycle processes — Maintenance — Estonian Centre for Standardisation and Accreditation (EVS)
- Ward Cunningham — The WyCash Portfolio Management System (OOPSLA '92 Experience Report) — c2.com
- Brehm, Heinzl, Markus — Tailoring ERP systems: a spectrum of choices and their implications (HICSS 2001) — IEEE
- Light — The maintenance implications of the customization of ERP software (2001) — Journal of Software Maintenance and Evolution: Research and Practice (Wiley)
- Ng, Gable, Chan — An ERP maintenance model (HICSS 2003) — IEEE
- Hansen, Haddara, Langseth — Investigating ERP System Customization: A Focus on Cloud-ERP (2023) — Procedia Computer Science (Elsevier)