How We Build · The Standard
We build systems that carry regulated and operationally critical work.
Ordering platforms, operational systems and integrations for South African businesses where being wrong is expensive — where customer data is protected by law, where auditors ask how a decision was recorded, and where an outage is not an inconvenience.
We are small and engineering-led. You work with the engineer who designs and builds your system, with independent verification at the decisions that matter.
Our method is published below. Assess it directly.
How We Work
We work in gates.
Most software projects fail commercially before they fail technically. A price is agreed before anyone knows what is being built, scope grows without being priced, and the relationship ends in a dispute about what was promised.
Each gate is separately proposed, priced and decided. Committing to one creates no obligation to the next.
Scope confirmation
We agree what is being built and what is not, name the person on your side who makes decisions, and record every open question. Ends with a signed scope.
Discovery and proof
We test the assumptions the project depends on rather than assuming them: whether the integration behaves as documented, whether the platform can enforce the access rules you need, what your regulatory position actually requires. Ends with a costed scope for the build. This is where projects are saved or quietly doomed, and it is why we do not quote a build price before it.
Design freeze
Data model, system behaviour, integration contracts, threat model. Ends with a fixed-price build quotation. Errors here become migrations later, so we slow down deliberately.
Build
Working software in fortnightly increments, demonstrated rather than reported. Automated testing throughout, not at the end.
Testing and readiness
Your team validates real workflows. An independent security firm tests the system. Findings are remediated and re-verified.
Pilot and handover
A controlled launch, measured, stabilised. Documentation and access handed over in full.
What this costs you: more time in discovery and design than a firm that starts building immediately. What it buys you: a price based on measurement rather than optimism, and the ability to stop at any gate with everything produced so far in your possession.
How We Price
You pay for measurement, not optimism.
Discovery first, at a fixed fee, credited against the build.
We quote what we have measured, not what we have guessed. If you proceed, the discovery fee comes off the build price.
Fixed scope, milestone payments.
Payments are tied to working software you have seen, not to time elapsed. No open-ended billing.
Written change control.
Anything outside the agreed scope is logged, assessed, quoted and approved before work begins. Nothing is refused — everything is priced. This protects your budget more than it protects our margin.
We will tell you when you are overspending.
If a feature costs more than it will return, we say so. We would rather lose the line item than build something that makes the project a bad investment.
On negotiation.
Our commercial terms are open to discussion, and we would rather have that conversation than have you weigh a number in silence. Where we will not move is quality. Work priced below what it costs to do properly produces a supplier who is slow to answer in year two, and that costs you more than the saving. We adjust what is built, not the standard it is built to.
Your Protections
What holds when things get difficult.
You own the code.
Repository access from the first commit. Full handover at every phase close, whether or not you continue with us.
You keep everything you pay for.
If you stop after discovery, you keep the discovery report, the architecture, the specifications and every document produced. There is no outcome where you have paid and hold nothing.
No lock-in by design.
Every proprietary dependency we introduce carries a documented exit path. We would rather you stay because the service is good than because leaving is difficult.
Your data stays in South Africa.
Systems are hosted in-region. Where a supplier processes your data, there is a written agreement and you can see who they are.
Independent verification.
The decisions that are expensive to get wrong are reviewed by a Chief Information Security Officer who does not report to us on delivery. Security is tested by a firm we did not choose for convenience.
Security & Compliance
Engineered in, not written after launch.
POPIA by design.
Lawful basis documented, data inventory maintained, written agreements with every processor, breach procedure defined and tested. Not a policy page written after launch.
Data residency.
We host in the Cape Town region so that your customers' personal information does not leave South Africa. The trade-off, stated plainly: there is no second South African region to fail over to. We design for availability-zone redundancy and tested restores, and we ask you to accept region-level failure as a residual risk in writing.
Access control that holds.
Systems are built deny-by-default: nothing is visible without an explicit current entitlement, enforced at the data layer rather than in the interface. Cross-customer access tests run on every code change and fail the build if they do not pass.
Security design to a standard.
Our architecture follows ISO/IEC 19249 principles — domain separation, least privilege, attack surface minimisation, centralised validation, failing closed. We can show you how each applies to your system.
Accessibility.
Built and tested to WCAG 2.1 AA. Full keyboard operation, screen reader compatibility, verified contrast. If you sell to the public sector, you will be asked for this.
What we do not claim.
We are not ISO 27001 or ISO 13485 certified. We apply the relevant principles, we have delivered into environments pursuing certification, and we will tell you plainly where our practice stops and a certified provider is required.
Due Diligence
Questions you should ask any firm.
Including us. If a supplier cannot answer these clearly, that is information.
Who owns the code when we are finished?
You do. Ask for it in writing, and ask for repository access on day one rather than at handover.
What happens if your lead engineer leaves, or is unavailable?
Ours is a real question and we answer it directly: a named senior advisor verifies the critical decisions, a second engineer is contracted before the build phase, and the system is documented so that a competent engineer can continue from the files alone. Be sceptical of any small firm that treats this question as unimportant.
Where will our data physically be stored, and who else can access it?
Ask for the list of suppliers who will process your data, and the agreements with them. Vagueness here is a compliance problem you will inherit.
What is your uptime commitment, and what does it exclude?
A percentage without a definition means nothing. Ask what is measured, over what period, and what happens when it is missed.
What happens when it breaks outside business hours?
Ask what is actually staffed. A support tier that implies overnight cover without anyone on call is a promise that fails on the night it matters.
How would we leave you?
Ask for the exit path before you sign, not when the relationship is under strain.
How do you know the system is secure?
"We follow best practice" is not an answer. Ask what is tested, how often, by whom, and whether you can see the results.
What could go wrong with this project?
The most useful question you can ask. A supplier who cannot name real risks has either not thought about it or is not being straight with you.
Boundaries
What we do not do.
We do not build quality management systems.
Validated QMS is a regulated product category with established vendors, and building one would add risk without adding value. We integrate with yours.
We do not perform our own penetration testing on systems we build.
A test scoped by the person who built the system inherits that person's blind spots. We arrange an independent firm and act on what they find.
We do not author regulated product content.
Claims, indications and labelling remain with your responsible person. We build the system that carries them.
We do not take on work we cannot staff properly.
If a project needs capability we do not have, we will say so and, where we can, tell you who does.
About
Who you actually deal with.
ASi Imperium Technologies is the technology division of the HyperMartX Group, based in Gauteng.
BEngTech Mechatronic Engineering, currently completing Honours. Siemens certified. Active practitioner in cybersecurity. Designs and builds the systems we deliver.
A serving Chief Information Security Officer and Chief Technology Officer, providing independent verification at defined decision points: architecture proofs, data model and threat model review, authorisation implementation, and security testing scope.
We are deliberately small. You deal with the people who do the work. Where a project needs capability beyond us, we say so rather than learning at your expense.
HyperMartX (Pty) Ltd · Reg 2025/218955/07 · Gauteng, South Africa · +27 75 347 3367 · hello@asitechnologies.co.za