Standard software
Usually the best fit when the process is common and an existing product already supports the required functions, roles and controls.
Custom financial software
Have custom software built for financial processes
Custom software for financial processes is intended for organisations whose administrative workflows, controls, user roles or data flows cannot be accommodated appropriately in standard software. Possible applications include internal finance tools, client portals, approval workflows and financial data integrations.
Before Flicc develops software, we investigate whether existing software, configuration or process automation can already solve the problem. The first step is therefore a discussion about the process, users, data, exceptions and the objective of the solution.
Decision framework
When should you choose custom software?
Custom development is not automatically the best solution. The choice depends on how unique the process is, the available software, technical options and the investment and management burden involved.
Process automation
May be sufficient when the software itself fits but data transfer, recurring tasks or the workflow between systems needs improvement.
Custom software
Becomes relevant when unique rules, roles, controls, data flows or user actions cannot be accommodated appropriately in existing solutions.
The deliverable
What do you get in a custom software engagement?
Specific deliverables are defined in advance. One-off development and recurring costs or responsibilities for licences, hosting, management and maintenance are documented separately.
- Description of the financial or administrative problem and intended objective
- Overview of users, roles, permissions and responsibilities within scope
- Functional requirements, process steps, data flows and required integrations
- Screen and workflow design for the agreed functionality
- Phased technical development of the agreed components
- Test and acceptance criteria for functions, roles, data and exceptions
- A working solution within the agreed technical environment
- Controlled commissioning and handover according to the project agreements
- Documented agreements on documentation, accounts, hosting, management and maintenance
Possible applications
Custom software for financial processes in practice
These examples show the types of functionality for which custom development can be investigated. They are not published client cases or claims about results already achieved.
Internal finance tool
A possible application for recurring financial controls, exceptions, internal follow-up or data processing.
Client or submission portal
An environment where clients or team members can submit documents, data or requests according to a fixed structure.
Approval workflow
Workflow software for statuses, roles, controls and approvals within a financial or administrative process.
API integration for accounting
A custom data-exchange route when no suitable standard integration exists and the APIs involved allow it.
Control and exception application
Software that makes agreed deviations, missing data or inconsistencies visible for further review.
Reporting environment
A central environment for agreed reports, exports, dashboards or management information.
Scope
What does Flicc perform within a software engagement?
Flicc is the point of contact for the components performed within the engagement. When systems or other external parties are required, we document dependencies and responsibilities in advance.
Process and need
Flicc maps the financial process, users, bottlenecks, data and desired outcome before selecting a technical direction.
Functional solution
We translate the need into functions, screen structure, roles, workflows, data flows, integrations and acceptance criteria.
Development and APIs
Flicc develops the agreed software and configures API integrations where required, subject to the capabilities of third-party systems.
Testing and handover
We test the agreed functions and exceptions. Commissioning, documentation, accounts, support and management are documented for each project.
Approach
From process question to controlled commissioning
Programming languages, the technical environment and deployment route are not presented as one universal solution. They follow from the requirements, integrations, accounts and project agreements.
Assess the need
We first investigate whether standard software, configuration or process automation can already solve the problem adequately.
Functional design
Users, roles, screens, process steps, data flows, exceptions and acceptance criteria are documented.
Phased development
The agreed functionality and integrations are developed in manageable components and reviewed along the way.
Testing and acceptance
Representative test data, user roles, API errors, missing or duplicate data and relevant interfaces are reviewed.
Commissioning and next steps
Following client acceptance, the agreed commissioning takes place and handover, management and any further development are documented.
Testing and acceptance
Control points before the software is commissioned
Tests are linked to the agreed functions and risks. Where possible, we use representative, privacy-conscious test data instead of unnecessary production data.
Functions and user roles
Acceptance criteria describe what a function should do and which role may view, add, change or approve data.
Data and API exceptions
Tests can include missing or duplicate data, invalid input, API errors and recovery after failed processing.
Interfaces and devices
When the solution contains a web interface, the agreed browsers, screen sizes and key user journeys are reviewed.
Client acceptance and commissioning
The client assesses the agreed criteria before the solution is commissioned through the agreed route.
Project agreements
Ownership, handover, security and privacy
These subjects differ by solution and technical environment. They therefore belong in explicit project agreements rather than as a general guarantee on a webpage.
Ownership and transferability
There is no universal arrangement for every project. Before work starts, the parties contractually document who owns or manages the source code, repository, hosting and cloud accounts, API accounts, tokens, licences and data.
- Which source code and documentation are transferred
- Which accounts are held by the client or supplier
- How data can be exported
- What is transferred when the collaboration ends
- What information a successor developer needs
Security and privacy
Required measures are determined by the data, users and systems involved. Scope may include agreements on roles, authentication, token access, logging, backups, personal data, export and deletion.
- No general guarantee or certification claim
- Document permissions and responsibilities in advance
- Identify dependencies on external systems
- Incident and recovery arrangements only where agreed
- Assess processor and data-location questions case by case
After delivery
Maintenance and further development are agreed separately
Custom software creates ongoing responsibilities. The agreement determines who performs which work and what is or is not included in support.
Bugs and changes
What qualifies as a bug, change or new feature after delivery and how requests are handled is documented in the project agreements.
External dependencies
Changes to third-party APIs, accounts or software may require adaptation. Responsibility and maintenance for this are not automatically included.
Monitoring and support
Ongoing monitoring, maintenance, updates, support or an SLA are only part of the service when agreed separately.
Scope boundaries
Custom software within your financial information chain
Custom development creates new functionality. Other services may be more logical when the question primarily concerns connecting, processing, visualising or interpreting information.
Frequently asked questions
Frequently asked questions about custom software
When is custom software better than standard software?
Custom software may be suitable when unique rules, roles, controls, data flows or user processes cannot be accommodated in existing software. Standard software or process automation is often more logical when existing solutions already support the core need. We therefore first investigate whether custom development is genuinely necessary.
How much does custom software cost?
This depends on the functional scope, user roles, screens, data flows, integrations, testing requirements, technical environment and arrangements for commissioning and management. A responsible fixed price cannot be given without this inventory.
How long does a custom software project take?
The duration depends on the size and clarity of the requirements, external dependencies, API availability, feedback moments, test scenarios and acceptance. The schedule is therefore established after the engagement has been defined.
Who owns the source code and data?
Ownership of source code, data, repositories, hosting accounts, API accounts and licences is documented contractually in advance. Arrangements may differ by project and should also describe what is transferred when the collaboration ends.
How are security and user permissions handled?
Requirements are determined based on the data, roles and systems involved. Within the agreed scope, we document which authentication and authorisation options are used, who manages access and what arrangements apply to tokens, logging, backups, personal data and recovery.
What happens after delivery?
This is agreed for each project. Commissioning and handover may be followed by separate arrangements for bugs, updates, maintenance, monitoring, support or further development. These components are not automatically included.
Can existing systems be connected through an API?
Flicc can develop API integrations when the systems involved provide a suitable and accessible API. The available data, documentation, authorisation, limits and error handling of third parties partly determine what is technically possible.
Can another developer take over the software later?
This depends on the prior arrangements for source code, repositories, accounts, licences, documentation and handover. If transferability is important, it should be included explicitly in the scope and agreement.
Discuss your software question
Discuss whether custom software makes sense for your process
We first review the problem, users, existing systems and alternatives. This clarifies whether custom software, automation or an existing solution is the appropriate next step.