Production Hardening & Scale
Fix what materially constrains the next stage.
Lornets turns material production findings into targeted engineering interventions. We keep working foundations, improve what evidence shows needs improvement and replace components only where the constraint justifies the disruption.
Success is a demonstrably stronger production system, measured against the target condition.
The commercial position
- The situation
- Assessment or operational evidence has identified constraints that materially affect the next operating context.
- The decision
- What is the smallest defensible set of engineering changes required for the next operating context?
- What Lornets does
- Engineering starts from verified findings and defined target conditions, then applies the least intervention that meets them: configure, instrument, harden, optimise, refactor, isolate or replace.
- What you leave with
- Defined work packages tied to verified findings and target conditions
- Target conditions and verification criteria agreed before work begins
- Implemented changes with evidence that the finding is closed
- An updated view of the production position
- What may happen next
- Where a constraint proves structural, Platform Transition & Migration may be considered as a separate engagement.
- When this is not appropriate
- The constraint has not been established and no verified findings exist
- You need general feature delivery or additional coding capacity
- A large architecture programme is already decided and only implementation is wanted
From finding to verified engineering
What actually needs to change for this system to support what comes next?
Make the smallest defensible set of engineering changes required to make the system fit for its next operating context.
The delivery logic
- 01Finding
- 02Target condition
- 03Engineering intervention
- 04Verification
- 05Updated technical position
Work begins from evidence, not technology preference. Lornets confirms the material constraint, defines the condition the system has to reach, implements the proportionate change and verifies that the technical position has actually moved.
What justifies material engineering work
Before material change is made, the case for it is stated plainly and agreed. Routine implementation tasks do not carry this overhead.
- A verified finding or a demonstrated constraint
- The target condition the system has to reach
- The proposed intervention
- Alternatives, where a materially less disruptive option exists
- The criteria that will verify the result
- The risk the change itself introduces
How this differs from a Production Readiness Assessment
The assessment establishes the technical position. Production Hardening & Scale turns selected findings from that position into engineering outcomes that can be demonstrated.
Production Readiness Assessment
Primary question
What is the technical position?
- Material findings
- Evidence
- Critical Readiness Gates
- Assurance Confidence
- Keep, Refactor or Replace decisions
Production Hardening & Scale
Primary question
Which justified engineering changes should now be implemented, and can we demonstrate that they worked?
- Engineering Work Packages
- Target conditions and verification criteria
- Controlled production change
- Verification evidence
- Updated technical position
Two engineering modes, one engagement
Work commonly falls into two overlapping modes. The same engagement may contain both, and the balance is set by what the evidence shows.
Production Hardening
Strengthen an existing system that broadly works but requires greater production assurance: security boundaries, access control, reliability, recovery, observability, deployment control, data handling and dependency posture.
Scale Engineering
Remove demonstrated constraints preventing the system from supporting its next workload: database contention, latency, concurrency, saturation, failure domains, external service limits and the operating economics that come with them.
Keep what works. Refactor where justified. Replace only where necessary.
Production Hardening & Scale does not start with a predetermined technology or architecture. A technically simple intervention can be the correct intervention, and a valid outcome may be to leave substantial parts of the existing system unchanged.
Not prescribed by default
- Microservices
- Kubernetes
- Event-driven architecture
- Cloud migration
- Framework replacement
- Database replacement
- Full rewrite
Nothing on this list is prescribed automatically. Each would need a demonstrated constraint and an argument that less disruptive options cannot reach the target condition.
Start with the least disruptive intervention
This progression is a decision discipline, not a mandatory sequence. Each step asks whether the target condition can be reached without moving further down the list.
The burden of evidence increases with the cost and disruption of the recommendation.
- 01
Configure
Can the target condition be achieved by correcting or improving configuration?
- 02
Instrument
Is the real constraint still insufficiently understood? Improve observability before redesigning the system.
- 03
Harden
Can stronger controls, testing, failure handling or operational practice solve the problem?
- 04
Optimise
Can the current architecture support the target with focused performance work?
- 05
Refactor
Does part of the implementation require restructuring while preserving the broader foundation?
- 06
Isolate
Can the constrained component be separated or bounded without replacing the wider system?
- 07
Replace
Is replacement now the most proportionate response to a demonstrated material constraint?
Measure first. Define the target. Verify the result.
A request to make the platform scalable is not precise enough to engineer against. Lornets establishes what the system supports now, what it needs to support next and how the result will be demonstrated.
- Current condition
- Required condition
- Intervention
- Verification
The example is illustrative. Lornets does not publish client results or generic improvement percentages, and creates no target for a dimension with no real operational basis.
One illustrative example
- Current condition
- Database saturation occurs at the projected workload.
- Required condition
- The target workload is sustained within agreed latency, error-rate and utilisation limits.
- Intervention
- Contention removed at the demonstrated bottleneck, without wider restructuring.
- Verification
- A controlled workload test demonstrates the required operating envelope.
Work is prioritised, then bounded
Not every finding should become engineering work. Potential work is weighed against materiality in the target operating context, then organised into Engineering Work Packages so the scope stays defined.
Work traces back to an assessment finding, a demonstrated constraint or an explicitly agreed target condition. New material requirements become an agreed change in scope, not a silent expansion.
- Required for target state
- Necessary for the stated operating context.
- High-value improvement
- Strongly justified but not currently a blocker.
- Opportunistic
- Worth addressing where adjacent work makes the cost proportionate.
- Defer
- A real issue that is not currently worth the cost or disruption.
What each work package defines
- Scope
- Target condition
- Intervention
- Acceptance and verification
- Ownership
The change itself should not become the incident
Material production changes carry proportionate rollout, rollback or recovery, observability and validation controls. Lightweight changes do not require heavyweight process, and the level of control follows the blast radius.
Engineering closes on evidence
A finding is not closed because implementation finished. It is closed when the evidence changes. The original evidence, the intervention and the new measurement or operational evidence are compared, and the affected part of the technical position is reassessed on that basis.
Result recorded as
- Resolved
- Partially resolved
- Not resolved
- Superseded
Material technical decisions and their verification are recorded in a lightweight form so the reasoning survives the engagement. Routine implementation is not documented for its own sake.
AI, security and operating economics
- AI controls where AI is material
- Where AI materially affects behaviour, hardening can include evaluation and regression testing, model and prompt versioning, output validation, tool and agent permissions, human review, sensitive-data controls, fallback and cost limits. Simple controls are preferred where they address the actual risk.
- Security engineering, within limits
- Access control, tenant isolation, secrets management, dependency remediation, configuration hardening and privilege reduction can all sit in scope. Formal penetration testing, certification, compliance opinions and 24/7 security operations are not automatically included and may require separate specialist scope.
- Operating economics where they affect scale
- Where infrastructure, database, third-party or AI inference cost materially affects the scale decision, cost behaviour is measured or modelled alongside technical capacity. Technically scalable is not always commercially scalable.
Working with your engineering team
Lornets integrates with the engineers already responsible for the system. The unit of work is the defined engineering outcome, not developer availability, and scope stays tied to the agreed target conditions.
- Collaborative
- Lornets defines and leads specialised production engineering while client engineers implement or participate.
- Lornets-led implementation
- Lornets implements defined Engineering Work Packages directly.
- Hybrid
- Responsibilities are divided according to technical expertise, system ownership and delivery efficiency.
Handover
- Updated architecture documentation
- Technical decision records
- Runbooks and recovery procedures
- Monitoring and alerting guidance
- Engineering walkthrough sessions
How the engagement runs
Duration depends on scope and complexity, and is agreed before work begins.
- 01
Confirm constraint and target
- 02
Define intervention and verification
- 03
Implement controlled change
- 04
Measure and verify
- 05
Update position and hand over
What you receive
Delivery depends on scope, and not every engagement generates every item. What follows is the visible outcome of the work.
- Implemented engineering changes
- What actually changed in the system.
- Work-package outcomes
- Target conditions and the completion state of each package.
- Material technical decisions
- The choices made and the trade-offs behind them.
- Verification evidence
- Tests, measurements and operational evidence.
- Updated technical position
- How the relevant claims, evidence and findings now stand.
- Residual risks and handover
- What remains, what is deferred and what the client needs to operate the change.
Do you need an assessment first?
A prior Lornets Production Readiness Assessment is a natural entry point but is not mandatory. Where sufficiently credible technical evidence already exists, Lornets validates the relevant findings and scopes the engineering work from there, so nobody pays for duplicate assessment work.
Substantial work does not begin without a defensible understanding of the problem, the evidence, the target condition, the scope and the verification criteria.
What Production Hardening & Scale is not
Work remains tied to material technical constraints or a defined target operating state.
- General feature or first-MVP development
- Staff augmentation or open-ended developer capacity
- A predetermined rewrite or migration
- Technology modernisation for its own sake
Related engagements
Platform Transition & Migration
Where the foundation itself is in question, the Stay, Refactor, Hybrid or Migrate decision belongs there.
Managed Production Engineering
Hardening is a defined programme with a target end state. Stewardship keeps that state true as the system continues to change.
Investment
From £15,000
Production Hardening & Scale
Scope is defined around agreed engineering outcomes, system complexity and verification requirements.
Work is scoped around defined Work Packages, target conditions and verification requirements. Larger or complex engagements may exceed £50,000.
Duration depends on scope and complexity, and is agreed before work begins.
Residual risk at completion
Production engineering does not remove all risk. Material residual risks are classified explicitly.
This records the technical position. Business-risk acceptance remains with client management.
- Resolved
- Addressed and verified.
- Reduced
- Materially improved but some exposure remains.
- Accepted
- Understood and consciously retained by the client.
- Deferred
- Real work that is not justified within the current target.
- Transferred
- Handled through another control, provider or specialist.
Questions we are asked
- Does Production Hardening mean rewriting the system?
- No. Hardening starts from verified findings and defined target conditions, not from a preference for new technology. The intervention may be configuration, instrumentation, hardening, optimisation, refactoring, isolation or replacement. Replacement is only one option, and the burden of evidence rises with the cost and disruption of the recommendation.
- How do you decide what to fix first?
- Prioritisation weighs materiality against the target operating context, the strength of the supporting evidence, technical severity, business priority and expected benefit. Not every finding receives equal treatment. Work required for the target state is separated from high-value, opportunistic and deferred improvements.
- How do you know a finding is actually fixed?
- A finding is not closed because code changed. It is closed when the evidence changes. Lornets defines the target condition, implements or reviews the intervention, verifies the result against acceptance criteria and updates the technical position on the basis of the new evidence.
- Can you work with our existing engineering team?
- Yes. Lornets can work collaboratively with your engineers, lead defined work packages directly or operate a hybrid delivery model. We do not assume that the existing team should be replaced.
- Is this staff augmentation?
- No. The work is organised around defined engineering outcomes, target conditions and verification. General product-feature delivery sits outside the remit.
What actually needs to change for this system to support what comes next?
If findings are already known, the next step is deciding which of them justify engineering work and how success will be demonstrated.