Describe the task before choosing the software.
The starting point is the process people follow today. Who creates the information? Who checks it? What happens when a request is incomplete or needs approval? Spreadsheets, emails and existing systems often reveal the rules that a new application must respect.
We map those steps and identify the parts worth improving. The first version should address a defined problem with clear acceptance criteria. That makes the scope more useful than a broad request for a dashboard or an all-in-one system.
Define users, permissions and responsibilities.
An application may serve staff, customers, partners or the public. Each group needs access to particular actions and information. We agree which users can create, view, edit, approve or export records, including what happens when responsibilities change.
Those rules affect both the interface and the underlying implementation. It is not enough to hide a button if the operation remains available elsewhere. We plan access checks around the actual data and workflows, with administrative responsibilities and account management included in the requirements.
Give the information a consistent structure.
The data model defines the records, required fields and relationships the application relies on. A customer, project, document and order may connect in several ways, and the rules should be clear before screens are built. Validation helps identify incomplete or inconsistent information at the right point.
We also discuss searches, filters, exports and reporting requirements. A report is easier to produce reliably when the necessary information has been captured consistently, rather than inferred later from free-text notes and differently formatted spreadsheets.
Design around the frequent tasks and exceptions.
The interface should help people complete their work with a clear next step. Forms, status indicators, search and navigation are designed around the roles and frequency of use. A tool used in the field on a phone has different constraints from an internal reporting screen.
We review the main journey and the exceptions: incomplete records, empty results, permission limits and failed submissions. Useful messages should explain what happened and what the user can do, rather than exposing an unexplained technical error.
Make system boundaries explicit.
Integration work depends on the interfaces provided by the systems involved. We review available documentation, authentication, data formats and sample responses before confirming feasibility. The plan specifies which system owns each record and how changes are exchanged.
Failures, duplicate submissions and interrupted transfers need deliberate handling. A useful integration should make exceptions visible and allow a controlled retry or correction. Access to a test environment and representative data helps establish these behaviours without relying on assumptions about the live system.
Plan imports and migration with real samples.
Existing data may come from databases, spreadsheets, exports or older websites. We inspect its structure and quality, define how fields map to the new model and identify relationships that need to be preserved. The migration scope should state which records and attachments are included.
A trial import helps reveal missing values and inconsistent formats. We then agree validation checks and the final transfer procedure. The work is confirmed against actual source material, because file size alone does not describe migration complexity.
Experience with interactive and connected systems.
The Trebjesa BioMap application combines a 3D map, species and location information, and citizen-science submissions. It is separate from the project’s public information website. Nautical Fashion connects an online catalogue with pricing and stock data from a business system.
These examples illustrate different kinds of application work: exploring structured information, collecting user contributions and exchanging operational data. They inform our technical discussions, while the solution for your organisation is scoped around its own users, constraints and responsibilities.
Build in reviewable stages.
We break the agreed scope into stages that can be demonstrated and checked. Early review of the main workflow helps reveal misunderstandings before every screen is complete. Acceptance criteria describe the expected behaviour, including important edge cases and permission rules.
Testing covers the agreed functionality, responsive use, data validation and integrations. The release plan includes environment configuration, backup or recovery requirements and any coordination with other providers. Further features can be planned after the first version has a clear, usable purpose.
Include operation and future development in the estimate.
The budget depends on the workflow complexity, roles, data, integrations, migration and non-functional requirements. Requirements that appear simple on screen can involve significant rules behind them. We identify those dependencies during discovery and distinguish the first release from later possibilities.
Ownership of source code, access, hosting and documentation should be agreed before work starts. The handover also explains how the application is deployed and maintained, with ongoing support and subsequent changes covered by a clear arrangement.
Common questions
Do we need a custom application or an existing product?
We assess that before recommending a build. An established product or a small extension may already solve the problem. Custom development becomes useful when the required workflow, integration or user experience cannot be met appropriately by those options.
Can you integrate our existing business software?
We can review its available API, exports or other supported interfaces. Feasibility depends on access, documentation and the operations the software exposes. We confirm the proposed exchange and limitations before treating an integration as part of the agreed scope.
Can an application work well on phones?
Yes, when mobile use is included in the requirements. We plan the relevant tasks, navigation and forms for smaller screens. Features that depend on connectivity, device capabilities or large amounts of data need to be assessed against the intended usage.
Can you migrate information from an old system?
Yes, subject to reviewing the source and export options. We define the records, field mapping, attachments and validation checks. A sample dataset and trial import are important because inconsistencies may not be apparent from the current interface.
How do you estimate a project with uncertain requirements?
We first clarify the main workflow, users and dependencies. Where significant uncertainty remains, a defined discovery or prototype stage can establish the scope. The proposal should separate confirmed requirements from assumptions and later features that have not been estimated.
Who maintains the application after launch?
That is agreed as part of the handover. We can provide ongoing technical support and development, or prepare an agreed transfer to your team. Hosting, access, documentation and responsibilities should be explicit so the application can be operated confidently.
