Custom software & integrations
Build the missing connection in your business
A custom application is useful when an important workflow cannot be handled well by the tools you already have. The starting point is a clear operational need: who must do what, which information they need, and where existing systems get in the way.
Discuss your projectA shared delivery plan
From a defined need to maintainable software
The process turns a specific operational gap into a reviewable application or integration. These stages are proposed collaboration points, not a fixed package. The agreement defines features, platform choices, testing boundaries and the responsibilities that continue after delivery.
We agree the stages, outputs and responsibilities in your project scope. Select a stage to explore the work and decisions.
A worked example · illustrative
A request has a successful path—and a recovery path.
Illustrative integration: a business user requests an update to an authoritative record in another system.
- RequestThe user supplies the required information→
- Validate & authorizeCheck fields, identity and permitted action→
- Write to the recordApply the change to the agreed source of truth→
- Confirm & traceShow the result and keep an appropriate trace→
Return a clear correction message. Do not silently write partial or unauthorized changes.
Show a pending or failed state. Define retries, duplicate prevention and the person who reviews unresolved work.
From scope to operation
The work at each stage
Open each stage to see the work, your role, the deliverables and the check before moving forward. Feedback can return a decision to an earlier stage.
Define the job to be done
Establish who needs the application and which task it must improve.
What Lava does
Map users, decisions, current tools and failure points; compare building with configuring or connecting existing products.
Your team provides or approves
Provide representative examples, access to relevant users and a decision maker for conflicting requirements.
Stage outputs
- Problem statement and workflow map
- Prioritised requirements and open questions
Ready to move forward when…
The team can describe the intended outcome and a concrete scenario for checking it.
Review loop Revisit the need when a feature request cannot be tied to the agreed task.
Trace data and dependencies
Define where records belong and how systems exchange them.
What Lava does
Assess authorised APIs, permissions, data relationships and hosting needs; specify handling for failed or conflicting transfers.
Your team provides or approves
Provide approved technical access and confirm record ownership, acceptable delays and any external-provider constraints.
Stage outputs
- Data and integration design
- Access and operational responsibility map
Ready to move forward when…
Dependencies and permissions are assessed; any critical unknown has a named proof check before dependent development.
Review loop Revisit scope if an external service cannot support the required data or interaction.
Prove the difficult part
Resolve the most important usability or integration uncertainty before building the application.
What Lava does
Prototype the riskiest journey or connection with suitable test data; demonstrate relevant usability, failure handling and duplicate prevention.
Your team provides or approves
Review the findings with users and system owners, then choose whether to proceed or revise the approach.
Stage outputs
- Prototype and feasibility findings
- Reviewed approach and fallback decisions
Ready to move forward when…
Dependent implementation begins only after the critical feasibility check passes or an explicit, workable fallback is approved.
Review loop Return to data design or scope when the prototype exposes an unsupported connection or business rule.
Build in reviewable increments
Turn the agreed design into working features that can be inspected.
What Lava does
Implement selected journeys and integrations, with server-enforced access rules, validation and appropriate operational logging.
Your team provides or approves
Review working examples and clarify business rules using agreed test records.
Stage outputs
- Working application increments
- Implementation decisions and issue log
Ready to move forward when…
Each increment meets its agreed checks and clearly identifies unfinished functionality.
Review loop Return to design when a new rule changes permissions, record structure or connected workflows.
Validate the complete workflow
Check normal tasks, boundaries and failure recovery before release.
What Lava does
Run the agreed functional and security checks; investigate invalid input, cross-role access and connection failures.
Your team provides or approves
Complete acceptance scenarios, confirm relevant business outputs and decide how remaining issues are treated.
Stage outputs
- Test results and resolved issue record
- Business acceptance decision
Ready to move forward when…
Required scenarios pass and remaining limitations have explicit owners and decisions.
Review loop Return to the affected build or design when an issue changes expected behaviour.
Release and transfer ownership
Put the agreed version into operation with a usable technical handover.
What Lava does
Follow the release plan and provide agreed source access, deployment instructions and dependency documentation.
Your team provides or approves
Approve release, confirm account ownership and nominate the people responsible for administration and maintenance.
Stage outputs
- Release record and operational checks
- Repository, access and maintenance handover
Ready to move forward when…
The agreed live checks pass and the nominated team can follow the handover instructions.
Review loop Use the agreed recovery route if release checks fail, then resolve the underlying cause.
Choose custom development for a defined reason
The right answer may be an internal portal, a focused mobile experience, an approval workflow or a connection between existing platforms. Before choosing the technology, we define the users, the decisions they make and the systems that must remain authoritative for each record.
Custom development is most useful when the workflow is distinctive or the gaps between products create persistent manual work. If an existing product can meet the requirement through configuration, that option deserves consideration. A smaller integration can be more practical than replacing a system your team already understands.
Turn the requirement into a buildable scope
The agreed proposal can include the following, with boundaries for each feature and integration:
- A workflow map and prioritised requirements, including user roles, record ownership and the exceptions the application must handle.
- A prototype of the main journeys, allowing the people doing the work to review screens and terminology before development.
- Web or mobile functionality, an appropriate data model and integrations with available, authorised APIs.
- Access controls, input validation, error handling and operational logging appropriate to the application and its data.
- A testing and release process, plus agreed documentation, source-code access and handover of deployment responsibilities.
Decisions that shape the solution
| Choice | Practical implication |
|---|---|
| Extend, integrate or replace | Compare the remaining manual work, disruption and maintenance cost of each route before commissioning a new application. |
| Web or mobile | Choose according to where people work and whether device features, offline use or distribution requirements justify additional complexity. |
| Immediate or scheduled synchronisation | Freshness matters, but so do API limits, outages and duplicate handling. Define the acceptable delay and recovery process. |
Test the workflow, not just the screens
Your team supplies representative examples, approved access to relevant systems and a decision maker for requirements. For an integration, we need the provider’s API documentation, permission model and a suitable test environment where available. Third-party restrictions can change what is possible and should be investigated before commitments are made.
Acceptance checks should cover real tasks, permission boundaries, invalid input and failed connections. A user seeing the right screen does not prove that another user’s records are protected; relevant access rules must also be enforced on the server. Handover establishes account ownership, dependencies, deployment instructions and who maintains the application when business needs or external services change.
Questions before starting
Do we need a detailed specification already?
No. A defined problem, examples of current work and access to the people involved are enough to begin discovery. The build scope should be agreed after the requirements and important unknowns are understood.
Can the application connect to our existing tools?
That depends on each tool’s authorised integration options, data access and limits. We assess the available APIs or export methods and define how errors, updates and conflicting records will be handled.
Who owns and maintains the finished software?
The agreement should specify rights to bespoke code, third-party licence restrictions, repository access and ownership of hosting and service accounts. Maintenance, monitoring and future development also need named owners and an explicit scope.
Handover & ongoing care
After delivery: maintain the whole connection
Maintenance needs an explicit scope and owner. Software depends on business rules, external services and the environment in which it runs; a completed release does not settle all future changes.
- Keep dependency, permission and integration documentation aligned with approved changes.
- Review reported faults separately from new features and plan relevant regression checks.
Sources & further reading
A useful next step
Bring one real workflow.
A sample document, the systems you use and the decision you need to make are enough to start a focused conversation.
Talk to Lava ↗