A small team, working on serious infrastructure.
Madsoft Technologies is a software and applied-AI practice. We build systems of record for operations where being wrong is expensive — a clearance platform running at three national customs administrations, integrated with ASYCUDA and ICUMS, and the same engineering behind a farm-to-retail custody ledger, an institute's student records, and the infrastructure they all run on.
We took the work nobody local was doing.
That is where we started. It is not the boundary of what the work turned out to be good for.
National customs and port systems are usually bought abroad, configured badly, and abandoned. We build them on the ground — close enough to the operators to watch a shift, and accountable enough to still be reachable a year later.
That has taken us from national port operations to one of the region’s busiest commercial border crossings, and from OCR pipelines for customs tickets to a ledger tracking produce from farm to retail. The same platform now runs in three countries, which is the part we are proudest of: the second deployment cost a fraction of the first, and the third less again.
Border work sets the bar, so we lead with it. But what a customs administration demands — an attributable record, a workflow that survives a dead link at the worst moment, a handover that does not depend on us staying friendly — is what an institute, a consortium or an operations team turns out to need too. They simply have nobody obliging them to ask for it. Most of our work is now outside government.
What that makes us wrong for: anything disposable. If the record will not be challenged, nobody is accountable for it, and a rebuild in two years is acceptable, this discipline is overhead you should not pay for. We will say so at the first meeting rather than the third invoice.
- National customs administrations
- 3
- Endpoints in production
- 30+
- Sectors delivered
- 5
- Operator screens, one platform
- 40+
Customs is the hardest case, not the only one.
A national border is the strictest version of a problem that turns up almost everywhere: several parties who disagree about one record, entered furthest from the data centre, and inspected later by someone who was not there. Clear that bar and a student record or a cold chain is the same machinery under a lighter statute.
10 published engagements across 5 sectors. Counted from the case studies themselves, so this cannot drift from the work.
All projects →Government
04Customs clearance, port operations, a commercial border weighbridge, and a command centre federating five live databases read-only. Several agencies, one record, an auditor arriving years later.
Enterprise
03A farm-to-retail custody ledger settling payment by smart contract, an operations workflow platform, and incentive administration. The same argument about the record, without a statute behind it.
Education
01Registrar, finance, lecturer, administrator and student working one data model — enrolment, fees, grade capture, signed documents, OCR intake — then migrated onto infrastructure the institute owns.
Cloud
01Managed cloud and mail infrastructure run for institutions that need their data resident in their jurisdiction and a named person to call about it.
Hospitality
01A brand and booking platform built to stay quick where bandwidth is metered and most visitors arrive on a phone.
Eight positions, and what each one costs us.
A principle with no trade-off attached is marketing. Each of these has a line underneath it describing the work we turn down to hold it — that is the part you should judge us on.
Why
Records get inspected — by an auditor, a regulator, a board, a client disputing an invoice — sometimes years later, usually by someone who was not there. A record that cannot answer who changed what, when, and on whose authority is not evidence. It is a rumour with a database behind it.
What we refuse
We will not build a bulk-edit tool that bypasses the audit trail, however much faster it would make a migration.
In practice
- Named individual accounts; no shared logins, ever
- Append-only audit of privileged actions, stored independently of the application
- Every state change carries actor, timestamp and justification
- Audit trails are the same records the workflow runs on, not a report generated afterwards
Why
The most consequential data in a national system is entered furthest from the data centre — at a border post, in a field, at a gate. Those are exactly the places with one contended link and a generator.
What we refuse
We will not sign off a field workflow that has only been tested on office wifi.
In practice
- Client-generated identifiers, so records exist before the server knows about them
- Durable local queue with explicit ordering and per-entity conflict rules
- Interfaces distinguish captured, submitted and confirmed
- Tested on the real hardware, at the real site, on a working day
Why
Once a model sits inside an operation it stops being a demo and starts deciding things about people — whether a consignment is held, a duty assessed, an application flagged, a payment delayed. The question is never whether it works. It is how often it fails, and in which direction.
What we refuse
We will not ship a model whose error rate we cannot state, and we will tell you when the honest answer is a rules engine.
In practice
- An evaluation harness before the model reaches production
- Accuracy reported as a number, with the failure modes named
- A human decision point wherever the model affects a person's liability
- Model outputs logged with inputs, so a decision can be reconstructed
Why
A blockchain buys exactly one property — a shared history no single party can quietly revise — and charges heavily for it in write speed, upgrade difficulty and permanent key-management burden. It is worth paying only when several genuinely independent parties will dispute the record.
What we refuse
We have talked more clients out of blockchain than into it, including ones who arrived with the budget already approved.
In practice
- The three-part test applied before the technology is chosen
- Key custody and recovery designed before the contracts are written
- Physical tags bridging cryptographic records to real objects
- An honest recommendation of a database and an audit table when that is the right answer
Why
Sovereignty is not a political slogan; it is a question about decision latency. When a revenue platform stops at 2am, what matters is whether someone empowered to fix it can be reached — and whether they need anyone's permission.
What we refuse
We will not architect a dependency on ourselves, even though vendors who do earn more from the same contract.
In practice
- Deployment within your jurisdiction by default for public-sector work
- Infrastructure accounts, DNS and credentials in the institution's name
- Documented data export in non-proprietary formats, executable without us
- On completion, we hold no key you cannot revoke
Why
Most failed public-sector software fails before a line is written, because it was scoped from a manual describing the process as designed rather than the accumulated workarounds actually keeping the port moving.
What we refuse
We will not quote a fixed price from a document alone. If that costs us the tender, it costs us the tender.
In practice
- A full shift observed at the busiest site before scope is agreed
- The people who will use it consulted before the people who will sign for it
- Workarounds documented as requirements, not treated as misuse
- Scope revised when observation contradicts the brief — and the contradiction stated plainly
Why
These systems outlive the officials who signed for them, the vendor who built them, and often the technology fashion they were built during. Novelty in the stack is a cost paid by whoever maintains it next.
What we refuse
We will not select a technology because it is interesting to us. Our enjoyment is not a project requirement.
In practice
- Mainstream, well-documented technologies with a real hiring pool
- Typed codebases, tested at the boundaries that matter
- No dependency added without a reason that survives being questioned
- Architecture a competent engineer can understand from the repository alone
Why
A project is not delivered when it works. It is delivered when it can be operated, changed and recovered by people who have never met us — because eventually that is exactly who will be running it.
What we refuse
We will not treat support as a hostage arrangement. Clients retain us because they want to, not because they cannot leave.
In practice
- Source held by the institution throughout, not delivered as an archive
- Independent build verification from delivered source and docs before final payment
- A runbook written for an engineer who has never met us
- A restore drill performed before go-live, not promised after
How a project actually runs.
Five phases, each with what you receive and what we need from you. Durations are typical for a national-scale system; a focused internal tool compresses by roughly half.
We spend a full shift at the busiest site, standing where the operators stand. We record the process as performed, including every workaround, paper form and informal step that keeps it moving. Those workarounds are requirements. Treating them as misuse is how systems get built that people route around.
What you receive
- Observed process map, as performed rather than as documented
- Stakeholder and role inventory with actual permissions in use
- Constraint register — connectivity, power, hardware, language, literacy
- An honest note on whether we are the right supplier for this
What we need from you
- Site access during a normal working day
- Time with operators, not only managers
We turn observation into an architecture and a scope you can hold us to. This is where we say what we would not build, and where a technology choice gets justified in writing rather than assumed. Fixed-price quotes are issued here and not before, because a price quoted from a specification is a guess dressed as a commitment.
What you receive
- Architecture and data model, with the reasoning for each significant choice
- Scope statement including explicit non-goals
- Fixed-price proposal with milestone structure
- Security, residency and access-control design
What we need from you
- A decision-maker who can approve scope
- Access to existing systems and schemas
The first release targets the single riskiest part of the system, not the easiest. It goes to real operators at a real site as early as it is safe to do so. Direction changes here are cheap; after go-live they are not. We would rather discover in week five that the scanner cannot read in direct sunlight than in month six.
What you receive
- Working software in a staging environment from the first fortnight
- Pilot with named operators at a live site
- Evaluation results where machine learning is involved
- Fortnightly demonstrations against the milestone plan
What we need from you
- Nominated pilot operators
- A test environment mirroring production data shape
We ship into the constraints you have, including the ones about connectivity and power. Backups are taken and then restored, in a drill, before go-live. A backup that has never been restored is not a backup; it is a belief. Rollout is staged by site or role so that a problem affects one group rather than the country.
What you receive
- Production deployment on infrastructure in your name
- Monitoring, alerting and a restore drill completed and witnessed
- Staged rollout plan with defined rollback
- Operator training, recorded so it survives staff turnover
What we need from you
- Infrastructure decisions and DNS control
- Training time released for operators
Before final payment we support an independent build: a third party of your choosing rebuilds and deploys the system from the delivered source using only the delivered documentation. It catches everything — undocumented variables, a dependency that lived on one laptop, a deployment always done by hand. Support afterwards is a separate, cancellable agreement.
What you receive
- Independent build verification, supported at our cost
- Runbook aimed at an engineer who has never met us
- All credentials, accounts and DNS transferred to the institution
- Documented data export you can run without us
What we need from you
- A nominated technical owner on your side
- A third party for build verification, if desired
Start here
Bring us the problem
nobody has solved.
A 30-minute technical briefing. We will tell you what we would build, roughly what it costs, and honestly whether we are the right people for it.