SERVICE LINE
Software Engineering
We design, build and maintain custom applications for organisations whose processes are too particular for off-the-shelf software. Sixty-two engineers, two-week sprints, tested code, documented handover and source-code escrow as standard.
Software built for how Nigerian institutions actually work
The Software Engineering practice is the oldest part of Brilliant Esystems and remains its largest, with sixty-two engineers, designers, business analysts and testers working out of Kano and Lagos under Nasiru Ahmad Shanono, Director of Software Engineering. We build the systems that packaged software will not fit: a revenue platform that must reconcile against a state treasury single account, a hospital records system that has to work when the fibre link to Kano drops, a payroll engine that models thirteen separate allowance rules written into a state civil service circular in 1998. Where a commercial product genuinely fits, we say so and configure it instead.
Most of our work falls into six shapes: line-of-business applications, management information systems, public-facing portals and self-service channels, API and integration layers, mobile applications for field workers and citizens, and the modernisation of legacy systems that still run the business but can no longer be safely changed. The last category is growing fastest. A large share of Nigerian public-sector software is a decade or more old, undocumented, and dependent on one or two people who know where the bodies are buried; strangling that system gradually into a maintainable one is careful, unglamorous work that we have now done more than forty times.
We are opinionated about a small number of things. Requirements are written down and signed. Code is reviewed by a second engineer before it merges. Tests run automatically on every commit. Deployments are scripted, never manual. And the client owns the source code outright at the end of the engagement, with a documented build, a populated repository, and a knowledge-transfer programme for the team who will inherit it.
What we build
Six sub-offerings, each with a standing team and a reference implementation you can see running.
Line-of-business applications
Core systems
Case management, licensing, permits, inspections, claims and workflow systems built around a documented process model, with role-based access, full audit trail and configurable approval chains.
Management information systems
Operational reporting
Consolidated reporting across agencies, branches and facilities, with scheduled returns, exception alerts and an executive view that survives contact with a board meeting.
Portals and self-service
Citizen and customer channels
Drupal and Laravel portals for registration, payment, application tracking and document issue, designed for low bandwidth and tested on the handsets Nigerians actually carry.
API and integration layers
Interoperability
REST and GraphQL interfaces, message queues, event streams and adapter services that let systems built a decade apart exchange data safely and reversibly.
Mobile applications
Field and public
Flutter and React Native applications with offline-first storage and conflict-aware synchronisation, for enumerators, meter readers, inspectors, health workers and field sales teams.
Legacy modernisation
Rescue and rebuild
Assessment, documentation and incremental replacement of ageing systems, using the strangler pattern so that the business keeps running while the platform underneath it changes.
What you get, on every engagement
These are contractual deliverables, not aspirations. They appear in the schedule of every software contract we sign.
- A signed requirement register and traceability matrix linking every requirement to a test case
- The full source code in a Git repository you own, with commit history intact
- Automated build and deployment pipelines in GitLab CI, documented and runnable by your team
- Unit and integration test suites, with coverage reported on every pipeline run
- Architecture decision records explaining why each significant choice was made
- Database schema documentation, entity-relationship diagrams and a seeded test dataset
- API documentation published as OpenAPI specifications with a working sandbox
- Administrator and end-user manuals in plain English, plus recorded walkthroughs
- A structured knowledge-transfer programme for your in-house developers and administrators
- A defect-warranty period of 90 to 180 days after acceptance, at no additional cost
- Source-code escrow with a Nigerian escrow agent where the contract requires it
- A named technical account manager for the life of the warranty and any retainer that follows
Our software development lifecycle
Scrum with the ceremonies that matter and none of the ones that do not. Sprints are two weeks. Every sprint ends with working software demonstrated to the client, never with a status deck.
Inception and requirements
Business analysts run process-mapping workshops with the people who do the work, not only with the people who commission it. Output is a requirement register, process maps in BPMN, a data dictionary and a prioritised product backlog with acceptance criteria.
Architecture and design
Solution architects fix the technology stack, service boundaries, data model, integration contracts, security controls and non-functional targets. Interaction designers produce clickable prototypes that are tested with real users before build begins.
Sprint delivery
Cross-functional squads of four to seven people deliver in two-week sprints. Every story is peer-reviewed, unit-tested and merged through a pipeline that runs static analysis, dependency scanning and the full test suite before anything reaches an environment.
System and integration testing
Our test team exercises end-to-end scenarios across integrated systems, runs load tests against agreed concurrency targets, and executes negative and failover cases. Findings are logged, fixed and retested inside the sprint cadence.
User acceptance testing
Named client testers work through scripted scenarios in a dedicated UAT environment loaded with migrated data. We supply the scripts, train the testers, sit with them, and hold a daily triage call until the defect list closes.
Go-live and warranty
Deployment follows a rehearsed cutover plan with a rollback point. Hypercare runs for the first two weeks with engineers on standby, then settles into the warranty period, after which the system can move to a managed-service retainer.
Deliverables by phase
What is produced, who signs it, and how long the phase typically runs on a mid-sized build.
| Phase | Key deliverables | Client sign-off | Typical duration |
|---|---|---|---|
| Inception | Discovery report, requirement register, process maps, data dictionary, prioritised backlog | Project sponsor and process owners | 3 – 5 weeks |
| Design | Solution architecture document, data model, integration contracts, clickable prototype, security design | Client architect and information security officer | 3 – 6 weeks |
| Build | Working increments each sprint, source code, automated tests, deployment pipeline, sprint demonstration notes | Product owner at each sprint review | 12 – 36 weeks |
| Test and assure | Test strategy, test scripts, defect register, performance test report, security test report | Client test manager | 4 – 8 weeks |
| Deploy and migrate | Cutover plan, rollback plan, data migration reconciliation report, production runbook | Project sponsor at the go or no-go gate | 2 – 5 weeks |
| Warranty and handover | Manuals, training records, escrow deposit, architecture decision records, defect closure report | Client IT head at final acceptance | 90 – 180 days |
The practice today
62
Engineers and analysts
Software Engineering practice
140+
Applications in production
Built and still running
2 weeks
Sprint cadence
Demonstrated working software each sprint
180 days
Maximum warranty
Defect cover after acceptance
Frequently asked questions
What is your technology stack?
Who owns the intellectual property in what you build?
Will we be locked into Brilliant Esystems for support?
How do you handle changes to scope mid-project?
Can you work alongside our internal development team?
What happens if a serious defect appears after go-live?
Related work
Much of what this practice builds ends up productised. BrilliantEd, our school management system at /solutions/school-management-system, and BrilliantRevenue, the government revenue platform at /solutions/government-revenue-platform, both began as bespoke builds for single clients before being generalised.
For sector context, see our work in Government and Public Sector at /industries/government and in Education at /industries/education.
Have a system that needs building — or rescuing?
Send us the requirement document, the tender, or simply a description of the process that is currently held together by spreadsheets. Nasiru Shanono and his leads will give you a scoped, costed and honest response within one working day.