Quality & After-sales
Prices move with the market. Quality standards do not. We put engineering standards in the contract — scope reviewed first, every stage inspectable, full source-code handover, and someone accountable after launch. The real cost of a system usually shows up after it goes live.
Scope: 99% is the share of milestones accepted on schedule over the trailing 12 months; 50/30/20 is the contractual stage-payment split; 100% means source code and intellectual property transfer to you in full at handover — no vendor lock-in.
Launch is not the finish line — we watch the dashboards with you.
Five hard standards, written down before we start
Quality is not something we talk about; it is something you can check. These five go into the requirement document and the acceptance checklist, and we walk through them one by one at handover.
Code standards & review
One style, one naming convention, one commit rule. Critical modules only merge after peer review, and the review comments stay in the repository for later reference.
Security baseline
Least privilege and masked sensitive data. Dependencies are scanned for known vulnerabilities, upgrades are logged, and every public endpoint is authenticated and validated.
Performance targets
Response-time and concurrency targets are agreed before coding. We load-test against realistic data volumes, and anything over target is optimised before acceptance.
Maintainability
Folder structure, configuration, dependencies and documentation travel with the code, so the system is not understandable only to the engineer who wrote it.
Automated regression
Core business flows become repeatable test cases. Every release runs the suite, and any release can be rolled back.
An example delivery pipeline: every stage produces something you can inspect (AI application pipeline).
Split into milestones, accepted against a checklist
Every milestone has named deliverables, acceptance criteria and a time window. If it does not pass, we rework and retest — the schedule moves by the actual rework time, and later milestones are not squeezed to compensate.
Payment rhythm: each instalment is paid only after the matching stage is accepted
The business flow diagram ships with the project (example: a multi-store ordering mini-app) — we draw the process before we build it, and the same diagram becomes the shared language for acceptance and troubleshooting.
If acceptance does not pass
If it fails, it gets written down
When acceptance does not pass we issue a written list of issues with reproduction steps and our diagnosis, each mapped back to a requirement item.
Rework is not extra billing
Problems on our side are fixed at no additional charge and cost you no time. The schedule shifts by the actual rework days, and later milestones are not squeezed.
Retest before we move on
A milestone does not advance until the retest passes. Acceptance records are filed on both sides and stay available for reference.
One year of complimentary maintenance, in writing
Launch is not the end of delivery. The first year of maintenance is part of the contract, covers the six items below, and carries no extra fee.
Incidents during maintenance turn into documentation and shared knowledge, so the same trap is not sprung twice.
When something breaks, this is how we commit to respond
Incident handling comes down to two questions: how fast we respond, and whether the same fault comes back. Both are written into the contract.
A response means work has started
A met response time means an engineer has picked the issue up and produced a plan — not an automatic "seen" receipt.
Plan first, then fix
We assess the impact and give an expected fix time first. Anything needing a code change ships as a small, revertible release.
Every incident gets a post-mortem
A short write-up: cause, blast radius, the fix applied, and the action taken to prevent a repeat.
Changes are never silent
Fix releases, data corrections and configuration changes are always communicated to you.
An example incident loop: ticket, diagnosis, resolution, capture.
Severity levels and our response commitment
These are contractual response commitments during working hours — not a historical failure-rate statistic. P1 outside working hours goes through the agreed on-call channel. Final wording follows the contract annex.
On go-live day, you receive a complete set of assets
Once the last milestone is accepted, the system goes live and the source code, documentation, accounts and deployment notes come with it — the system belongs to you, and to whoever you choose to run it next.
Source code and IP
The full repository, dependency notes and intellectual property transfer with the final payment. There is no vendor lock-in.
Documentation
Requirement notes, interface documentation, deployment and operations manuals, and the acceptance record — archived and handed over together.
Accounts and deployment
Cloud resources, domains and third-party accounts (payments and the like) move into your name, along with deployment scripts and configuration.
Training and handover
Operator training before launch plus a handover session. The engineers answer questions until your own team can run the system.
A handover example: a mini-app project runs independently once delivered, with no dependency on our environment.
Renewal and additional scope
Need a quality and after-sales commitment list written for your project?