Why pay for an assessment before paying engineers to fix things?

Because the expensive mistake can be doing too little or doing too much. The assessment establishes what materially constrains the next operating context before the organisation commits to a larger engineering programme, so remediation starts from evidence.

What if the assessment shows that nothing major needs changing?

That is a valid outcome. Where the evidence supports the existing system for the stated operating context, the recommendation may be to keep it, and the Dossier records the residual risks, evidence gaps and trigger points that should cause reassessment.

Does AI-assisted or vibe-coded software automatically need an assessment?

No. How the software was created may influence what evidence we examine. It does not determine the conclusion. Lornets assesses the actual system and what the organisation now requires from it.

Why can't our existing CTO or engineering team assess this?

They may be perfectly capable of it. Lornets is useful when the organisation needs a structured technical challenge around a consequential decision, particularly where management, customers, investors or significant engineering spend depend on the conclusion. We work alongside the existing team.

Is Production Assurance just a security audit?

No. Security & Access Control is one Production Assurance domain. The assessment also examines Architecture & Maintainability, Reliability & Recoverability, Performance & Scalability, Data & Privacy Engineering, Delivery & Change Control, and Observability & Operations. Specialist penetration testing or certification may still be required separately.

What access do you need?

Only what the agreed assessment requires, on a minimum access and maximum evidence principle: read-only and least-privilege access where practical, client-controlled credentials, and no unnecessary extraction of production data. Some conclusions cannot be substantiated without appropriate technical access, and we say so.

Can Lornets implement the recommendations?

Yes, where engineering is justified. Assessment and implementation are deliberately separated. Where changes are required, Lornets can deliver Production Hardening & Scale, undertake Platform Transition work or collaborate with your existing engineering team.

Production Readiness Assessment

What does your software need to withstand next?

A scoped, evidence-based technical assessment answering one commercial question: can the organisation safely depend on this software for what it needs to do next?

Discuss a Production Readiness Assessment Explore the Lornets methodology

From £5,000 · typically 7 to 10 business days from evidence availability

The commercial position

The situation: Software that already works has become commercially or operationally important, and a larger engineering, commercial or operational commitment is approaching.
The decision: Can the organisation depend on this software for what it needs to do next?
What Lornets does: We establish what the system must withstand, gather technical evidence, measure behaviour under real conditions and resolve each material finding to Keep, Refactor or Replace with a stated verification criterion.
What you leave with: Readiness Position for the defined scope and operating context
Assurance Confidence describing how strongly the evidence supports it
Critical Gates that materially constrain the next stage
Prioritised findings with Keep, Refactor or Replace decisions
Verification criteria for any recommended work
What may happen next: Engineering may follow where the evidence justifies it. Establishing that the current system is fit for the next operating context is an equally valid conclusion.
When this is not appropriate: The product is still being validated and nothing depends on it commercially
You need developers to build a first MVP
You require a formal penetration test, audit opinion or certification

When Production Readiness is the right starting point

The assessment establishes what the software can actually support before larger commitments are made. It is commissioned when the consequences of technical weakness change, before a failure forces the question.

Assess first. Keep what works. Change only what the evidence justifies.

Under-engineering: Continuing to depend on software that cannot withstand what the business now asks of it, and discovering the limit through an incident, a lost deal or a failed diligence process.
Over-engineering: Committing to a rebuild, migration or architecture programme the evidence does not justify, spending capital and calendar time on work the business did not need.

Typical triggers

A working product is about to carry real production dependency.
Operational dependency has increased faster than the engineering foundation.
Usage is growing faster than the system was designed for.
Reliability, performance or incident frequency has become a management concern.
A migration, rebuild or replatform is being considered without independent evidence.

What the assessment establishes

The assessment determines whether the existing system is appropriate for a clearly defined operating context, and what, if anything, materially needs to change.

The conclusion is expressed as a Readiness Position, supported by Assurance Confidence, Critical Readiness Gates and a Keep, Refactor or Replace decision for each material finding.

Based on the operating context, scope, evidence and assumptions defined in this assessment, Lornets considers the system Ready, Conditionally Ready or Not Demonstrated Ready for the stated use. The position remains bounded by the agreed scope, evidence, assumptions and operating context. It is not a certification and not a guarantee of future system behaviour.

See the Production Assurance Framework

Readiness Position

Ready: The evidence supports operation in the stated context without identified material blockers.
Conditionally Ready: The system can reasonably support the stated context subject to clearly identified remediation, controls or operating conditions.
Not Demonstrated Ready: Available evidence or material technical findings do not currently support a positive readiness conclusion for the stated operating context.

Every conclusion is tied to a defined boundary.

Before assessment begins, Lornets and the client agree an Assessment Scope Statement covering the system boundary, the operating context the software must withstand, the evidence and access available, the depth of verification justified by risk, and anything explicitly excluded.

Conclusions apply to the stated operating context, the defined scope, the evidence reviewed and the assumptions recorded. Where something cannot be demonstrated, the position is recorded as Not Demonstrated rather than treated as either success or failure.

How we reach the conclusion

The assessment combines system context, documentary and technical evidence, risk-led verification and senior engineering judgement. Assessment depth follows the consequence of the claim and the strength of the available evidence.

Tooling contributes evidence. Severity, readiness and engineering direction are determined by engineers, and material conclusions receive senior technical review before delivery.

Assurance Confidence records how strongly each material conclusion is supported by the evidence actually available.

Explore the Production Assurance Methodology

How the engagement runs

Typically 7 to 10 business days from evidence availability.

01
Scope & context
Define the system boundary and what the software needs to withstand.
02
Evidence & system mapping
Establish architecture, dependencies and the existing evidence base.
03
Assurance review
Assess the applicable Production Assurance domains and identify material hypotheses.
04
Risk-led verification
Test the areas where direct evidence matters.
05
Position & handover
Readiness Position, engineering decisions, verification criteria and action priorities.

The exact sequence varies with system scope, evidence availability and stakeholder access.

Keep, Refactor or Replace

Every material finding resolves to one of three engineering decisions, with a stated priority and a verification criterion describing the evidence that will later demonstrate the issue has been resolved.

Keep: The existing implementation remains appropriate for the stated operating context.
Refactor: The foundation remains viable and proportionate improvement is required, through configuration, hardening, testing, instrumentation, restructuring or targeted redesign.
Replace: Evidence demonstrates a material constraint that cannot reasonably be addressed through proportionate improvement.

Sometimes the right answer is to keep it.

A valid Production Readiness Assessment may conclude that the existing foundation is appropriate and only limited remediation is justified.

The purpose is to establish the technical position. The more expensive and disruptive the recommendation, the stronger the evidence required to justify it.

What you receive

The engagement concludes with a Production Assurance Dossier.

Executive Readiness Position: The management-level conclusion.
Scope & System Context: What was assessed and what the system must withstand.
Material Findings & Critical Gates: Prioritised findings, including anything preventing an unrestricted positive conclusion.
Evidence & Verification Record: Traceability between material claims, the supporting evidence and Assurance Confidence.
Keep / Refactor / Replace Decisions: Clear technical direction for each material finding.
Prioritised Engineering Roadmap: What should be addressed, in what order, and how completion will be demonstrated.

These are delivered through the Production Assurance Dossier, with technical appendices such as architecture views, measurements, standards crosswalks or AI assurance material included where relevant to the assessed system.

Delivery

Executive readout

Founders, executives and management

The management-level readiness position, the critical gates and the priorities that follow from them.

Technical handover

CTOs, technical leads and engineers

Evidence, findings, engineering decisions and the verification criteria for material remediation.

Session format and length are agreed with the client.

Boundaries

Deeper assurance work can be scoped separately, including extended AI assurance, application security verification, controlled recovery exercises and structured performance and capacity validation. The standard assessment remains bounded, and accredited testing or certification requires an appropriate specialist provider.

Formal certification or audit opinion
Formal penetration testing or red teaming
Legal or regulatory opinions
Unlimited or exhaustive system and source review
Destructive or high-risk testing unless specifically scoped

Investment

From £5,000

Typically 7 to 10 business days from evidence availability.

Final scope depends on system complexity, the number of applications and services, available evidence, operating context and the depth of verification required.

Focused systems with a single application and clear evidence are generally at the lower end.
Complex production environments require broader scope and more verification effort.
Multi-system estates, or engagements requiring unusually deep verification, are scoped separately.

What happens after the assessment

The assessment establishes the technical position and the recommended actions. Clients may implement the roadmap internally, with another engineering partner, or through Lornets Production Hardening & Scale. Where Lornets continues, findings become defined engineering outcomes with acceptance and verification criteria.

Clients are not required to use Lornets for remediation. That independence is deliberate.

Production Hardening & Scale

Questions we are asked

Why pay for an assessment before paying engineers to fix things?: Because the expensive mistake can be doing too little or doing too much. The assessment establishes what materially constrains the next operating context before the organisation commits to a larger engineering programme, so remediation starts from evidence.
What if the assessment shows that nothing major needs changing?: That is a valid outcome. Where the evidence supports the existing system for the stated operating context, the recommendation may be to keep it, and the Dossier records the residual risks, evidence gaps and trigger points that should cause reassessment.
Does AI-assisted or vibe-coded software automatically need an assessment?: No. How the software was created may influence what evidence we examine. It does not determine the conclusion. Lornets assesses the actual system and what the organisation now requires from it.
Why can't our existing CTO or engineering team assess this?: They may be perfectly capable of it. Lornets is useful when the organisation needs a structured technical challenge around a consequential decision, particularly where management, customers, investors or significant engineering spend depend on the conclusion. We work alongside the existing team.
Is Production Assurance just a security audit?: No. Security & Access Control is one Production Assurance domain. The assessment also examines Architecture & Maintainability, Reliability & Recoverability, Performance & Scalability, Data & Privacy Engineering, Delivery & Change Control, and Observability & Operations. Specialist penetration testing or certification may still be required separately.
What access do you need?: Only what the agreed assessment requires, on a minimum access and maximum evidence principle: read-only and least-privilege access where practical, client-controlled credentials, and no unnecessary extraction of production data. Some conclusions cannot be substantiated without appropriate technical access, and we say so.
Can Lornets implement the recommendations?: Yes, where engineering is justified. Assessment and implementation are deliberately separated. Where changes are required, Lornets can deliver Production Hardening & Scale, undertake Platform Transition work or collaborate with your existing engineering team.

Can the organisation safely depend on this software for what it needs to do next?

Tell us what has changed around the software and what it now needs to support. We will establish the scope, the evidence required and whether this assessment is the right starting point.