You need evidence of the current system’s quality, risks or limitations.
Software audit →OXIAE / SOFTWARE DEVELOPMENT
Custom business software.
Bring internal operations together in software built for your business.
Discuss your projectAssess, modernise or develop?
You want to improve or replace a selected component, with agreed availability during the transition.
Legacy software modernisation →You need a business function that an existing product or the current environment does not adequately support.
Custom software development →UNDERSTAND THE SERVICE
How can departments work with the same information?
Custom business software supports internal work that depends on shared information. An item of equipment can have a stable identity while facilities maintains its location, planning its assigned team and maintenance its next service date. I work with you to define what each record and field means, who may change it and which source is authoritative. The central data model is that shared agreement; it does not prescribe a central database, a complete migration or a new ERP. Existing applications can remain part of the solution. This is a specific use of custom software development for the daily work of your organisation.
When it is a good fit
This fits when departments use the same objects but separate lists show different locations, owners or statuses. The scope then covers recording and changing information as well as using it together. If the main uncertainty is who performs the next task or review, workflow software provides a more focused scope.
When to take a different approach
An existing product may be sufficient when it already supports the required records, roles and working arrangements. If the sources are correct and the need is mainly to view information, consider dashboard development. Missing data owners require an organisational decision first; new software cannot make that decision itself.
PRACTICAL DECISION GUIDE
Model business software around responsibilities
Custom business software formalizes how an organization actually works. I investigate who enters data, who approves changes and which system is authoritative. A shared spreadsheet may conceal several processes with different roles, states and retention needs. [1]
We translate those agreements into a data model and recognizable work actions. Important changes remain traceable without unnecessarily copying sensitive content into logs. Migration and reconciliation are designed in advance so employees can verify that existing records reached the new application completely and correctly. [2][3]
Questions to settle first
- Which role may change a record after approval?
- How will employees check the completeness of migrated information?
Make acceptance measurable
- A role and process model employees can assess using their own records.
- Reconciliation of migration counts, samples and rejected records.
Fictional design example — not a customer case
One item of equipment, three departments and clear field owners
This original example uses the fictional equipment item EQ-014. It illustrates design agreements for a shared register. Values and roles are illustrative; no working application, migration or business result has been demonstrated.
Give the equipment a lasting identity
The register manager creates EQ-014 in the equipment register and owns this identity. Moving it or assigning another team does not change its ID. References to location, planning and maintenance records link to this ID; a different spelling of the equipment name does not create another item.
Assign a source and owner to each field
Facilities owns ‘location’ in the location register: North Workshop. Planning owns ‘assigned team’ in the planning application: Installation Team. The maintenance coordinator owns ‘next maintenance date’ in the maintenance register: 15 January 2027. The register manager owns the equipment ID. Each source is authoritative only for its agreed fields.
Separate reading from editing
Operational staff read where EQ-014 is and which team uses it. Team leaders also read the maintenance date when discussing assignments. Only designated roles change their own fields, through the agreed source or an input function that updates that source. A reader can report a discrepancy without replacing the authoritative value.
Apply changes without resetting other fields
Facilities moves EQ-014 to South Workshop. Planning then assigns the same item to Service Team. Both changes stay with EQ-014 and affect only their own field. An older planning view must not reset the new location. The shared view shows when values from each source were last updated.
Treat a conflict as a question for the owner
Two facilities staff start from the same version showing South Workshop: the first selects West Workshop and the second East Workshop. The second change does not silently replace the first. The current value and difference become visible. Facilities checks the actual location, confirms West Workshop and records the outcome with its reason. Team and maintenance date stay unchanged.
Reconcile with sources and show uncertainty
A check compares EQ-014 and its three shared field values with their authoritative records. An old separate list showing North Workshop differs from the verified West Workshop location; facilities receives that discrepancy. If the maintenance register is temporarily unavailable, the previous date remains recognisable as potentially stale. The maintenance coordinator investigates and requests another comparison after recovery.
What the process delivers
The design gives each department a useful view of the same equipment, with separate responsibility for identity, location, team and maintenance. The register can connect existing applications; this example does not require replacing the entire business environment.
How to test this example
- In a future acceptance exercise, moving equipment and changing its team preserve the same equipment ID; selected source values appear against precisely EQ-014.
- A team change from an older view does not reset location. Two conflicting location edits lead to the agreed review and a traceable outcome.
- An operational reader can view the assigned fields and report a difference but cannot change location, team assignment or maintenance date.
- A stale maintenance source and a source discrepancy are visible. The assigned owner can investigate and run another comparison after correction.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Configure existing business software | Existing features support the shared register and the required work. | Check that meanings, editing permissions, history and exceptions actually fit before adding custom features. |
| Connect existing applications | Each department can keep working in its own application and mainly lacks data exchange. | Agree an authoritative source, freshness and correction route for each field. A connection cannot replace a missing function for managing records. |
| Custom business software | Departments lack a shared way to maintain records and carry out their work. | Scope the initial objects, fields, roles and actions. Source agreements, operation and connections to existing applications belong in the design. |
What I need to start
- One bounded area of work with participating departments and their daily actions. Define the managed objects, such as equipment, locations and teams, and how stable IDs refer to existing records.
- A meaning, allowed values, business owner and authoritative source for each field. Distinguish current location, assigned team and maintenance date; one owner for the entire record is not automatically appropriate.
- Agreements for each role on reading, creation, editing and retirement. Define where a change is made, how corrections are recorded and what happens when two changes use the same older version.
- For existing applications: supported access, ID mapping and visible source freshness. Software integrations can carry agreed fields; assign an owner for differences, missing records and source outages.
- An agreed first version, daily operation and handover. Migrating existing lists is included only when sources, selection, conversion, checks and a rollout plan have been scoped separately.
How to assess the result
- Participating departments use the same stable identity and field meanings for the same object. Representative records are compared with the agreed source for each field; missing, duplicate or differing values receive an explained outcome.
- A location or team change updates the intended object. Editing one field does not overwrite other fields with older values; a same-field conflict follows the agreed rule and remains explainable.
- Users can perform the agreed daily actions in their roles. Read and edit permissions are assessed separately, including changes made outside visible screen controls.
- An unavailable or stale source is recognisable. Reconciliation shows differences between the shared view and authoritative fields, with an owner for investigation, correction and rechecking.
- Handover describes the model, field owners, editing rules, source dependencies and daily operation. If migration is selected, the agreed source selection and field values are checked before use; unresolved differences remain visible.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- The initial scope specifies object types, fields, roles, actions and participating departments. An equipment register with a few editing functions has a different scope from a complete business application.
- The number of existing sources, supported access, ID mapping and change exceptions. Investigating conflicting or incomplete lists is scoped separately.
- An optional migration requires selected source records, cleanup, a trial conversion, reconciliation and rollout arrangements. That work follows an explicit scope decision.
- Hosting, any licences, support, source changes and maintenance after handover are agreed separately. Additional departments, object types and features change the agreed scope.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
Your organisation uses separate lists with conflicting versions of the same information.
Internal business software can bring tasks and information together in one environment. Workflow software specifically addresses the sequence of tasks and approvals. Through software integrations, existing applications can remain part of that environment, with clear rules about where information is updated.
THE QUESTION I ASK FIRST
Which information needs a single owner, and which departments use it?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Does all information need to move into one new database?
No. A central data model defines what information means, how records relate and who maintains each field. Authoritative values can remain in different existing applications. We then choose the storage, shared views and editing functions the work needs.
Who can change information used by several departments?
We agree this by field and action. Facilities can maintain location while planning maintains the assigned team. Other roles may read those values. We also define how corrections are requested and concurrent changes are reviewed; the last value received is not automatically correct.
Can we keep our current applications?
Yes, where they provide the agreed functions and supported access. For each field, we define which source remains authoritative and where users make changes. A shared view can combine information without replacing every application. Insufficient access or missing features are investigated first.
What happens to our existing spreadsheets?
We first decide whether migration is needed and which lists are usable sources. For a selected migration, we agree how IDs, duplicate records, missing fields and conflicts are handled. A trial conversion and comparison with the selected sources precede daily use; unexplained differences are not silently carried over.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Authorization Cheat SheetOWASP
Basis for roles and per-action authorization.
Link and relevance checked: - Logging Cheat SheetOWASP
Guidance for traceability without unnecessary data copies.
Link and relevance checked: - Data on the Web Best PracticesW3C
Principles for data quality and provenance.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Custom business software? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief