Skip to main content
NELLA Labs

Services · Operate

Managed engineering for products that have to keep working.

Launch is the beginning of the expensive part. Dependencies age, certificates expire, usage patterns shift and small problems compound. Operate is a defined service with response targets, named people and reporting you can hold us to — not a retainer that quietly becomes an unused budget line.

Problems we hear

If you recognise any of these, this is the right page

  • Our product is live but nobody owns it, and issues get fixed by whoever is free.
  • We have no visibility of availability, incidents or the security position of our dependencies.
  • Our internal team is consumed by support and cannot get to the roadmap.
  • We need senior technical leadership but not a full-time CTO.
  • Our previous supplier disappeared after launch and we cannot get a straight answer.

Outcomes

What you should have at the end

A named team and a response target
Defined severities, response targets and escalation routes, with people you have actually met.
Visible service health
Availability, incidents, SLA attainment, security position and cost reported monthly and reviewed quarterly.
A maintained security position
Dependencies patched on a defined cadence, with vulnerabilities triaged rather than accumulated.
Continuous improvement
A portion of every month reserved for improvement work, so the product moves forward rather than only being defended.

Capabilities

What Operate covers

Each of these is a distinct piece of work with its own deliverables. They combine into engagements rather than being sold separately.

01

Managed engineering

A standing team that maintains and extends your product.

The problem

Products without a permanent owner decay quietly, and the cost of re-establishing context each time is paid repeatedly.

What the work involves

A named team holds continuous context on your product: they maintain it, extend it and are accountable for its health. Capacity is split explicitly between support, maintenance and improvement, so roadmap work is protected rather than perpetually deferred.

Typical deliverables

  • Named team with documented context and handover-free continuity
  • Agreed split of support, maintenance and enhancement capacity
  • Monthly service reporting
  • Quarterly roadmap and health review
02

Application and cloud support

Defined severities, response targets and a route to a person.

The problem

Support with vague expectations produces conflict during exactly the incidents where clarity matters most.

What the work involves

Severities are defined with examples so classification is not argued during an incident. Response targets are separated from resolution targets, because resolution time for a novel defect cannot be honestly guaranteed. Tickets, timers and communications are visible in your portal.

Typical deliverables

  • Documented severity definitions with worked examples
  • Response targets by severity with escalation routes
  • Ticketing with visible SLA timers and communications
  • Monthly SLA attainment reporting
03

Monitoring and incident response

Detect problems before your users report them, and learn from each one.

The problem

Alerting on infrastructure metrics rather than user-visible symptoms produces noise, and noisy alerts get ignored.

What the work involves

We define service-level objectives against user-visible behaviour and alert on those. Incidents follow a defined process with a named commander, a communications path and a blameless review afterwards. Corrective actions are tracked to completion rather than noted and forgotten.

Typical deliverables

  • SLOs with symptom-based alerting and on-call routing
  • Incident response process with defined roles
  • Incident records with root cause and corrective actions
  • Post-incident reviews with tracked follow-through
04

Security patching and dependency management

Stay current deliberately rather than in an annual panic.

The problem

Dependencies left to age turn a routine update into a high-risk migration, usually discovered when a vulnerability forces it.

What the work involves

We patch on a defined cadence with automated dependency and vulnerability scanning, triage findings by exploitability in your context rather than by score alone, and keep runtime versions current. Emergency patching for critical vulnerabilities is part of the service, not a change request.

Typical deliverables

  • Automated dependency and vulnerability scanning
  • Defined patch cadence with an emergency path for critical issues
  • Triage records with the reasoning for deferred items
  • Runtime and platform currency maintenance
05

Performance and cost optimisation

Keep the product fast and the bill proportionate as usage changes.

The problem

Performance and cost drift gradually. Nobody notices the month it becomes a problem, only the quarter it becomes expensive.

What the work involves

We monitor Core Web Vitals and backend latency against budgets and treat regressions as defects. On cost, we track spend against usage, identify waste and model the effect of changes before making them.

Typical deliverables

  • Performance budgets with monitoring and regression alerts
  • Cost tracking with attribution and anomaly alerting
  • Optimisation recommendations with modelled impact
  • Quarterly efficiency review
06

Product backlog enhancement

Reserved capacity so the product keeps moving forward.

The problem

When all capacity is consumed by support, a product stops improving and gradually stops being competitive.

What the work involves

A defined share of monthly capacity is reserved for enhancement work, prioritised by you. Unused enhancement capacity rollover is configurable and agreed in the contract rather than left ambiguous.

Typical deliverables

  • Reserved enhancement capacity with a client-controlled backlog
  • Regular prioritisation sessions
  • Enhancement delivery within the standard quality gates
  • Transparent capacity reporting
07

Fractional CTO and platform leadership

Senior technical leadership at the fraction you actually need.

The problem

Organisations needing technical judgement at board level rarely need — or can justify — a full-time executive to provide it.

What the work involves

A senior engineer or architect works with your leadership on technical strategy, architecture governance, supplier assessment, hiring and technical due diligence. They are accountable to your leadership, and they will disagree with us when we are wrong.

Typical deliverables

  • Technical strategy and roadmap input
  • Architecture governance and decision records
  • Supplier and technology assessment
  • Hiring support and technical due diligence
08

Quarterly health and roadmap reviews

A structured look at whether the product is actually healthy.

The problem

Without a scheduled review, service conversations only happen when something has gone wrong.

What the work involves

Each quarter we review availability, incidents, SLA attainment, security position, cost, performance, technical debt and roadmap progress against outcomes — and produce a written recommendation for the next quarter, including where we think you should spend less with us.

Typical deliverables

  • Quarterly service health report
  • Technical debt and risk assessment
  • Cost and performance analysis
  • Written recommendations for the next quarter

Engagement models

How we can work together

Essential — up to 20 hours per month

Monitoring, patching, support and a small enhancement allowance.

Best for: Stable products with modest change needs.

Growth — up to 50 hours per month

Everything in Essential with meaningful reserved enhancement capacity.

Best for: Products still developing after launch.

Scale — up to 100 hours per month

Substantial ongoing engineering alongside full operational cover.

Best for: Products under active development with real user volumes.

Enterprise dedicated pod

A dedicated cross-functional team with a negotiated SLA and defined escalation to leadership.

Best for: Business-critical systems with strict availability requirements.

Delivery process

How the work runs

  1. 01

    Onboard

    Knowledge transfer, access, runbooks and monitoring verification.

  2. 02

    Operate

    Monitoring, support, patching and reserved improvement work.

  3. 03

    Review

    Monthly reporting and a quarterly health and roadmap review.

  4. 04

    Grow

    Evidence-led enhancement against agreed outcomes.

Technology approach

What we build with, and why

Monitoring
Sentry, Vercel, Azure Monitor and uptime platforms, integrated into one service view.
Ticketing
Your client portal, with optional synchronisation to Jira, Linear or Azure DevOps.
Communication
Portal, email, and Teams or Slack, with escalation paths agreed in advance.
Security
Automated dependency and secret scanning with triage in your context rather than by CVSS alone.

Security and quality

Non-negotiables

  • Response targets and resolution targets are stated separately, because only one of them can be honestly guaranteed.
  • Every incident produces a blameless review with corrective actions tracked to completion.
  • Rollover of unused capacity is contractually explicit, not left to interpretation.
  • We report what actually happened, including the months we missed a target.
  • Overtime and overage require your approval before the work happens.

Investment

Starting points

Indicative bands, not quotations. What moves a project within — or outside — these ranges is scope, integration count, data quality and regulatory context.

Essential — up to 20 hours

£3,000 – £4,000 / month

Monitoring, patching, support, small enhancements.

Growth — up to 50 hours

£7,000 – £9,000 / month

Adds meaningful reserved enhancement capacity.

Scale — up to 100 hours

£13,000 – £17,000 / month

Substantial ongoing engineering with full operational cover.

Enterprise dedicated pod

from £25,000 / month

Dedicated team with a negotiated SLA.

All published figures are indicative and exclude tax, cloud and model usage, third-party licences and app-store fees. A price becomes an offer only when a person at NELLA Labs confirms it in writing.

Related

Where this shows up

NELLA Labs product

Trellis

Learning that connects families, learners and verified educators.

NELLA Labs product

Daju Verify

Onboard people and businesses with evidence you can audit.

NELLA Labs product

Domicium

The rental relationship, from listing to renewal, in one record.

Industry

Professional services

Utilisation, engagement records and knowledge that leaves with people.

Industry

Financial services and fintech

Onboarding, money movement and controls that survive an audit.

Industry

NGOs and development organisations

Beneficiary safety, donor reporting and systems that work offline.

Frequently asked questions

Will you support a product you did not build?

Yes, after an onboarding assessment. We need to understand the codebase, the infrastructure and the operational position before committing to response targets — typically two to four weeks. If the assessment finds work required before the product can be supported responsibly, we will quote that separately rather than absorb it and then miss targets.

What happens to unused hours?

Rollover is configurable and written into your contract. A common arrangement is that unused enhancement hours roll over for one month and then expire, which balances your flexibility against our ability to plan capacity. Whatever we agree is stated explicitly, and your consumption is visible in the portal throughout the month.

Do you guarantee a resolution time?

We guarantee response times and we commit to resolution targets, and we are deliberate about the difference. A response target is entirely within our control. A resolution time for a novel defect, or one rooted in a third-party service, is not — and any supplier guaranteeing it either has caveats you have not read or is going to disappoint you.

Can we move to another supplier later?

Yes, and we will help. Your documentation, runbooks, infrastructure code and access remain yours throughout, and exit assistance is a defined part of the contract rather than a negotiation held while you are trying to leave.

What counts as support versus a change request?

Support covers the product doing something other than what it was accepted as doing, plus operational work to keep it healthy. New behaviour is enhancement, drawn from your reserved capacity or quoted as a change. Borderline cases are decided in your favour and then discussed at the monthly review rather than argued at the time.

Next step

Start a operate conversation

The Project Architect will already know you came from this page, and will ask questions that fit.