- Home
- How we work
How we work
Delivery, documentation, security and support — described as we actually do them.
Institutional and enterprise buyers have procurement, data-protection and security requirements that product customers do not. This page describes how we actually work on those points, so your reviewers can check it rather than take it on trust.
Delivery method
Six steps from first conversation to a supported system.
A delivery method we use on our own products and on client work. Each step produces something you can read, test or sign off.
- 01
Discovery and requirements analysis
We meet the people who do the work, map the current process, and document roles, data, integrations and constraints. You get a written requirements document to review.
- 02
Solution architecture and proposal
A proposed architecture, the scope in plain language with what is explicitly out, milestones with acceptance criteria, and a fixed price per scope. Timelines are written here, not promised on the first call.
- 03
UI/UX design and prototyping
Clickable prototypes of the key screens, tested with real users where possible — including the least experienced ones — before engineering starts.
- 04
Development and quality assurance
Build in short iterations with weekly demos on staging, automated tests, code review and security checks. You can test each milestone against its acceptance checklist.
- 05
Deployment and implementation
Data migration with dry runs, deployment to your infrastructure or ours, parallel running where needed, and a rehearsed cut-over with a rollback path.
- 06
Training, maintenance and ongoing support
Training for administrators and users, documentation and runbooks, then a support arrangement with agreed response times and a backlog of improvements we prioritize with you.
How you stay informed
You are never guessing where the project is. Every week you get a short written update and a demo on a staging environment you can open on your phone; every milestone has an acceptance checklist agreed in advance; and you talk to the engineers doing the work, not an account manager.
For procurement, IT and data-protection reviewers
Nine things your reviewers will ask about, answered plainly.
Requirements documentation and project scope
Discovery produces a written requirements document and a proposal that states the scope, what is explicitly out, milestones, acceptance criteria and price. Changes to scope are re-quoted in writing before work proceeds.
Role-based access control
Every system we build has roles, permissions and an administration area from the first version. Access can be limited by organizational unit, location and field, and administrators can review who has access to what.
Data privacy and appropriate data handling
We collect only the data a process needs, restrict sensitive fields to the roles that require them, record consent where personal data is involved, and define retention and deletion rules with you. We align with GDPR-style practice and Ethiopia's Personal Data Protection Proclamation.
Secure development practices
Encrypted connections everywhere, secrets kept out of code and documents, least-privilege credentials, regular updates, code review, and verified, duplicate-safe handling of anything that moves money. Vulnerability reports go to a published security contact.
Backups and recovery planning
Automated database backups with agreed retention, stored separately from the production system, and a restore procedure that is documented and rehearsed before go-live rather than assumed to work.
Deployment and maintenance
Separate development, staging and production environments; automated deployments with a change log and rollback; monitoring and alerting; and scheduled patching. Systems deploy to your infrastructure or ours, as policy requires.
Technical documentation
Architecture overview, data model, API documentation, environment and runbook documentation, delivered with the system and kept current during support.
User training and handover
Training sessions for administrators and user groups, printed or recorded guides, and a handover package so your team — or another vendor — can operate the system without us.
Ongoing support arrangements
A support contract with response times by severity, maintenance windows, a reviewed backlog of improvements and periodic service reviews covering usage, cost and risk.
Your requirements
Privacy, data residency, security and procurement requirements are design inputs.
Where your organization has specific privacy, data-residency, security or procurement requirements — in-country hosting, a particular review process, source-code escrow, a tender format — tell us during discovery. We design the solution and the engagement around them, and we will say plainly if there is a requirement we cannot meet.
What we do not claim
We do not hold formal security certifications, and we do not publish availability guarantees for environments we do not control. We say so here so that nothing on this site has to be taken back during due diligence.
Read next
- Security — what is live, what is designed, and a finding from our own audit
- Technology — architecture, stack, principles and platform status
- Pricing — engagement models and what a written quote contains
- Compliance — for gaming platforms: licensing, KYC, responsible gambling
Start a conversation
Bring your own reviewer.
We are happy to walk a technical, security or procurement reviewer through any of the above on a call, and to answer a questionnaire in writing.