Software shaped around your approvals, records and core systems. From discovery and architecture to a tested production release.
Custom software development for workflows that standard tools cannot carry
What it is
Custom software development builds applications around your workflows, from discovery and architecture to tested delivery in production.
It is appropriate when off-the-shelf tools force staff to re-enter records, work around access restrictions or reconcile conflicting data. We first examine the workflow and existing systems, including whether configuration or a smaller integration would solve the problem without a new application.
Discovery establishes who performs each task, who approves it and which system owns the record. Architecture then defines data boundaries, integrations and deployment choices. Role-based access control and audit trails are designed with the workflow, not added as a final screen. We build in reviewable increments and test both normal operations and exceptions. Production planning includes migration checks, rollback procedures and an agreed support boundary, so launch is an operational decision rather than simply a code deployment.
The problem
The spreadsheet is not the system. Yet it is where approvals, exceptions and reconciliations end up.
Where bespoke software misses the real workflow
A specification can list every screen and still miss who owns the record, how an exception is resolved or which system authorises a transaction. These gaps surface late as manual workarounds. We examine the process, data and operational constraints before treating a feature list as a delivery plan.
The traps
Trap 0101 / 04
Screens before requirements
A brief that misses the exceptions
A happy-path demo can hide rejected approvals, duplicate records and work that crosses departments. Discovery maps the actual workflow, including exception owners and acceptance criteria. That gives engineering a testable model of the operation, not just a list of screens.
Trap 0202 / 04
A growing maintenance burden
Architecture chosen by habit
A familiar framework is not an architecture decision. Data ownership, hosting constraints and support capability matter too. We document the major trade-offs, deployment boundaries and likely change points. The design should fit the operating requirements without making every future change depend on unnecessary infrastructure.
Trap 0303 / 04
Permissions added at the end
Access rules without audit trails
A login screen does not establish who can approve a payment, export a record or change a role. We define role-based access and sensitive actions during design. Audit events include the actor, action and relevant context, with retention and access requirements agreed for the system.
Trap 0404 / 04
Disconnected records
Integrations left until launch
A new application can still leave staff copying data into finance, identity or core operational systems. We identify interfaces, record ownership and failure handling early. Integration tests cover rejected requests and duplicates, while reconciliation makes incomplete exchanges visible rather than silently accepting inconsistent records.
The process
From operating requirements to production software
Discovery defines the workflow and acceptance criteria. Architecture makes data and integration decisions explicit. Delivery proceeds in tested increments, with your operators reviewing the result. We plan migration, access and support before production so the organisation can operate what it accepts.
Step 01
Discover the workflow
Interview process owners and operators. Map approvals, exceptions, data sources and acceptance criteria before agreeing the first delivery scope.
Step 02
Design architecture
Define data ownership, RBAC, audit events and core-system interfaces. Record technology choices and the trade-offs behind them.
Step 03
Build in increments
Implement and demonstrate working flows. Review code, automate suitable tests and validate integrations against agreed contracts.
Step 04
Prove release readiness
Test permissions, exceptions and performance. Rehearse migration and rollback, then obtain business acceptance for production release.
Step 05
Deploy and hand over
Release through an agreed change process. Provide runbooks, source code and support boundaries so the operating team can take responsibility.
What you get
Working software, with the records to operate it.
Discovery and acceptance criteria
Process maps, exception paths and a prioritised scope agreed with the people responsible for the workflow.
Documented architecture
Data models, deployment boundaries and key decisions recorded for your engineering and operations teams.
RBAC and audit trails
Role-based permissions and sensitive-action records designed around approvals and operational review.
Core-system integrations
Documented interfaces, failure handling and reconciliation paths for the systems in the agreed scope.
Test and release evidence
Results for agreed acceptance, integration and permission tests, with unresolved risks made explicit.
Migration and operating runbooks
Instructions for moving data, deploying releases, rolling back changes and handling common failures.
Source code and ownership terms
Repository access, build instructions and written project IP terms, with third-party licences identified.
Selected work
Selected product and interface work
When is custom software the right choice?
Start with the workflow, not the assumption that you need a new application. Custom development is worth considering when existing products cannot support essential approvals, data boundaries or integrations without costly workarounds. Discovery compares a bespoke build with configuration and targeted integration. It should produce a reasoned scope, including what not to build.
How do you estimate the cost?
Cost depends on workflow complexity, integrations, migration, access requirements and the evidence needed for acceptance. Discovery reduces uncertainty before a delivery estimate is committed. The proposal should distinguish build costs from hosting, licences and ongoing support. Where requirements are uncertain, phase the work rather than present an early guess as a fixed commitment.
How long does delivery take?
There is no useful universal timeline for an enterprise application. We establish a delivery plan after examining the workflows, interfaces and data. The plan identifies an initial usable scope, review points and dependencies on your teams or vendors. Migration rehearsals, acceptance and production approvals are part of the schedule, not tasks left after development.
How is the technology stack chosen?
We assess deployment constraints, data sensitivity, expected workloads, internal skills and maintenance needs. Architecture decisions record the reasons for the selected approach and its trade-offs. Existing platforms are considered before introducing new services. Your team should be able to review and operate the resulting system without inheriting an unexplained collection of dependencies.
How do you handle permissions and audit trails?
We define roles and sensitive actions with process owners, including who can approve, export or amend records. Tests cover unauthorised actions as well as permitted ones. Audit events record relevant changes and actor context; retention, visibility and protection of those records are agreed during design. This supports review and evidence without claiming that software alone guarantees compliance.
Can you integrate with our core systems?
We scope integrations after reviewing API documentation, authentication, vendor restrictions and available test environments. The design identifies the authoritative record, error handling and reconciliation rules. Where an interface is unavailable, that dependency must be resolved or the scope changed. We do not assume that access to a system means permission to alter it.
Will we own the code and documentation?
The agreement sets out ownership of commissioned source code and project IP, repository access and handover duties. Pre-existing components and third-party licences are listed separately. Build instructions, architecture notes and deployment procedures should accompany the code. This allows your engineers or a future supplier to take over without reconstructing the system from scratch.
What happens after production launch?
The release plan identifies who monitors the application, handles incidents and approves fixes. Warranty, maintenance and ongoing enhancements are agreed separately rather than implied by the build fee. Handover includes runbooks and known issues. If you need continuing delivery capacity, software development as a service provides a different engagement model from a fixed project.
Software development as a service, or a fixed project? How to choose
6 min read
Compare monthly capacity with a defined project scope: ownership, planning, changing priorities and the decisions that belong in the agreement.
Designing internal tools people actually use
6 min read
Lessons from Relix, Victora and Interoly on tasks, handoffs and interfaces. Start with the work operators need to complete, not a screen inventory.
What a regulator-ready VAPT report contains
6 min read
Examine the scope, evidence, remediation guidance and retest records that make a security assessment useful to engineering and oversight teams.
The 72-hour clock: what NDPA and the GAID demand of your systems
6 min read
Consider incident records, escalation paths and data visibility when preparing systems to support breach assessment and notification decisions.
Sophos or Fortinet? Choosing the security stack for a Nigerian enterprise
6 min read
Compare security-stack requirements through deployment constraints, operational ownership and the evidence your team needs for ongoing review.
Other services
