’ data infrastructure and systems access practices. These required us to develop in distinct workstreams and to create products which operated solely within individual LAs – though the deployment code can of course be shared and reproduced. Our response to these challenges was to recruit partner LAs to work with our project team, deploying our code and reporting testing results, or developing their own code and then sharing it with us, without our directly accessing their systems. This approach worked, but was made significantly easier by partnering with D2I’s host LA for the first pilot development, where our project team could have direct access to code and systems, and thereby learn before working with external partners. Indeed, concern remains in some LAs regarding the over-sharing of information about their CMS or data. Less data mature LAs will typically look exclusively to their CMS supplier for guidance on data and systems work, which may further entrench a siloed culture and hinder compatibility and interoperability work – although our wider research suggested that these were key aspirations for many LAs. 9.3. Feedback driven iteration Working in the open reassured stakeholders as to project progress and direction; partners and wider community members alike could review our progress as it happened and provide iterative feedback – upon which we acted. This will continue into the next development phase, and feed directly into the project’s development backlog/bug ticket system. This process has worked well so far, and an increasing level of direct feedback is anticipated as more LAs have hands-on experience with the SSD structure and tools, and can better engage with beta data testing. Feedback to date has been insightful, and directly correlated to periods direc