Business applications
Build a business application around a real workflow
A custom business application becomes relevant when existing tools no longer represent how the organisation works. Spreadsheets, email and shared folders can serve a team for years. A project starts when ownership, approvals or reliable information become difficult to follow across them.
Confirm the problem before commissioning software
Observe tasks with the people performing them. Ask to see an ordinary case and a difficult one. Look for repeated entry, information waiting on colleagues and decisions happening outside existing systems. Software cannot automatically fix a process whose responsibilities are still undefined.
Review the tools already available. Configuration, training or an integration may be sufficient. Custom work becomes easier to justify when specific rules, permissions, volumes or critical journeys lack a satisfactory solution. Record that reason to avoid rebuilding an ordinary capability without a clear benefit.
Map stages, responsibilities and exceptions
Draw the journey of a request, order or case. Name the owner of each stage, the required information and the condition for progression. Include rejection, cancellation, correction and reopening. These situations often determine whether operational tracking can be trusted.
Permissions should follow these responsibilities. Someone may view a case without approving it, or prepare a change that another role confirms. Enforce access on the server as well as in the interface. A history of selected events can help explain changes without turning every interaction into unnecessary logging.
Agree data meanings before building dashboards
Define shared terms such as active customer, completed order and complete case. Different teams may use the same expression differently. Agree identifiers, statuses and authoritative sources before building dashboards that rely on them.
Test migration with representative data. Identify duplicates and values that cannot be matched. Decide whether each should be corrected, ignored or reviewed. Rehearse migration before the switch and establish how to handle changes made in the old system during the transition.
Deliver a small but complete workflow
Choose a scope narrow enough to deliver and complete enough for a pilot team to use. A collection of finished screens that cannot close a case will not validate the workflow. An initial release might cover receipt, assignment, processing and closure for a limited set of roles.
Demonstrate realistic, anonymised examples. Test exceptions and record obstacles to completing tasks. Separate essential corrections from desirable improvements. Feedback from a frequent user is useful, but compare it with other roles before making one person’s preference a rule for everyone.
Plan adoption and ongoing operation
Assign a functional owner, technical support and a channel for reporting problems. Prepare short instructions for everyday tasks: creating a case, finding a document and correcting an error. Training should follow actual work rather than visit every menu.
After launch, observe difficulties and workarounds. They may reveal an unclear rule or an unnecessary stage. Prioritise changes through shared decisions, estimates and approval. Include backups, updates and a future handover path rather than leaving ongoing operation until the end of development.
Your checklist
- Inspect real cases and the difficulties they expose.
- Document transitions, permissions and rejected actions.
- Agree terminology and authoritative data sources.
- Choose a complete workflow for a pilot team.
- Assign training, support, maintenance and change decisions.
Frequently asked questions
Must a business application replace every existing tool?
No. It can own a defined process and exchange information with retained systems. Define each system’s responsibility and how synchronisation failures will be handled.
How do we know whether the first release is complete enough?
A pilot user should be able to finish the agreed work, including ordinary exceptions, without recreating the process in a parallel tool. Secondary features can follow if their absence does not prevent that outcome.
A project to explore
Pare-Brise Éco
Pare-Brise Éco brings together business applications, mobile tools and integrations. The project page shows how related workflows can be supported within a coordinated delivery, including team training.
Explore the project