Insights, articles and news

Connected devices are everywhere — from smart speakers and security cameras in our homes to sensors, gateways, and wearables powering entire industries. But as our reliance on connected technology has grown, so too has the threat landscape. Vulnerabilities in consumer devices have become one of the most common entry points for cyberattacks, often due to poor security design, weak default credentials, and a lack of long-term support. To address this, the UK government has introduced the Product Security and Telecommunications Infrastructure (PSTI) Act 2022 — legislation that sets legally enforceable security requirements for consumer connectable products. While similar in spirit to the EU’s Cyber Resilience Act (CRA), PSTI is the UK’s standalone approach to raising the baseline for IoT security and ensuring manufacturers take responsibility for the products they sell.

The European Union will be introducing the Cyber Resilience Act (CRA) from September 2026 which is set to fundamentally transform how technology products are designed, sold, and maintained. The CRA is a landmark regulation that establishes mandatory, horizontal cybersecurity requirements for all products with digital elements (PDEs) placed on the EU market. For any company developing, manufacturing, importing, or distributing connected hardware and software, understanding the CRA is now a critical business imperative.

In modern software development, particularly in connected devices and IoT systems, security isn’t just a nice-to-have — it’s a fundamental requirement. As supply chains become more complex and regulatory standards tighten, understanding what’s inside your software is now just as important as knowing how it works. That’s where a Software Bill of Materials (SBOM) comes in.

At a recent Sheffield AI meetup, I gave a talk that aimed to unpack a big question: Is AI coming for your job? Short answer? No. But not for the reasons you might think. Rather than fall into the trap of hyperbole, I approached the topic by stepping back and asking a different question: How have the skills and resources around building software changed over time?

Modern cloud environments provide several different mechanisms and services for deploying a web application. In a more traditional scenario, an application may be deployed to a bare metal server or a virtual machine (VM).

We’re often engaged by our clients to develop Minimum Viable Products (MVPs) of a given product or system. More often than not we see a common and recurring problem with the original brief – the “MVP” is packed full of features of varying shapes and sizes.

Story points estimation is an estimation method that is often used in agile software development. Story points are a unit of measure used in agile project management to estimate and compare the complexity, effort, and relative size of features or user stories within a project.

Sometimes it can be useful to request a manual approval before a deploy is unleashed on production. GitHub supports manual approval when you use environments, but only on public repositories or private repositories for GitHub Enterprise. In this post, I look at how GitHub Actions and Microsoft Teams can be used to create a manual approval process.

We use continuous integration and continuous deployment techniques regularly in the delivery of our projects. Whilst our team predominantly uses GitHub Actions these days, we’ve supported a variety of CI tooling including Jenkins and GitLab Pipelines.

Estimating the effort involved in any project can be a challenge, and software projects are no different. Arriving at an accurate estimate and plan is tricky, to get right.