Skip to main content
Kerah

Kerah Systems

One accountable path from operational problem to running system.

Kerah combines discovery, design, engineering, integration and ongoing improvement around one goal: a system the organization can understand, operate and evolve.

Request a consultationHow we work

Where we usually come in

Most engagements start from a recognisable symptom rather than a specification.

  • A process that works on paper and falls apart at scale
  • Data that is accurate in four systems and reconciled in none
  • A system that only one person genuinely understands
  • An approval chain nobody can audit after the fact
  • A platform that was built once and has been frozen since
  • A pilot that impressed everyone and stalled before production

Eight capability families

Most engagements touch two or three. Each page below states what the service delivers and, just as importantly, where it stops.

Discovery and Architecture

The problem. The problem is understood in the organization, but nobody can yet say what should be built, in what order, under which permissions, or what it will cost to run.

What changes. A documented blueprint with a target architecture, a permission and data-role map, a phased roadmap and a scope you can approve, price or decline on evidence.

Representative deliverables

  • Current process and pain-point map
  • Target architecture
  • Phased delivery roadmap
  • Scope, exclusions and estimate

Discovery and Architecture

Enterprise Systems

The problem. A core process runs across spreadsheets, inboxes and undocumented judgement, and it cannot be audited, delegated or scaled.

What changes. One operational system where work is assigned, decisions are recorded, permissions are explicit and reporting comes from the same data people work in.

Representative deliverables

  • Operations, customer and partner portals
  • Workflow, approvals and escalation
  • Roles, permissions and audit trails
  • Operational reporting

Enterprise Systems

Digital Product Engineering

The problem. A product has to work for customers or staff in real conditions — an older device, a poor connection, two languages, and rules that cannot be broken.

What changes. A designed, accessible product with a secure back end, built around the tasks people actually perform and measured after release.

Representative deliverables

  • Product definition and user journeys
  • Design system and interface design
  • Websites, web and mobile applications
  • Backend services and APIs

Digital Product Engineering

Cloud, Data and Integrations

The problem. The same information exists in several systems, none of them agree, and someone's job is to reconcile them by hand.

What changes. Defined interfaces, a documented data model and monitored flows, so information moves once and reporting can be trusted.

Representative deliverables

  • API and integration design
  • Data mapping and migration
  • Cloud foundations and deployment
  • Monitoring and reconciliation reporting

Cloud, Data and Integrations

AI and Intelligent Automation

The problem. High-volume repetitive judgement work, and a low tolerance for a decision nobody can explain afterwards.

What changes. A bounded use case with defined success criteria, evaluation against representative cases, human review where it matters, and a fallback when the model is unavailable.

Representative deliverables

  • Bounded use case and success criteria
  • Evaluation set and results
  • Human review and oversight design
  • Fallback and monitoring design

AI and Intelligent Automation

Managed Evolution

The problem. A live system that still runs, quietly ages, and has an improvement list going into an inbox nobody owns.

What changes. A defined support and release model with security maintenance, an owned backlog and a roadmap reviewed on a set cadence.

Representative deliverables

  • Support and incident workflow
  • Release management
  • Security and dependency maintenance
  • Prioritised improvement backlog

Managed Evolution

Security and Privacy Engineering

The problem. Security and privacy are raised late, as a questionnaire to be answered, by which point the access model, the data flows and the retention behaviour are already fixed by the architecture.

What changes. A system whose access model, data inventory, encryption, logging and deletion behaviour were designed together — and the documentation an assessor asks for, produced as delivery output rather than reconstructed afterwards.

Representative deliverables

  • Threat model and data-flow documentation
  • Access and permission model
  • Data inventory and retention schedule
  • Incident response and escalation plan

Security and Privacy Engineering

Quality, Testing and Accessibility

The problem. Arabic is added as a translation pass at the end, accessibility is asserted rather than tested, and the first real load the system sees is on the day it goes live.

What changes. A system tested in both languages by people who read both, measured against WCAG 2.2 AA, and exercised under realistic load and failure conditions before launch rather than after it.

Representative deliverables

  • Automated test suites over the critical paths
  • Arabic and English quality assurance
  • Accessibility test results and remediation
  • Performance and resilience test results

Quality, Testing and Accessibility

Not sure where the problem starts?

That is a normal place to begin, and it is what discovery is for. A discovery phase maps the process, the system landscape, the data and the constraints, and produces a practical first phase you can approve, price or decline.

Kerah does not publish fixed prices for enterprise work. A number set before the problem is understood is either padded or wrong. Discovery is priced as its own phase, and implementation is priced against a blueprint you have approved.

About discovery and architecture

Describe the operational problem.

You do not need a specification. Tell us what is not working, who it affects and what it costs.

Request a consultationSee reference patterns