Discuss your project
Software & Cloud Development

Custom software development

Some processes are too specific, too regulated or too important to force into a generic product. We build custom applications around the way your organisation works, connect them to the systems you already run, and hand over code and documentation you own.

Discuss your project How the work is delivered

A good fit if

  • A core process runs on spreadsheets, email and an old database that only a few people understand.
  • You have evaluated packaged products and each one needs expensive workarounds.
  • An ageing in-house application needs replacing or modernising without losing its data or business rules.
  • The process sets you apart from competitors, so forcing it into a generic product would cost you something.
  • You want the application to share data with your ERP, CRM or Microsoft 365 rather than become another silo.

Another approach may suit you better if

  • The need is common, such as payroll or general accounting, and mature products already cover it well.
  • Configuring or extending your existing ERP or CRM would do the job. Our ERPNext and Prometheus customisation service may suit you better.
  • Nobody on your side can yet own the application and make decisions about it.

What this service is

Custom software development means designing and building an application specifically for your organisation, instead of adapting your work to fit a packaged product. It is the right answer less often than vendors of custom work tend to suggest, and a very good answer when it fits.

Typical examples include field inspection and work-order systems, a CRM shaped around a specialised sales or intake process, transportation and dispatch management, quoting and pricing engines, case and file management, compliance registers, and client portals tied directly to internal records. What they have in common is a process that matters to the organisation and that generic tools handle badly.

Most custom applications need the same supporting features, and we plan them from the start: sign-in through Microsoft Entra ID or Google, permissions by role, approval workflows, email and Microsoft Teams notifications, document and PDF generation, search, reporting dashboards, data exports for finance, and an audit trail. Where users work away from a desk, the application can include a mobile app or work offline, which also helps where connectivity is patchy. Where users need more than one language, screens and generated documents can be built to support it.

When custom software makes sense

Before we recommend building anything, we compare three options for the process in question:

  • Buy a product and configure it. This suits processes that are common, where a mature product fits closely.
  • Integrate the tools you already have, so data moves between them without retyping. Often the quickest improvement. See business system integration.
  • Build a custom application, or a custom module inside your ERP. This is the right choice when the fit is poor, the workarounds are expensive, or the process is a real advantage.

The assessment is written down, so you can see why we recommend what we do. For a deeper look at the trade-offs, read build, buy or integrate your business software?

Modernising legacy applications

Many organisations depend on software written years ago: an Access database, a desktop application in an outdated language, or a web system on an unsupported framework. These tools often hold business rules nobody has written down.

We start by documenting what the application does and who relies on it. Then we choose an approach: move it to supported infrastructure as it is, refactor it gradually, or replace it piece by piece so the old and new systems run together until the last function is moved. Replacing a system in stages is slower on paper but far less risky than a single cut-over.

Built to be maintained

Custom software is only an asset if it can be maintained after the original developers move on. We use widely supported frameworks, keep code in your repositories, write automated tests, document the architecture and business rules, and make sure deployments are repeatable. If your organisation runs Prometheus ERP or ERPNext, we often recommend building inside it, and our ERPNext and Prometheus customisation service covers that work.

The benefits are the ones organisations tell us they need: staff spend time on the business instead of workarounds, costs are planned in phases with estimates in naira (or US dollars where a licence or service is priced in dollars), data is protected by role-based access and audit trails, and the application can grow with you. Managed-service clients can have their custom applications covered by 24/7 monitoring and support, with response targets set in the service agreement.

What is included

The exact list is agreed in writing for each project. These are the usual deliverables and the usual boundaries.

Typical deliverables

  • A build, buy or integrate assessment with the reasoning written down.
  • Documented requirements, business rules, exceptions and user roles.
  • A data model and architecture outline.
  • The application, built iteratively with regular demonstrations.
  • Data migration from spreadsheets or the legacy system, with reconciliation reports.
  • Role-based access, audit logging and single sign-on where required.
  • Automated tests and a repeatable deployment pipeline.
  • Administrator and user documentation, training and a handover session.
  • Source code and infrastructure in your organisation's accounts.

Not included unless agreed separately

  • Licences, hosting and third-party services, billed to you with your approval.
  • Cleaning historical data beyond the agreed migration scope.
  • Redesigning the business process itself, unless included as a separate consulting item.
  • Support and enhancements after handover, unless covered by a separate agreement.

What we will need from you

Most delays in this kind of work come from access and decisions, not from the technical build. Knowing these early keeps the project predictable.

  • A process owner who knows the rules, the exceptions and the edge cases.
  • Access to existing spreadsheets, databases or systems, and permission to copy data for testing.
  • Users who can attend workshops and carry out acceptance testing.
  • A decision on hosting, such as your own cloud account, your servers or a Promatics-managed environment.
Delivery

How the work is delivered

Each stage ends with something you can review before the next one starts.

  1. Assess

    Map the process, the people involved and the systems it touches, then compare building, buying and integrating.

    Output: Assessment and recommendation.

  2. Specify

    Capture business rules, roles, data and exceptions, and agree what the first release must do.

    Output: Requirements and release plan.

  3. Build iteratively

    Short iterations with working demonstrations. Priorities can change between iterations as you see the software take shape.

    Output: Tested increments in a test environment.

  4. Migrate and go live

    Move data from the old tools, run old and new side by side where needed, and reconcile results before switching over.

    Output: Live application and reconciliation evidence.

  5. Hand over

    Documentation, training, credentials and code transfer, with an optional support agreement.

    Output: Handover pack.

Testing and handover

  • Business rules are tested with real examples from the process owner, including the awkward exceptions.
  • Migrated data is reconciled against the source, with record counts and totals signed off.
  • Access controls are tested for each role, including what a role must not be able to see or change.
  • Audit logs record who changed what and when, where the process requires it.
  • The application can be rebuilt and redeployed from the repository by someone other than Promatics.

What affects the cost

We do not publish package prices. Each estimate is based on an agreed scope, in naira, with taxes shown separately. These are the things that move the number most:

  • The number and complexity of business rules and exceptions.
  • The number of user roles and approval paths.
  • Integrations with other systems.
  • The volume and condition of data to migrate.
  • Audit, data protection and records-retention requirements.

Questions buyers usually ask

How do you decide between building and buying?

We look at how closely available products fit, what workarounds they would need, what they cost over several years, and how much the process matters to you. If a product fits, we will recommend it. Custom software earns its place when the fit is poor or the process is a genuine advantage.

Can you replace our old Access database or spreadsheet system?

Yes, and it is a common starting point. We document what the current tool does, including unwritten rules people rely on, migrate the data and run both side by side until the results match.

Should we extend our ERP instead of building something separate?

Often, yes. If you run Prometheus or ERPNext, a custom app inside the ERP shares its users, permissions and data. We recommend a separate application when the users, scale or security model are very different.

Who owns the software?

You do. The agreement assigns ownership of the code written for you, and it lives in repositories and cloud accounts in your organisation's name. We list the open-source components and their licences.

What if our requirements change during the project?

They usually do. Iterative delivery lets you reprioritise between iterations, and changes that affect scope or estimates are agreed in writing before work continues.

Guide

Build, buy or integrate?

How to decide between buying software, integrating what you already have and building your own, using a weighted worksheet that treats each option fairly.

Service

Business system integration

Connect the applications your organisation runs on so data is entered once, moves reliably, and failures are caught instead of silently lost.

Outgrown your spreadsheets or legacy system?

Describe the process, the tools it runs on today and who uses it. We will reply to arrange a conversation about whether building, buying or integrating makes most sense.

Discuss custom software