Managed Production Engineering
Keep the system dependable as it changes.
Lornets provides ongoing senior technical stewardship for software that has become important enough that reliability, recoverability, security, controlled change and operational evidence cannot be left to chance.
Who is responsible for keeping this system dependable as it changes?
The commercial position
- The situation
- The software keeps changing, so the technical position needs to stay current without being rebuilt from scratch each time.
- The decision
- How do we maintain the production position as the system changes?
- What Lornets does
- Production stewardship: maintain the assurance baseline, review material changes, address Assurance Drift and provide continuing technical challenge.
- What you leave with
- Production Assurance Baseline maintained over time
- Material change and incident record
- Current assurance position and open risks
- Verified bounded interventions
- Production engineering priorities
- Technical decisions and handover record
- What may happen next
- Larger remediation or architecture work becomes a separate Production Hardening & Scale or Platform Transition & Migration engagement.
- When this is not appropriate
- You need 24/7 monitoring or a manned incident response desk, which is not included by default
- You want staff augmentation or general feature delivery
- The software is non-critical and no assurance position needs maintaining
Software does not remain production-ready by itself
A system can be in a strong production position on the day it is assessed and a materially weaker one twelve months later without anybody deciding that should happen. Product, infrastructure, dependency, team and AI changes all move the technical position.
Stewardship keeps that position understood, controlled and evidenced as the system changes, so it does not have to be reconstructed under pressure during an incident, a procurement review or a funding round.
Where this sits in the lifecycle
- Assess
- Harden
- Operate
- Reassess
Managed Production Engineering owns the Operate stage, feeding new evidence back into the assurance position established during assessment and hardening.
Where ongoing stewardship is relevant
These are representative situations. Others may also fit the remit.
- Strong product engineers, no production-assurance owner
- Feature delivery is well covered. Recovery ownership, operational risk, architecture drift, deployment safety, observability and scale planning often are not.
- A non-technical organisation that depends on important software
- The software may have been built by an agency, contractors or internal developers, but nobody independently owns the question of whether the organisation can continue to depend on it.
- A system that has just completed a hardening programme
- New changes can gradually undo the position established during that work. Stewardship keeps those improvements current.
- Recurring enterprise or investor scrutiny
- Technical evidence needs to stay current, so it does not have to be recreated whenever a new customer or investor begins technical review.
The remit is defined before the engagement begins
At onboarding, Lornets and the client agree exactly what the engagement is responsible for. Without that, the arrangement drifts into an undefined message us whenever something comes up relationship.
- System boundary and critical workflows
- Which systems, services and environments are covered, and which behaviours matter most to the organisation and its customers.
- Operating expectations
- The availability, recovery, security, data, performance and scale requirements that apply in this operating context.
- Responsibilities on both sides
- What sits with Lornets, and what remains with the client team, including routine delivery and business-risk acceptance.
- Material change and escalation thresholds
- Which changes trigger Lornets review, which proceed as routine engineering, and what requires urgent attention.
- Review and evidence cadence
- Which capabilities are periodically re-demonstrated, and how often, set proportionately to system criticality.
Production Assurance Baseline
The Production Assurance Baseline is the known technical position stewardship begins from. Lornets does not accept ongoing responsibility for a system it has not sufficiently understood. The starting position records the current readiness position, open material findings, architecture and dependencies, operating measures, recovery and security position, and the target operating context.
Onboarding assessment work is scoped and priced on its own terms.
How the baseline is established
- Recent Lornets assessment
- Where a recent Production Readiness Assessment exists, it is reused directly as the baseline.
- Credible external evidence
- Where a credible external assessment or internal evidence base exists, Lornets validates the relevant evidence and avoids duplicate work.
- Bounded onboarding assessment
- Where no credible baseline exists, a scoped onboarding assessment establishes one before ongoing responsibility begins.
Assurance Drift
Assurance Drift is the gradual divergence between the production position previously established and the real system as it changes over time.
Has anything changed that materially weakens or invalidates the position we previously established?
This is engineering judgement applied to real system change, not an automated score or a monitoring product.
Common causes
- New dependencies, integrations or data flows
- Architecture, configuration and permission changes
- New engineers and changing ownership
- Higher workload and new customers
- AI provider or behaviour changes
- Stale monitoring, documentation and recovery assumptions
The stewardship cycle
- Observe
- Review
- Prioritise
- Intervene
- Verify
- Update
- Observe
- What materially changed: deployments, incidents, dependencies, architecture, workload, AI behaviour, customer requirements and security posture.
- Review
- Whether the change affects reliability, security, recoverability, scalability, data, delivery, operations or enterprise evidence.
- Prioritise
- Immediate, near-term, planned or monitor, using the existing Lornets priority model.
- Intervene
- Bounded production-engineering work where the evidence justifies it.
- Verify
- Demonstrate whether the intervention actually worked, using verifiable evidence.
- Update
- Update the baseline and supporting evidence so the current position stays accurate.
Review the changes that can materially alter production risk
Lornets does not review every pull request or routine deployment, and does not become an approval bottleneck for ordinary engineering. Review is focused where the consequence justifies it.
- Standard changes
- Routine work managed normally by the client team without Lornets involvement.
- Material changes
- Changes that may affect an important assurance claim and should trigger Lornets review.
- High-consequence changes
- Changes requiring explicit technical assurance and verification before or after deployment.
Typically material or high consequence
- Authentication or authorisation model changes
- Database migration or major schema change
- New sensitive-data flow or external integration
- Major infrastructure or recovery architecture change
- New privileged AI agent or tool-permission change
- Platform migration
What recurring review covers
Scope follows the system. Not every area applies to every engagement, and depth is proportionate to criticality.
Lornets does not provide 24/7 monitoring, network operations centre or security operations centre capability. Expanded operational coverage would be separately scoped.
- Reliability and recovery
- Service objectives, availability and error trends, incident patterns, backup posture and periodic recovery verification. Recovery demonstrated once should not be assumed to hold indefinitely.
- Architecture drift
- The actual system compared against the currently understood architecture: new services, trust boundaries, data flows, single points of failure and deployment dependencies.
- Dependency and security posture
- Dependency changes, critical vulnerabilities, unsupported versions, secrets and configuration weaknesses, and provider changes. Tool output is evidence, not the engineering conclusion.
- Delivery performance
- Where reliable data exists, change lead time, deployment frequency, change failures and recovery from failed deployments, used only to answer whether the delivery system is becoming safer or more fragile.
- AI assurance where AI is material
- Model, provider and prompt changes, evaluation regression, tool and agent permissions, fallback behaviour, sensitive-data exposure and inference-cost trends.
- Enterprise evidence where it applies
- Architecture, data-flow, recovery, security and operational evidence kept current so the position does not have to be rebuilt for every procurement cycle.
Incident review
For material incidents, Lornets performs a blameless technical review covering what happened, the operational consequence, how it was detected, why existing controls did not prevent or contain it, how recovery behaved and what remediation is justified. The purpose is to improve system assurance, not to attribute fault.
This is not a 24/7 first-line incident response service. Technical review, root-cause analysis, engineering remediation, recovery improvement and agreed escalation support sit within the remit.
Bounded engineering intervention
The engagement includes proportionate production-engineering work. Without it, the arrangement would be advisory only.
Larger work such as a major refactor, platform migration, extensive architecture change or substantial new system design is separately scoped as Production Hardening & Scale. The engagement does not carry unlimited implementation capacity.
Typical intervention
- Monitoring and observability corrections
- Dependency remediation and configuration hardening
- Access-control hardening
- Deployment and recovery improvements
- Small reliability fixes and targeted performance work
- AI control changes
Recurring production position
The engagement maintains a current view of material changes, incidents, Assurance Drift, bounded interventions, open risks, engineering priorities and management decisions. Deeper reassessment is performed periodically where the system's criticality or rate of change warrants it.
This is a professional technical document, not a dashboard product.
- Material changes and incidents since the last review
- Assurance Drift and new risks
- Interventions completed and verification results
- Reliability, dependency and security observations
- Production engineering priorities for the next period
- Decisions required from management
Cadence is agreed as part of the stewardship remit and reflects the system and its operating context. Deeper reassessment revisits system context, critical readiness gates, key assurance claims, architecture drift, recovery evidence, security posture, capacity and significant technical debt, together with AI and enterprise evidence where they apply.
Production engineering priorities are tracked alongside this position, so reliability, security, architecture, recovery, operability, scale, technical debt and evidence gaps do not disappear behind feature delivery.
Some decisions belong to the business
Where a production risk cannot be resolved by engineering judgement alone, Lornets presents it plainly.
Management remains responsible for business-risk acceptance. Lornets does not accept business risk on the client's behalf.
- The technical issue
- What the evidence shows and why it matters.
- Available options
- The realistic engineering and operational choices.
- Consequence and cost
- What is likely to happen, and the effort involved.
- Lornets recommendation
- The position Lornets would take, and why.
- Residual risk
- What remains after the recommended action.
Work with your existing team
Stewardship is configured around the team the organisation already has, not around replacing it.
Independent oversight of external delivery partners
Where software is delivered by an external development partner, Lornets provides independent technical assurance over architecture decisions, material production changes, security controls, recovery evidence and technical claims, without replacing that partner. This is assurance oversight, not duplicate project management.
- Existing engineering team
- Lornets acts as a senior production-assurance and engineering layer alongside your engineers.
- Small technical team
- Lornets takes greater direct responsibility for defined production-engineering areas.
- Non-technical organisation
- Lornets provides independent production assurance over software operated or developed by agencies, contractors or external providers.
A quiet month does not need manufactured engineering work
If the production position is healthy, the engagement continues to earn its place through assurance work, not invented delivery.
- Material change review
- Recovery and evidence verification
- Dependency and architecture drift review
- Roadmap stewardship and capacity planning
Clean handover principle
There is no proprietary lock-in and no portal the client would lose access to.
Lornets should reduce operational dependency, not manufacture it. At the end of an engagement the client leaves with the current architecture and operational position, open risks and outstanding actions, assurance evidence and technical decisions, runbooks, the production engineering roadmap and client-controlled access.
Investment
From £6,000/month
Managed Production Engineering
Scope depends on system complexity, production criticality, review cadence and the level of direct engineering responsibility required.
Larger or more operationally demanding engagements may exceed £15,000 per month. There are no tiered packages, published hour bundles or developer seats.
The commercial unit is the stewardship remit
Managed Production Engineering is not sold as hours, developer days or seats. Scope is defined by responsibility: the agreed remit, the bounded intervention it includes, the review cadence, and the complexity and criticality of the system.
What Managed Production Engineering is not
Lornets owns a defined production-engineering and assurance remit, not the client's entire technology function.
- Not general development or staff augmentation
- Not unlimited engineering capacity
- Not a 24/7 operations or security desk by default
- Not an outsourced product or technology function
Questions we are asked
- Is this developers on retainer?
- No. Managed Production Engineering is production stewardship. It is organised around maintaining the production assurance position, reviewing material changes, addressing assurance drift and performing bounded engineering where it is justified. It does not supply general developer availability.
- Does this include 24/7 operations or incident response?
- Not by default. The standard service is not a 24/7 network operations centre or an emergency response service. Any enhanced operational coverage is agreed and scoped separately.
- What is assurance drift?
- Assurance drift is the gradual divergence between the technical position previously established and the system as it continues to change. It can arise from new dependencies, architecture changes, new AI components, changes in usage, permissions, data flows, deployment behaviour or operating conditions. The service periodically reassesses material change, so an earlier assessment is not assumed to hold indefinitely.
- What happens if a larger engineering problem is discovered?
- If the work exceeds the bounded scope of Managed Production Engineering, it becomes a separately scoped Production Hardening & Scale or Platform Transition engagement. Major programmes are not hidden inside an indefinite retainer.
- Can you work alongside our internal team?
- Yes. The service operates as a technical stewardship and challenge function alongside your existing engineering capability, or alongside an external development provider, without replacing either.
- What happens if we end the engagement?
- Lornets follows a clean handover principle so current evidence, risks, technical records and operational knowledge transition back to the client.
Related engagements
Production Readiness Assessment
The usual way a credible baseline is established before ongoing stewardship begins.
Production Hardening & Scale
A defined engineering programme with a target end state. Stewardship keeps that state true as the system changes.
Enterprise Readiness
Where the client sells to enterprise customers, stewardship keeps that technical evidence current between procurement cycles.
Who is responsible for keeping this system dependable as it changes?
If the answer is nobody in particular, that is usually the reason to talk.