Work.

Poster was a bespoke post room web application, developed whilst I worked at a convenyancing firm, to solve the problem of increasing sorting and filing times as the business grew. It allowed post room staff to drag and drop centralised scanned post, enter a file reference, which Poster would then 'post' to the relevant file in the case management system and notify the associated fee earner that they had received 'post', including a narrative entered by the postal team, such as 'Mortgage offer' received.

Despite the business growing and postal volume increasing, post could now be processed by just one team member, both increasing efficiency and saving costs, whilst not compromising on quality or accuracy.

Ensuring servers are patched in a timely, standardized manner is what I would consider IT bread and butter. However, in my own experience, many organizations leveraging Azure struggle to achieve coverage across their estate, even when utilizing the native Azure Update Manager offering. Across customers I often saw inconsistent patch schedules, update groups with a mismatch of desired reboot behaviours and out of date corresponding documentation.

Whilst at Littlefish, I developed a solution for this exact problem. Leveraging Terraform, Azure Policy and PowerShell, we had a solution which could be deployed into any of our Azure customers, in hours. It provided a standardized, scalable, yet flexible approach to update management. It featured automatic documentation creation and maintenance, monitoring and alerting, and also supported pre and post maintenance tasks / webhooks, so it could be extended to meet any particular needs of that customer.

The capturing of update reqirements could be done through an ITSM tool, such as ServiceNow, or through a custom portal.

I think most cloud engineers are familiar with the rigmoral of onboarding new projects, creating the identities, role assignments, repositories, workflows, secrets and plumbing it all together. It takes time, is often error prone and can lead to inconsistencies.

To solve this problem both internally and for our customers, I developed a project onboarding solution, which upon capturing the business requirements through a simple form, or ITSM tool, would then provision all the necessary resources to get a project up and running in minutes, not days.

Working across several customer accounts, I noticed that teams that needed an app registration or SSO integration had to raise a request, wait for an internal team to action it, and then hope it was configured correctly. Beyond the bottleneck, each team often ended up with slightly different setups, client secrets that nobody was tracking, and no consistent approach to governance.

To fix this, I built a self-service identity vendor solution we could provide to our customers. Developers could submit their requirements through a form or something like ServiceNow, specifying things like the name, authentication configuration, API permissions and whether it needed a federated identity or a client secret. The solution would then provision an app registration in Entra ID, configure it to spec, and return the necessary credentials securely back to the developer. If a client secret was involved, it would also handle secure storage, expiry notifications to the relevant owners, and rotation. Rather than each team reinventing the wheel, they got a standardised, pre-configured setup that met security and governance requirements out of the box, without having to wait on anyone.