About Onyxsis
Engineering the Missing Capability Around Existing Systems
We begin by understanding the environment and its limitations, then recommend an appropriate technical approach.
Onyxsis was founded in 2014 on a practical principle: technology should reduce manual effort, not add to it.
Many organisations depend on systems that have accumulated manual workarounds, undocumented logic, and uncertain integrations over time. Knowledge can become concentrated in a few people, small changes carry disproportionate risk, and teams spend too much time maintaining the status quo.
We work within that reality. After understanding the systems, data, infrastructure, dependencies, and boundaries already in place, we build the integration, platform extension, operational tooling, reporting, automation, or infrastructure change that is missing. The result should be understandable, diagnosable and supportable, without adding scope or complexity the requirement does not justify.
When Existing Systems Leave an Important Gap
We typically work with established systems whose dependencies mean that failures or changes can have real operational consequences.
A platform has grown too complex or risky to change confidently
Integrations and workarounds have accumulated without enough documentation or shared understanding
Information about system behaviour is limited, slow to obtain, or unreliable
Previous changes have left important system behaviour or ownership unclear
The system works, but only because a small number of people understand its undocumented behaviour
This usually points to: business-critical workflows, data flows, and integrations where downtime, errors, or manual effort affect cost, service continuity, or reputation. The aim is to make the environment clearer, supportable, and safer to operate.
Where Our Work Fits
We work on complex internal operations where the requirement sits between applications, data, infrastructure, vendor platforms, and the people responsible for running them.
Capabilities We Bring
- Systems and API integration and existing and legacy system engineering
- Bespoke operational systems and tooling and workflow and process automation
- Data integration and operational reporting
- Technical investigation and operational diagnostics, plus infrastructure architecture and migration
- Specialist communications and contact-centre work, including voice and protocol engineering, with SLA-based technical support for defined systems where required
Work We Are Not Set Up For
- Marketing websites
- Visual redesigns
- Interface-led or aesthetic-first projects
Our focus is on the interfaces, tooling, data flows, and workflows around systems that already matter. Technical support is available for defined systems, but we do not provide general managed IT services.
Designed for Operation, Not Presentation
A system has to remain understandable and supportable after delivery. Our experience operating and evolving systems over time shapes the decisions we make during design.
Our systems are:
- Grounded in the actual requirement, rather than a predetermined architecture
- Built with interfaces defined around the work they must support, without unnecessary additions
- Designed for failure modes and production edge cases
- Built to be operated, diagnosed, and maintained
We do not replace enterprise platforms without a clear reason. Where appropriate, we integrate with them, extend them, and make the required data or workflow usable. Our communications and contact-centre work is a specialist application of this broader approach. The goal is a clearer, more supportable environment, with less manual effort and less dependence on undocumented individual knowledge.
A Practical Preference for Open Source
We favour open-source technology where it is appropriate for the requirement.
It can reduce unnecessary lock-in, make the system easier to inspect, and give the organisation more control over how its software evolves.
This is a practical preference, not a rule. We choose tools according to the environment, support model, and technical boundaries, while favouring transparency, auditability, and control retained by the organisation.
The Existing Environment Determines the Approach
We do not start with a standard product or predetermined architecture. Each engagement is shaped around:
Your Systems
We start with the environment that is actually in place.
Your Risk Profile
Trade-offs are explicit and documented.
What Cannot Change
We identify the conditions the solution must work within.
How the Service Runs
Real-world edge cases are considered explicitly.
What This Means in Practice
We investigate before designing, challenge assumptions where useful, and avoid simplifying away dependencies that matter in operation.
We make the relevant risks and trade-offs explicit before committing to an implementation.
The Engineers Responsible Stay Close to the Work
We keep communication direct, decisions visible, and responsibility clear throughout the engagement.
Hands-On Throughout
The engineers responsible remain involved from investigation through delivery and support.
Straight Answers
Visible trade-offs, clear decisions, and no black boxes.
Documented and Explainable
Decisions are recorded so the system stays understandable over time.
Visible Progress
Clear communication about current status, next steps, and the reasons behind them.
Support After Go-Live
Where ongoing support is part of the requirement, the same system context carries forward.
Follow-Through
Agreed actions are owned, communicated, and carried through to completion.
We take care over technical decisions, communicate their implications clearly, and follow through on agreed responsibilities. The working relationship should be as dependable as the system being delivered.
Success Is Measured in Day-to-Day Operation
A system is successful when, in practice:
- Teams trust the system
- The information teams need is available when decisions are made
- Unnecessary manual work is reduced
- Incidents can be diagnosed and resolved effectively
- The platform can grow without becoming unreliable
In short: when the system supports the operation without demanding unnecessary attention.
Discuss What Needs to Change
If an important process is being limited by existing systems, tell us what needs to work differently, what cannot easily change, and where the current approach falls short.
