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 — an executive command centre federating five production databases, a farm-to-retail custody ledger settling by smart contract, an institute's student records across five roles, and the infrastructure they all run on.
We build the software that was being bought abroad.
That is where we started. It is not the boundary of what the work turned out to be good for.
Serious operational software is usually bought abroad, configured badly, and abandoned. We build it 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 an executive command centre reading five production databases at once to a consignment workflow that replaced paper across six roles, and from OCR intake pipelines to a ledger tracking produce from farm to retail. The part we are proudest of is that the same platform has been deployed more than once: the second deployment cost a fraction of the first, and the third less again.
The strictest work sets the bar, so it is the bar we build to. What a regulated operation 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.
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.
- Engagements delivered
- 10
- Endpoints in production
- 30+
- Sectors delivered
- 5
- Operator screens, one platform
- 40+
One discipline, five kinds of system.
Underneath the sectors it is one problem repeating: several parties who disagree about one record, entered furthest from the data centre, and inspected later by someone who was not there. A student transcript, a cold chain and an operations ledger are the same machinery wearing different clothes.
10 published engagements across 5 sectors. Counted from the case studies themselves, so this cannot drift from the work.
All projects →Enterprise
05An executive command centre federating five production databases read-only, an integration API bridging two systems that each held half of the same record, an operations workflow platform, and incentive administration.
Logistics
02A consignment workflow replacing paper tickets across six roles, and a bilingual high-volume operations platform built for peak days rather than average ones — weighing, documentation, approvals, exit.
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 clients who 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 an operation is entered furthest from the data centre — at a gate, in a field, on a factory floor. 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 where residency matters
- 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 operational 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 place running.
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 people 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 large-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.