Support and operations

We can run and maintain what we build: monitoring, incident response, security updates, and changes as your business and its partners change. Support is agreed in writing, with response targets, escalation contacts and regular reporting.

Link to this question

AI systems need ongoing attention: data changes, models are updated and new cases appear. We can monitor quality and cost, review flagged cases, update prompts or models, and rerun the evaluation set before every change. This can be part of a support agreement or handed to your own team with the runbook and training.

Read more: AI developmentLink to this question

Monitoring shows it before the business feels it. We track the input data and the model’s results against what it saw in training, and alert when they shift. Your team then sees the evidence and decides whether to retrain, adjust thresholds or fall back to rules. Retraining runs through the same tested pipeline as the original model.

Read more: Machine learningLink to this question

Either your team or ours. We hand over documentation, tests, monitoring and a runbook, and train your engineers if they will run it. If you prefer, we monitor loads and quality, fix failures, handle source system changes and add new subject areas under a support agreement.

Read more: Data engineering and analyticsLink to this question

You choose. We can support and extend the system under an agreement that sets out response times, monitoring and a budget for changes, or we hand it over to your team with the code, the documentation and a period of overlap. Many clients start with our support and move the work in-house over time.

Read more: Custom software developmentLink to this question

Apple and Google release new operating system versions every year, and store rules change. Libraries need security updates. We test the app against each new release, fix what changes and keep its dependencies current, alongside your own roadmap of features. This usually runs under a support agreement or within a dedicated team.

Read more: Mobile appsLink to this question

Yes. Under a support agreement we watch the alerts, respond to incidents within the response times we agree with you, apply security patches and keep the platform’s tools current. Every significant incident gets a written review of its cause and of the change that stops it happening again.

Read more: Cloud and DevOpsLink to this question

We treat an unreliable test as a defect. It is set aside so it cannot block releases, its cause is found and fixed, and it comes back. Common causes are shared test data, timing assumptions and unstable environments. We track test stability over time, so the suite stays one your team can trust.

Read more: QA and test automationLink to this question

We build on the interfaces the vendor publishes and supports, not on database tables or screens, so most upgrades leave the integration untouched. Before an upgrade we review the vendor’s release notes against each interface, run the test suite on the upgraded test system, and fix anything that changed before production moves.

Read more: ERP integrationLink to this question

Banks announce format changes in advance, as many did when moving from SWIFT MT to ISO 20022 messages. We follow those notices for the banks we connect, assess the impact, and schedule the change and its tests with the bank before its deadline. This can be part of a support agreement.

Read more: Bank integrationLink to this question

For the APIs you publish, we version them, keep old versions running for an agreed period and tell consumers what changes. For the APIs you call, we track each partner’s deprecation notices, test new versions in their sandbox and move before the old version is switched off. Contract tests catch an unannounced change before it reaches production.

Read more: Third-party and API integrationLink to this question

You choose. We can hand the system over to your own team with documentation and walkthroughs, or keep supporting and developing it under a support agreement or a dedicated team. We agree this before the project ends, so there is no gap.

Read more: Project-based deliveryLink to this question

Yes, if you want us to. The same architects can stay on to guide delivery, and we can provide a dedicated team, augment your own engineers or deliver a defined project. There is no obligation: the roadmap is yours to deliver with any supplier or your own team.

Read more: Technology and architecture consultingLink to this question

We can monitor and support it under a support agreement, or hand it over to your team with documentation, alerts and a runbook. Either way, a failed message lands in a queue with its reason, so it can be fixed and replayed rather than lost.

Read more: Retail and POSLink to this question

Yes, under a support agreement. We watch message flows and partner connections, alert on failures and backlogs, and fix or replay failed messages. If you prefer to run it yourselves, we hand over to your team with the dashboards and runbooks.

Read more: Logistics and distributionLink to this question

That is agreed before go-live. Usually your store operations or finance team handles business errors, such as an unknown item, from a review list, and the technical team handles faults in the flow itself. We can provide that technical support as part of an ongoing agreement, with the runbook shared with your team.

Read more: POS and ERPLink to this question

The rest of the flows keep running. Messages for that partner are retried and then queued, the support team is alerted, and nothing is lost. When the partner recovers, queued messages are replayed in order. The dashboard shows which partner is affected and how many messages are waiting.

Read more: ERP and third partiesLink to this question