Development leadership / Shared systems
From starting again
to building on shared work.
The problem
Every application started from an empty Unity project. Teams recreated player rigs, movement and interactions, with no consistent approach across projects. Time went into solving the same basics, and useful work rarely carried forward.
How I fixed it
I built, tested and documented a bespoke Unity VR template: a single, standardised starting point with our plugins and tools connected, tested and kept up to date. Reusable interactions, assessment systems and course-building wizards followed, supported by common planning, testing and release practices.
The result
Projects were quicker to start and more consistent. Non-developers could prepare courses, developers could focus on technical challenges, and project teams could deliver more independently.
More about the rollout
Making it work for people
I explained why we were choosing a common system, including its limitations. Familiar constraints helped the team become more proficient and gave the business clearer choices: use an established capability, or allow time to build something new. Written guides, videos and demonstrations supported different ways of learning.
Keeping the foundation useful
New capabilities were added back into the template so the team could use them on future projects. Shared setup, testing, deployment, bug reporting and progress tracking helped prevent projects from drifting apart.
A practical example
For one anonymous utilities client, a familiar interaction model let planners and developers recommend a solution confidently within the available budget. It became one of our cleanest and quickest projects, substantially reducing development time compared with similar early work.




