Standards applied the same way on every engagement are what let a small development team keep its pace after the first month. What that looks like in practice.
A lot of what gets called agile is improvisation with a stand-up meeting. It looks fast for the first month and slows down every month after, because decisions that were never written down have to be rediscovered, and integrations that were never specified break in production.
We run development engagements the other way round: a small amount of structure first, applied the same way every time, and then as much speed as the structure allows. A recent outsourced engagement, building operational dashboards for a software company, is a fair example of what that means in practice.
Every engagement starts with a solution architecture document written before the build. It is short, and it is explicitly a living document. It states what the system does, the technology it must fit, the integration points, the assumptions and, just as importantly, the exclusions.
In the dashboard work the assumptions were specific about what each tile would show, which data feeds would supply it and that the supplied data structures were fixed, and the exclusions were just as specific. Each of those sentences removes an argument that would otherwise happen halfway through a sprint.
The dashboards are fed by scheduled imports of spreadsheet extracts. Nothing is imported on trust. A base importer reads each file and validates it against a defined schema before anything is persisted, so a renamed column or a missing tab produces a clear rejection at the door, not a wrong number on a manager's screen three days later.
The same thinking applies to any integration. Define the contract, validate against it, and make failure loud.
The first phase reads files from an FTP location. The second replaces that with an API. The FTP path is kept as a fallback for when the API is unavailable, and the scheduler that runs the imports provides logging and automatic retries.
It is a small amount of extra work at design time, and it is the difference between a dashboard that is occasionally stale and one that is occasionally blank.
We apply these practices on every engagement.
Source control and pipelines. Code lives in version control, every change is reviewed, and every change is built and tested by a pipeline before it can be deployed.
Separate environments with increasing control. Development deploys freely. Staging and production follow the client's own change process, typically a written request for change with risks and a rollback plan, and a change advisory review before production.
Security in the pipeline. Static code analysis as the baseline, with every added line scanned for standards, architecture and security issues before it is committed, dependency scanning where the client chooses it, and dynamic testing as a deliberate, scheduled activity.
A written handover. The documentation needed to run the system arrives at go-live.
Because the standards are the same everywhere, an engineer moving between engagements does not have to learn a new way of working, and a client can see in advance exactly how their software will be built, tested and released.
Structure sounds like overhead. In practice it removes the most expensive kind of delay, which is discovering in month three something that could have been decided in week one. A small team with clear standards spends its time building. A large team without them spends its time reconciling.
How we apply this, now with AI assistance inside the same discipline, is set out on AI-assisted engagement and delivery and under software development and engineering.
Part of From our delivery work. Get new articles by email or follow the RSS feed.
Unstructured data is the harder half of retiring an old platform. When documents are wired into daily work, the aim is a migration the users never notice, and the risk sits in places that are not code.
Most of our work is building software that a client owns. UMOYA Zone is different. It is a joint venture, and co-owning a product has taught us things that client work does not.
When an investor looks under a growing platform, the questions are about credentials, data and whether the fixes are real. What we learned taking a technical due diligence from first review to verified remediation.
