Managed software development
The team that builds it is named, and you know where they sit. Acceptance is still yours to declare.
A named team, not a pool
Every engagement is staffed with named individuals and a stated role for each: the person who owns architecture and code review, the people who implement, and the engineer who owns the tests. They are named at scoping, before anything is signed, and they stay with the engagement. Where they sit, and who else can see the code, is stated in the same conversation — before access is granted, not after.
What "done" means is written before the first line of code
Scope, inclusions, exclusions and acceptance criteria are agreed at scoping, and the rule for changing them is written at the same time. Those criteria are what the automated tests assert, so a build is measured against what you agreed. Scope moves on a build of any size; when it moves, it moves in writing, against that rule.
Starting from a system that already runs
Where the work begins from an existing platform rather than an empty repository, the first deliverable is a written description of what that platform does today — read from the running system, not from its documentation. You approve that description, and it joins the acceptance criteria, so the behaviour you depend on has to survive the work rather than be rediscovered after go-live.
We do not verify our own build
Where independent verification is required, it is run by people who did not build the software — our own IV&V practice, staffed separately, or a party you appoint. We work to either. The separation is written into the contract rather than assumed.
The documentation is a by-product of the work, not a phase at the end
Documentation is written as the work proceeds. Decisions are kept with the date, the named author, the options set aside and what followed — in the LightHouse Context Graph, which runs through Foundry and Enterprise Intelligence alike. Where your own engineers work alongside ours, that sits in the scope with the time it takes, rather than being offered as goodwill.
What you get
- The build reference: scope, acceptance criteria, exclusions, change rule
- Source code in your own repositories, from the first commit
- The automated test suites, which stay with you
- Environment, build and deployment documentation, written as the work proceeds
- The decision record: dated, named authors, options set aside
- The acceptance record, written to be signed by you
The boundaries, stated up front
We do not declare acceptance on your behalf. We do not deploy to production on our own authority: that approval is yours, against criteria agreed before the work. We do not take over business ownership of the requirements: priority, scope and the business rules stay with your owner, and what we do is make them buildable. And where a scope calls for a party we do not have, the arrangement is named in the contract rather than implied.
Independent verification and validation (IV&V) →·Delivery Model →·Trust →
Tell us what you need built. A person reads every message and replies.
Engagements are contracted with Onshore Technology Services, Inc., a U.S.-domiciled entity. Delivery runs today from established teams, primarily U.S.-based; the African pathway and its current status are set out on Trust & Transparency. Trust →