How We Build and Hand Over Software
Software is built and handed over under three rules Eicra Soft Limited calls inheritor-first engineering, applied in this order: build for the engineer who inherits it, integrate through APIs rather than people, and modernize in stages. The rules follow the NIST SSDF practice groups, and we say so when the cheaper option is the right one.
Build for whoever inherits it
Software is cheap to write once and expensive to change forever. The cost that matters is not the build; it is the next five years of someone else reading it.
So every project ships with tests, a setup guide that actually starts the project, environment documentation and a second named reviewer on every change.
Integrate by API, not by hand
If a person exports a file on Monday so another system has Tuesday’s data, that is not an integration. It is a job that fails quietly whenever that person is on leave.
So we connect systems directly, with retries, an error queue, an alert to a named owner and a log of every call that failed and why.
Modernize module by module
Full rewrites fail for a predictable reason: the old system keeps changing while the new one is being built, and the business cannot wait for the finish line.
So we move one module at a time behind a stable interface, keep both running, with a rollback ready, until the new path is proven, and stop whenever you want to stop. The pattern is the strangler fig application described by Martin Fowler.
What this page covers: the software itself — building, connecting, testing, running and modernizing it. Staffed level 1 and level 2 user support runs as the separate
outsourced help desk. The National Institute of Standards and Technology (NIST) Secure Software Development Framework states that its practices “should help software producers reduce the number of vulnerabilities in released software”, and every build here follows its four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. AI-written code is reviewed against the
OWASP Top 10 before it ships (a standalone
AI generated code audit is available for code we did not write), and personal data is handled under a data processing agreement that follows
GDPR Article 28(3). Article 28(3) lists eight processor obligations, points (a) to (h), and the agreement is drafted clause by clause against them. The same regulation, at Article 83(4), sets the fine for a processor that breaches those obligations at up to €10 million or 2% of worldwide annual turnover, whichever is higher, which is why the agreement is signed before any code is written.