# How to build a new application and keep it evergreen

> Build a completely new application from agreed business requirements, then keep its specification, application knowledge and verification current so engineers can continue improving or replacing the implementation.

Paper: 05.3
Published: 2026-10-29
Canonical: https://harten.io/papers/05-3-the-route-to-the-target-is-part-of-the-architecture/

Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/05-3-the-route-to-the-target-is-part-of-the-architecture.jpg?v=18e3ff27ce29). Illustrative cover artwork, not an application screenshot or a record of measured results.

## What This Paper Examines

Once an organisation understands what its service needs to do, it can build a completely new application around those requirements. The existing implementation provides evidence; it does not have to supply the replacement's architecture. This paper follows that choice through an illustrative eligibility service and asks what would make the new application evergreen: keeping its business requirements, application knowledge and verification current enough for engineers to continue changing it, including replacing the implementation again when that is justified. Bringing it into production is one part of the work. By the end, the reader should be able to judge whether a proposed replacement establishes that continuing capability, as well as delivering a working first release.

## A New Application With a Different Starting Point

Imagine that our eligibility service has reached the point described in [A target architecture must explain its trade-offs](https://harten.io/papers/05-2-a-target-architecture-must-explain-its-trade-offs/). The organisation knows which decisions the service must make, which corrections staff may authorise and what applicants and downstream systems need to receive. Engineers have compared plausible designs and explained their preferred approach. There are still questions to resolve, but the replacement is no longer being designed from an unexplained collection of repositories and database tables.

We can now build a new application. Its user journeys, internal components, data structures and technology can be chosen around the service the organisation intends to provide. There is no requirement to begin by extracting the old calculation routine, translating each legacy module or reproducing the existing database behind a different interface. If an overnight process only exists because the old application cannot complete an update reliably, the replacement needs to satisfy the underlying business requirement. It does not automatically need the same overnight process.

That freedom was the point of the greenfield approach in [Architecture should be a consequence of evidence](https://harten.io/papers/05-architecture-should-be-a-consequence-of-evidence/). Recovering the existing behaviour gives us a better basis for deciding what to build. It should also help us identify what the organisation no longer needs, what it wants to improve and which constraints belonged to the old implementation. The specification for the new application is an agreed account of its required future behaviour, informed by that investigation.

For the eligibility service, the organisation might want applicants to see the status of a correction without contacting operations, while staff need to understand why a decision changed. Those are useful design requirements even if the old application never provided that experience. We would still preserve the authority to approve a correction and the ability to explain a historic decision. The business outcome and the old mechanism need separate consideration.

The larger opportunity is to retain what we have learned after the first release. If the new code becomes the only reliable description of the service, a later team will have to reconstruct the same knowledge before making another substantial change. I want the organisation to finish this work with an application it can keep improving and with the means to understand what the next change would affect.

![An illustrative evergreen engineering approach. Evidence from the existing application and operational work is considered alongside future business needs. People agree and maintain the required behaviour, design decisions and verification cases. Engineers and agents use that material to build a new application, verify and introduce it, then learn from its operation. Approved changes feed back into the maintained requirements so the implementation can be revised or replaced again.](/assets/papers/05-3-building-and-renewing-an-evergreen-application.svg)

*The first implementation is new. Later changes use an updated account of the service, its requirements and the evidence from operation. A later engineering decision can improve the current application or replace it with another implementation.* [View the diagram at full size](https://harten.io/assets/papers/05-3-building-and-renewing-an-evergreen-application.svg).

## What Evergreen Means for This Service

By evergreen, I mean that the organisation retains the practical ability to understand, change and renew the application as its needs and technology change. Engineers can establish which behaviour is required, find the relevant implementation and dependencies, check a proposed change against representative cases and see what happened after release. The people responsible for the service can explain what they have authorised and reconsider it when the circumstances change.

This includes ordinary maintenance, but it reaches further. A supported runtime and current libraries are useful; they do not tell us whether a policy change can be introduced without recreating an unexplained calculation in several places. Equally, a good specification is of limited use if nobody can reproduce the deployed application or determine which version of a rule it is using. We need the business understanding and the engineering arrangements to remain usable together.

Consider what happens when the period over which household income is assessed changes. A team should be able to identify how that period affects intake, the calculation, decisions already made, cases still open and reporting. It should be able to find the approved rule, the reason for its previous form and the tests that exercise relevant exceptions. Where the new policy has not settled the treatment of open cases, the team should be able to show that question to the responsible person before implementation turns an assumption into behaviour.

That is a practical test of whether the application remains understood. Having to undertake some investigation is normal. Having to rediscover the meaning of the service from scratch every time is the condition we are trying to avoid.

The implementation itself need not be permanent. A future team may improve a module, adopt a different database or build another complete application from the then-current specification. An evergreen approach should leave those choices available. The continuity comes from maintaining the knowledge and evidence needed to make and verify the change, rather than expecting the original code to remain suitable indefinitely.

In [Evergreen engineering beyond the context window](https://harten.io/papers/evergreen-engineering-beyond-the-context-window/), I examined continuity as people, agents and working contexts changed. The question here is what we should design and retain around a new application so that future engineers can continue the work. The earlier operating case informs that direction; the eligibility service remains an illustrative design example.

## An Agreed Specification That Can Change With the Business

The initial specification should describe more than the normal path through an eligibility calculation. It needs the meaning of the information being collected, the conditions for an accepted submission, the rules for deciding a case and the handling of authorised corrections. It also needs the service's operating requirements: who may see or change sensitive information, which dependencies can be unavailable temporarily, how quickly outcomes must reach their consumers and what recovery must achieve.

Those requirements will have different sources. A policy owner may confirm a rule. Operations may explain a correction that was invisible in the public interface. Source analysis may reveal a reporting consumer that still depends on an old interpretation. A proposed improvement may come from research with applicants. The record should let the next team distinguish an observed behaviour, an agreed future requirement and an unresolved question. Otherwise an agent can turn a plausible description of the old application into a requirement the organisation never accepted.

Some of the legacy behaviour should deliberately disappear. Suppose staff currently export cases to a spreadsheet to reconcile a reporting discrepancy. The investigation needs to establish what the reconciliation protects. The new application may provide that control directly, making the export unnecessary. Preserving the spreadsheet workflow simply because it appears in the operating history would miss the opportunity to build a better service.

Once the new application is live, the same record needs to change with it. If a policy decision alters eligibility, the team should record the approved meaning and effective conditions, update the relevant examples and identify which implementation and release introduced the change. A later reader should be able to recover the rule that applied to an earlier decision as well as the rule that applies now. Overwriting yesterday's requirement with today's wording would make the current specification simpler while making historic outcomes harder to explain.

I would also keep the limits of the specification visible. An unresolved interpretation should have an owner and a consequence for the work that depends on it. A test that covers one class of correction should not be described as covering every possible intervention. The purpose is to give the team a dependable starting point for engineering, with enough context to recognise when a new decision is required.

The distinction developed in [How to describe required behaviour without copying the old implementation](https://harten.io/papers/04-2-how-to-describe-required-behaviour-without-copying-the-old-implementation/) remains useful throughout this process. We can preserve a required outcome while changing how it is delivered, and we can change the outcome itself when the organisation has deliberately authorised that change.

## A Design That Can Be Reconsidered

For the first implementation, suppose the team chooses the modular decision application examined in 05.2. Rules, case state and authorised corrections remain within one deployable application. Intake and reporting have separate boundaries where their operating needs justify them. This is a new design selected for the circumstances of the example, not a translation of the three legacy repositories.

Keeping it evergreen requires more than recording that decision once. The reasons for the design need to remain accessible, together with the conditions that would justify reconsidering it. The core might have been kept together because one team owns the outcome and separate rule deployment offered little demonstrated benefit. If several services later need the evaluator and a dedicated team takes responsibility for it, those circumstances have changed. The previous decision gives the team a useful starting point for review, rather than a permanent instruction to keep the architecture unchanged.

Interfaces should make those changes possible without exposing every internal detail. A reporting consumer should use an agreed representation of decisions and corrections, with clear version and timing behaviour. If it depends directly on private table layouts, changing the decision application's storage becomes a coordinated exercise across systems. A defined contract gives the team a place to assess compatibility and, where necessary, plan a deliberate change with the consumer.

The same care applies to information that must survive an implementation. The organisation needs to understand the meaning of case identifiers, submitted evidence, policy versions and correction history. It should be able to move or retain that information without losing the ability to explain what happened. An export containing every row is not sufficient if the relationships that make a historic decision intelligible have disappeared.

I would therefore ask engineers to demonstrate important aspects of future change while building the first version. Can another engineer recreate the environment from the controlled build and configuration? Can the team identify where the income-period rule is implemented and which tests challenge it? Can a reporting contract change without an unexplained effect on case decisions? Can the chosen data representation preserve the history that operations needs? These checks give the architecture consequences the team can inspect.

There is no need to create a separate service for every potential future change. Each boundary brings its own coordination and operating work. The useful design is one whose responsibilities are clear, whose significant assumptions can be challenged and whose implementation can change without making the required behaviour unknowable.

## The Next Policy Change After the First Release

Now imagine the new eligibility application has been operating for several months. The organisation approves a different assessment period for household income. For this example, the change applies to claims submitted from an agreed date, while the treatment of cases already open requires a separate decision. Earlier completed decisions must remain explainable under the rules used at the time.

The engineering team starts with the current requirement and its linked examples. It can see where the assessment period affects input validation, the calculation and the explanation shown to the applicant. It can also see the correction path and the reporting contract that carries the resulting decision. An agent can help trace those relationships against the current source, identify affected tests and prepare the implementation work. The saved account guides the investigation; checking the deployed version and current code prevents an old description from being mistaken for the present application.

Before the change is implemented, the policy owner resolves what happens to open cases. Suppose some remain under the original rule while others may be reassessed through an authorised process. That choice needs to appear in the specification and acceptance examples. An engineer or agent should not infer that every open case can simply be recalculated with the latest configuration.

The team then develops the change and challenges it with cases that exercise the decision. A new claim submitted after the agreed date should receive the new treatment. An earlier completed decision should retain its original explanation. A case selected for reassessment should show the new decision and the reason it was reconsidered. An authorised correction arriving during calculation should still be protected against a stale result, as examined in 05.2. These are examples of the required behaviour, not tests chosen merely because the new code happens to pass them.

When the change is released, the record connects that approved policy version to the implementation, the checks performed and the deployed configuration. Operations can identify which cases are still waiting for reassessment and investigate unexpected results. Any discrepancy that changes our understanding should feed back into the requirement or implementation, with the reason retained. A release note saying only that the income rule was updated would lose much of what the next engineer needs.

This is what I would want ordinary change to look like in the new application. The team still has engineering and business decisions to make, but it can work from maintained knowledge of the service. AI assistance can increase the amount of tracing, implementation and verification it can undertake without requiring the team to recover the entire meaning of the application on each occasion.

## When Another Complete Implementation Is the Better Choice

Continuous improvement does not restrict the organisation to incremental changes inside the first replacement. Suppose a later operating constraint makes the chosen technology unsuitable, or a different design offers a substantial benefit. The team should be able to consider a completely new implementation again, using the current approved requirements, operational findings and verification cases as its starting point.

That decision still needs a reason. A routine dependency update may be the right response to an ordinary maintenance requirement. A broader replacement may be justified when the current design creates a persistent constraint that smaller changes do not address satisfactorily. The comparison should include the work of verifying the new application, introducing it and maintaining it, as well as the effort required to generate its code. The availability of faster generation changes the options worth examining; it does not make every rewrite worthwhile.

For the eligibility service, a new implementation could be developed separately from the live application and tested against the current business specification. It could use a different language, data model or arrangement of components. Engineers would need to check the meaning of decisions and corrections, the treatment of historic information, external contracts and operating requirements. Matching a few example outputs would not establish that the replacement satisfies the service as a whole.

Nor should the current specification be treated as permanently complete. The investigation may reveal a new operational need or a mistaken assumption. The team should resolve that finding and revise the approved requirement where appropriate, rather than reproducing a defect because it is already documented. The maintained knowledge makes this work more informed; it does not remove the need for judgement.

The important freedom is that the business is not obliged to preserve one implementation simply because the reasoning has become inseparable from its code. A new application can be built from an updated understanding of the service. That is the larger opportunity in combining application intelligence with AI-assisted engineering.

## Bringing the New Application Into Service {#bringing-the-new-application-into-service}

The initial greenfield application, and any later replacement, still needs a deliberate introduction into live operation. The existing service can continue handling applications while the new system is built and verified independently. The organisation then decides whether a single rehearsed cutover or a staged transfer is appropriate for its cases, data and external dependencies. Building a complete new application does not require a programme to extract and migrate each legacy component in turn.

![The existing application continues serving live cases while a complete new application is built and verified independently. An authorised release decision leads to either one rehearsed cutover or a staged transfer of case groups. Each case has one authoritative writer. The new application then enters continuing operation and improvement; the old system is retired only when its required dependencies and retained records have been accounted for.](/assets/papers/05-3-bringing-the-new-application-into-service.svg)

*Both routes introduce a complete, independently built application. Staged transfer can leave different case groups with different applications, while keeping one authoritative writer for each case. Continuing improvement follows introduction into service.* [View the diagram at full size](https://harten.io/assets/papers/05-3-bringing-the-new-application-into-service.svg).

Where comparison with live activity is useful and permitted, the new application can calculate a shadow result while the existing service remains authoritative. Differences need to be assessed against the approved specification. An intentional correction of an old defect should not fail merely because the outputs differ. Equally, an unexplained difference should not be accepted because the new implementation appears cleaner. The cases and the reasons for their disposition need to remain available for review.

At each stage, the team needs to know which system may change authoritative case state. If the new intake interface is introduced before case ownership moves, it may use an adapter into the old application's accepted contract. Allowing both applications to update its tables independently could bypass validation and create conflicting decisions. The temporary arrangement should have an owner and an exit condition: for example, remove the adapter after the new application owns case creation and the old interface has no remaining production consumers.

The transfer also has to preserve the work around a case. Staff must still receive cases requiring manual review, reports need an agreed source for each period, and historic decisions must remain intelligible. The old application can be retired when no required behaviour, interface or operational process depends on it and retained information has an agreed home. These conditions are more useful than declaring a migration complete because the new code is deployed.

Recovery changes when write authority moves. Before then, returning traffic to the old application may be sufficient. After the replacement has accepted new decisions or corrections, returning to an earlier deployment can require data reconciliation or a different recovery route. The team should rehearse the response that actually restores the service's required state. Google's [SRE guidance on canarying releases](https://sre.google/workbook/canarying-releases/) describes evaluating a limited production exposure before proceeding more broadly. That can inform a release decision, but the transfer of case ownership also needs the data and business checks described here.

These arrangements support the introduction of the new application. They are one part of the evergreen approach, alongside the continuing work of keeping its requirements, implementation and verification understandable after the transfer has finished.

## Keeping Renewal Part of Normal Engineering

The organisation needs to retain capacity for this work after the programme delivers its first release. Someone must be responsible for the service's requirements and priorities. Engineers need time to address dependency changes, improve the design and maintain the means of verification. Operations needs a way to bring newly observed behaviour into that work. A useful design can still become difficult to change if the organisation treats understanding and improvement as activities that ended at launch.

The Government Digital Service's [guidance on managing and improving a service through its lifecycle](https://www.gov.uk/service-manual/agile-delivery/running-your-service-in-a-sustainable-way) makes a related point: a service needs people and funding for continuing improvements, including changes in user needs and policy. Routine fixes alone do not cover that responsibility. For our example, the question is whether the eligibility team can change how the service works when the business needs it to, rather than only keep its present processes available.

The technical arrangements should support that capacity. The team needs controlled source and configuration, repeatable builds, useful automated checks and a reliable way to introduce changes. DORA's [continuous delivery guidance](https://dora.dev/capabilities/continuous-delivery/) connects sustained deployability with feedback and engineering practices. It also distinguishes being able to release when needed from automatically deploying every change. An evergreen application can have deliberate release decisions while keeping the work needed to reach those decisions manageable.

I would judge this through actual changes. When the income rule changes, how much of the affected behaviour can the team identify and explain? When a dependency must be replaced, can it establish which responsibilities are affected and test them? When an incident reveals a missed case, does the correction improve the specification and verification for the next release? When a new engineer joins, can they reconstruct the reason for a consequential design choice without finding the person who originally made it?

The answers will show where further investment is needed. A growing collection of unexplained exceptions or a recovery procedure that nobody has exercised is a reason to investigate. A team that can demonstrate the next required change has evidence that the capability remains usable. Counting deployments or generating more documentation would not answer the same questions.

## What Engineers and Agents Need for the Next Change

AI-assisted engineering makes the quality of this continuing account particularly consequential. An agent can help analyse new dependencies, update a candidate specification, generate a different implementation and prepare tests. It can also act on an outdated requirement or produce a convincing explanation for behaviour it has not established. The work should connect it to the current approved requirements, relevant source and operating evidence, rather than expecting one conversation to contain the whole history of the service.

For the income-policy change, the agent needs the current baseline, the authorised change and the decisions that still require a person. It needs to know which historic rules remain relevant and why an earlier correction must survive a later calculation. That gives it useful engineering freedom within a clear purpose. It can propose a different implementation of the rule without acquiring authority to redefine who qualifies for support.

The same distinction applies when an agent prepares a complete replacement. The organisation should be able to inspect what was built against requirements and examples established independently of that implementation. A model generating both code and a matching set of tests can reproduce the same misunderstanding in each. Review of operational cases, affected interfaces and observed test results remains part of establishing whether the application does what the organisation intended.

What we learn from that work should improve the retained account. A newly discovered consumer belongs in the dependency information. A corrected interpretation belongs in the requirements and its associated examples. A rejected design should retain the reason it was rejected, so a later team can distinguish a continuing constraint from a condition that has changed. These are specific engineering responsibilities, not a request to preserve every message an agent produces.

The opportunity is considerable. Teams can use AI to investigate more thoroughly, compare more designs and undertake implementation work that would otherwise be difficult to resource. They can build a genuinely new application and continue renewing it. The people responsible for the service still determine its purpose, approve changes to required behaviour and judge whether the resulting application is fit for use.

## What We Should Have After the First Release

At the end of this work, our eligibility service should have a new application designed around agreed needs. Applicants and staff should receive the capabilities the organisation chose to provide, including improvements that the old implementation could not readily support. The legacy implementation can be retired once the transfer and retained records have been accounted for.

Alongside that application, the team should have a current, reviewable account of its requirements, important design decisions, dependencies and operating behaviour. Its verification should challenge the cases that matter to the service. Its delivery arrangements should make it practical to introduce the next justified change. Engineers and agents should be able to use and update that material as they work.

That gives the organisation a choice about the future implementation. It can continue improving this one, replace a capability or build another application when the evidence supports doing so. What it should not have to do is repeat the same expensive reconstruction of what the business needs because that knowledge was allowed to disappear after go-live.

Series 05 began by asking what architecture the evidence supports. It can end with a more ambitious result than a newer version of the same constraints: a new application whose required behaviour remains understood and whose implementation can continue to change. Series 06 then examines how to organise the engineering work around consequence, dependencies and learning, whether the chosen implementation is being built from new or improved through subsequent releases.

---

*This paper uses an illustrative eligibility service. Its policy changes, design choices and proposed checks are examples, not measured outcomes from a customer modernisation.*

*This paper is part of The Modernisation Control Papers, the first major sequence within The Harten Papers. [Read the complete series on harten.io](https://harten.io/papers/).*