A Day at Made Tech: What It’s Really Like

A typical day at Made Tech starts with a calm but focused atmosphere. I’d arrive, settle in, and check my tasks for the day. The team always made space for me, and even though I was a student, I felt like a real contributor. Mornings often began with stand‑ups — short meetings where everyone shared what they were working on. This was one of the first surprises for me: how much communication matters in tech. It’s not just coding in silence; it’s constant collaboration.

After stand‑up, I’d dive into my tasks. Some days I was writing Python code for the login system. Other days I was testing endpoints, fixing bugs, or improving the database. I learned quickly that real‑world coding is less about writing perfect code the first time and more about iterating, testing, and refining. The team encouraged me to ask questions, and every answer helped me understand not just what to do, but why it mattered.

One of the most surprising things I learned was how much consultants think about users. Even when building something simple, the question was always: “How will this help the user?” That mindset changed how I approached my work. Instead of just making features function, I started thinking about clarity, security, and long‑term maintainability. Lunch breaks were relaxed and social — a chance to talk about tech, career paths, or even completely unrelated topics. These conversations helped me understand the culture of tech teams: supportive, curious, and always learning.

Afternoons were usually focused work time. I’d continue building features, updating documentation, or reviewing feedback. I learned how to manage my time, how to stay organised, and how to keep track of tasks using tools like GitHub. Seeing my code pushed to a real repository was a moment of pride — it made everything feel real.By the end of the day, I’d reflect on what I learned. Every day brought something new: a concept, a tool, a technique, or a piece of advice. That constant learning is what makes tech exciting.

🎓 Advice for Future T‑Level Students

If I could give one piece of advice, it would be this: don’t be afraid to ask questions. Tech is a team sport, and learning from others is part of the job. Be curious, be open, and take every opportunity to try something new. Your placement is not just about completing tasks — it’s about discovering how you work, how you learn, and how you fit into the world of digital consultancy.

The post A day in the life of a T-level student – Goodluck appeared first on Made Tech.

Modernising legacy technology has never been about simply replacing what exists. As we saw in the previous article, the real challenge is understanding complex systems and improving them without disrupting the services that depend on them.

AI is now accelerating that process. It is changing how teams analyse, rebuild and improve legacy systems, but it is not removing the need for careful engineering or clear thinking.

Ben Pirt, Principal Technologist at Made Tech, describes the impact of AI. “It has been phenomenally helpful in understanding a legacy codebase,” he says. “With the right inputs, AI can analyse structures, surface relationships and explain how systems behave in a way that would previously have taken weeks or months to piece together.”

That kind of visibility matters because discovery is often the slowest part of modernisation. Teams need to understand not just what a system does, but why it behaves the way it does, and how that connects to real-world processes. AI does not remove the need for that work, but it can accelerate it significantly.

Speeding up redevelopment without losing control

It is also starting to change how redevelopment happens. In one example, teams used AI to extract behaviours from a legacy codebase and treat those behaviours as a set of specifications. They then used AI to reimplement those behaviours in a new language, bringing tests across at the same time.

The results were immediate. “A week-long test got through a huge amount,” Ben says. “For certain types of work, particularly where patterns are well understood, AI can speed up delivery in a way that would have been difficult to achieve even a year ago.”

That is especially true for more repetitive tasks. Building API endpoints, following established patterns and generating boilerplate code are all areas where AI is already performing well. As Ben puts it, it is “insanely good” at following structured instructions.

It would be easy to see this as a shortcut to solving legacy problems, but the reality is more complex. AI can move things forward quickly, but it can also replicate existing issues just as fast if it is not used carefully.

“If you just say to AI, ‘port this code’, it’ll do it,” Ben explains. “But it might not do it very well.” In that scenario, the risk is that you carry forward the same poor design into a new environment, rather than improving it.

That is why engineering discipline still matters. If anything, it matters more. Strong testing, clear specifications and careful validation are what make AI useful rather than risky.

Just as importantly, organisations need permission to approach AI incrementally. That often means starting in low-risk areas, testing where it adds value, and creating space for teams to learn without feeling they have to bet the service on a single decision. In practice, responsible innovation often depends as much on creating that permission as it does on the technology itself.

Ben describes using AI within a controlled, test-driven approach. Behaviour is extracted, verified against the existing system and then used to guide the new implementation. The AI is not left to decide what “good” looks like on its own; it is constrained by clear rules and expectations.

“If you force it down a rigorous path, you can get extremely good quality,” he says. “Without that structure, the outputs are far less reliable.”

That structure also has to include transparency and governance. If AI is helping analyse, generate or recommend changes to legacy systems, teams need to understand how those outputs are reached, how decisions are validated, and where accountability sits.

Avoiding a new generation of technical debt

There is also a broader question about how AI is used across organisations. As tools become more accessible, it becomes easier for teams to build solutions quickly. That can be a positive shift, but it also introduces a familiar risk. Geraldine Mathews, Client Partner at Made Tech, highlights the concern that organisations may start solving problems in isolation. One team builds something for one part of the service, another team builds something elsewhere, and the overall journey becomes more fragmented rather than less.

“It’s got to be about the full user journey,” she says. “Without that focus, there is a real chance of creating a new layer of technical debt on top of the old one.”

Geraldine continues: “This is where the conversation becomes particularly interesting. AI is often positioned as a way to reduce technical debt, but it may also change what technical debt looks like. Instead of slow, ageing systems, the risk becomes fast-moving, disconnected ones.

“The technology itself is not the issue. The challenge is how it is applied. Without a clear delivery approach, strong architecture and a shared understanding of user needs, speed can work against you.”

AI is an accelerator, not a shortcut

At the same time, expectations are rising quickly. Organisations are seeing demonstrations of AI rewriting legacy systems and naturally begin to expect similar results. As Geraldine notes, “the expectation is going to be very high now”.

“That creates pressure to move faster, but it also increases the importance of getting things right. Delivering quickly is only useful if what you deliver is coherent, maintainable and aligned with how people actually work.”

This is also where risk assessment becomes practical. Rather than asking whether AI should or should not be used, the better question is where it is appropriate, where human oversight should remain, and how risks can be reduced through staged delivery. That is often where Made Tech works closely with clients, assessing the service, identifying suitable use cases, and proving approaches safely before scaling them into live environments.

Geraldine continues: “There is also a question about how far AI can go in redefining legacy modernisation. Some suggest that older systems can simply be translated into modern stacks with minimal effort. While that is technically possible, it risks missing a key opportunity.

“Porting a system does not improve it. It changes the environment it runs in, but it does not address the underlying design issues or the mismatch with user needs. Without that deeper work, the same problems are likely to resurface.”

That is why the fundamentals remain the same. Understanding users, designing around real workflows and building systems that can evolve over time are still central to successful modernisation. AI can support that process, but it cannot replace it.

In practice, the most effective use of AI is as an accelerator rather than a solution in its own right. It helps teams understand systems more quickly, test ideas more thoroughly and deliver certain types of work more efficiently.

What it does not do is remove the need for judgement. As Ben puts it, the best engineering practices still apply, and in many cases, they become even more important when AI is involved.

Looking ahead, the role of AI in legacy modernisation is likely to evolve quickly. The organisations that benefit most will not be the ones that adopt it fastest, but the ones that use it most thoughtfully.

In that sense, AI does not change the goal of modernisation. It changes how effectively that goal can be achieved, provided the focus remains on building systems that genuinely work for the people who rely on them.

Learn more about our public safety and defence expertise and how Made Tech can help your organisation.

The post AI is an accelerator, not a shortcut, when tackling legacy systems appeared first on Made Tech.

What does a typical morning look like? 

As a student, it’s important to gain a variety of skills during your college years to help prepare for adulthood. Being part of the Made Tech team has allowed me to experience so much and every working day is different, where I am consistently learning something new. Starting a work placement as a student can feel both exciting and nerve-wracking, but each day brings new opportunities to learn and grow. 

I typically start my day at 9:30am, whether I am working online or in person. I begin by checking my emails and Slack for any updates, which helps me stay organised and prepared for the day ahead. We usually start our morning with a catch-up session, where we talk about what we’ve done over the week. At the end of each week, we complete a journal and an evaluation reflecting on the skills we develop.

What was the most surprising thing you learned about working in tech? 

One of the most surprising things I learned about tech is how much teamwork is involved. Teamwork and collaboration are essential to share ideas, fix problems and meet deadlines. 

What advice would you give to the next group of students?  

For the next group of students, I would advise them to be confident and ask questions. At first, it can feel intimidating being in a professional environment; however, everyone understands that you’re here to learn. At MadeTech, one of the key values is continuous learning, whether it is a personal skill or a technical one. I would also advise staying organised and managing your time well. At first, it may feel overwhelming balancing work, college, and personal life, but remember you can always speak to your manager and teachers for support. 

Overall, my experience here has been extremely valuable. I have developed many personal and technical skills through programming projects such as the NASA Space Apps Challenge, which gave me a better understanding of how collaboration works in a real programming environment. The skills I’ve developed through those projects have helped me perform better in my end-of-year exam and will continue to support me in my future career.

The post A day in the life of a T-level student – Laura appeared first on Made Tech.

What does a typical morning look like? 

There is never really a typical morning for us, each week there’s a new exciting project, whether it’s with the DfE, coding alongside apprentices or even writing blogs like this one! But even with the change in tasks, most mornings start with a quick meeting with our supervisor, Dom.  Before we jump straight into work, we usually play a short game together to get settled and make the rest of the day feel a bit lighter. It’s a nice way to ease into the work. 

After the game, we have a catch-up session on what we did the previous week and what awaits us in the following week. It is also recommended to take lots of breaks throughout the day. I then spend some time writing in my journal. This is where we reflect on what we did that week, what we learned, what we want to learn next, and any worries or concerns we may have. This helps me keep track of my progress and reflect on it as part of my development. 

What was the most surprising thing you learned about working in tech? 

The most surprising thing for me was how collaborative everything is, not just sitting at a chair doing independent work that drains the life out of you, but instead, I find myself constantly pairing up on code and discussing ideas. This opened my eyes to how much I misunderstood what tech is; it isn’t just about writing a bunch of code, it’s communicating with others and solving problems together. 

Whilst working on my project of designing and building a simple assessment system for teachers, I realised I wasn’t just learning HTML, CSS, Flask or SQL, I was learning what it’s really like in a junior product designer’s shoes. I was able to pick up on what the user wants/needs to ensure a smoother user experience for a non-technical audience.  

What advice would you give to the next group of students? 

My advice is to find a routine that works best for you. Both college work and  your responsibilities tend to pile up quickly, making you feel overwhelmed.  If you can’t manage your time well, then try different ways to see what fits you. And honestly, if u end up doing things last minute (not recommended,  but we’ve all been there), make sure you still try your best.

The post A day in the life of a T-level student – Taybah appeared first on Made Tech.

Spend any time inside a policing or justice organisation and you start to see the same patterns. People switch between systems, copy information from one place to another, and rely on spreadsheets just to build a complete picture. None of it feels deliberate, but it has quietly become the way work gets done.

That is what technical debt looks like in practice. It is not an abstract IT issue, but something that shapes the working day and slows people down. In already stretched environments, that friction quickly becomes a real problem.

The instinct, when things get this tangled, is to start again. Replace the systems, wipe the slate clean, and build something new. It sounds decisive, but it is rarely the safest or most effective option.

In many cases, the better approach is more measured. Modernisation does not have to mean starting from scratch, and new does not automatically mean better. The organisations seeing the most success are often the ones improving what they already have, rather than replacing it wholesale.

What technical debt really looks like

Ask people to define technical debt and you will get a range of answers, but Ben Pirt, Principal Technologist at Made Tech, puts it simply. “It ultimately just looks like code that you can’t really maintain. Once systems reach that point, everything becomes harder, from making small changes to finding people who understand how things work.”

Ben adds: “What is often overlooked is that age is not the only factor. Some systems have been running for decades, while others are only a few years old but already difficult to work with.

“I think the issue comes from neglect, whether that’s over a long or short timescale. Most systems were built with good intentions, but as standards move on and expectations change, they are not always updated to keep pace. Over time, they drift further away from what users actually need.”

Where legacy systems hit hardest

That gap tends to show up most clearly in frontline roles. Geraldine Mathews, Made Tech’s Client Partner, describes environments where caseworkers move constantly between systems that were never designed to work together. Each system does its own job, but there is no single view, so people are forced to piece information together themselves.

“If you wanted to know one thing, you logged into that system. For something else, you logged into another, and never the two should meet. The result is duplication, repetition and a steady loss of time. Users just want IT to work for them, be intuitive and solve the whole problem,  often in difficult and complex situations.”

Geraldine continues: “They really just want to be sitting down, looking someone in the eye. IT should support that work, not take time away from it.”

Part of the reason this situation develops is structural. In the commercial world, products improve because organisations compete for users. In government, internal systems do not face that same pressure, so once they are delivered, they can remain unchanged for years.

“They’ve got to be maintained,” Ben explains. “Without that natural incentive to evolve, systems tend to stagnate. Over time, workarounds build up and the gap between what the system does and what users need continues to grow.”

Why evolution beats replacement

At that point, a full rewrite can seem like the obvious answer. It offers the promise of a clean start and a chance to fix everything in one go. In reality, it introduces significant risk, especially when the existing system is still handling critical work.

There is also the challenge of understanding what the system actually does. In many cases, documentation is limited and knowledge has moved on. Switching everything off and replacing it in one step leaves very little room for learning or adjustment.

A more practical approach is to evolve the system in place. That does not mean preserving everything, but it does mean understanding it properly before making changes. As Ben puts it, “It’s not a legacy IT problem,” and starting with technology alone misses the point.

The first step is to understand how people use the system today and where it causes friction. That means combining technical analysis with user research and service design. Only then does it make sense to decide what needs to change and how to change it.

Reducing risk without stopping the service

Risk is always part of the conversation, especially in services that handle large volumes of sensitive data. The way change is delivered makes a big difference here. Incremental approaches allow teams to test, learn and adjust before committing fully.

Ben describes work on a system where the team analysed existing behaviour, then tested a new version against real data. They ran both systems in parallel and gradually shifted usage across, monitoring the results as they went.

“We compared it against millions of real examples,” he says. “In some cases, we even discovered issues in the original system that had gone unnoticed.” The transition itself was so smooth that “no one noticed”, which is often the best possible outcome.

This approach also brings users into the process earlier. Instead of delivering something new at the end of a long project, teams can show progress as they go and gather feedback along the way. That creates a stronger sense of ownership and improves adoption.

For people who have used the same systems for years without being consulted, being involved makes a real difference. It turns change into something they are part of, rather than something that happens to them.

Dealing with uncertainty

One of the challenges with this kind of work is uncertainty. Legacy systems often contain hidden dependencies and behaviours that only become visible once you start digging into them. That can make it difficult to define exact timelines and costs upfront.

“There are huge amounts of unknowns,” Ben says. “The most effective projects tend to acknowledge that reality rather than trying to plan around it. They rely on experienced teams who can adapt as new information emerges.”

There is also a growing recognition that technical debt is not just an operational issue. As systems age, they can introduce security risks as well. The longer technical debt is ignored, the harder it becomes to address. What starts as an inconvenience can gradually turn into a barrier to change and, in some cases, a source of real risk.

This all points towards a more balanced view of modernisation. It is not about defending legacy systems, but it is not about discarding them either. The goal is to improve what exists in a way that is controlled, sustainable and grounded in real needs.

That approach can reduce costs by extending the life of existing systems, while improving performance where it matters most. It also lowers risk by avoiding disruptive, all-or-nothing change.

For organisations working in policing, justice and across government, that is often the more responsible path. It delivers progress without unnecessary upheaval, and it keeps the focus where it belongs, which is on the people using these systems every day.

Learn more about our public safety and defence expertise and how Made Tech can help your organisation.

The post Modernising the legacy estate: reducing technical debt without starting from scratch appeared first on Made Tech.

Phase 2 is coming later in 2026. And it’s going to be harder.

Not just because there are more hazard categories. But because the nature of those hazards means the way providers have to respond is fundamentally different. The teams involved, the processes required, and the decisions that need to be made won’t map neatly onto anything most housing organisations already have in place.

Here’s what you need to know.

What is Awaab’s Law?

Awaab’s Law was introduced through the Social Housing (Regulation) Act 2023 following the death of two-year-old Awaab Ishak from prolonged mould exposure.

The regulations require landlords to investigate hazards in their tenants’ homes, provide written updates,  and commence any required follow-on works within strict timeframes.

Phase 1 brought damp and mould, and emergency hazards into scope. For emergency hazards, most providers already had a process of sorts – typically an emergency “make-safe” process. Phase 1 largely added formal timeframes and documentation obligations around something that already existed (to a greater or lesser extent – depending on the provider) 

Phase 2 extends those same obligations to a wider set of hazard categories from the Housing Health and Safety Rating System (HHSRS). A firm implementation date has not yet been confirmed – it is subject to secondary legislation – but government guidance points to later this year. Phase 3, covering the remaining HHSRS hazards, follows in 2027.

Which hazards does Phase 2 cover?

What Phase 2 means for social landlords

1. The admin burden is going to get heavier

The government estimated that Phase 1 would cost the social housing sector £129 million in additional staffing alone. When providers were consulted on whether that figure was accurate, 63% said it was an underestimate.

That’s before Phase 2 adds five new hazard categories to the workload.

Providers who have found Phase 1 stretching their capacity are about to take on more work. For each of these new hazard categories, the same work is required: investigations actioned and recorded, timeline documentation, written tenant communication, and remediation planning.

The Housing Ombudsman’s caseload tells the same story. Determinations rose 30% in 2024-25, and over 40% of all compensation ordered that year related to failures around damp and mould – hazards that have been in scope for years. If the sector is still struggling with the original obligations, adding five more hazard categories without a step-change in how cases are managed will only make the situation worse.

If you’re already feeling the weight of Phase 1 compliance, Phase 2 doesn’t give you breathing room. It raises the floor.

2. These hazards aren’t all your repairs team’s problem

Damp and mould – however complex – is something most repairs and maintenance teams had some version of a process for. There were SLAs. There were contractor relationships. There was at least a general sense of who owned it.

Excess cold, structural instability, domestic hygiene failures – these don’t sit cleanly in a repairs workflow. They’re more likely to land with building safety teams, compliance functions, or neighbourhood and housing offices. Some will require specialist contractors. 

The people who got your social landlord through Phase 1 may not be the right people for Phase 2. And the people who are the right people may not know that yet.

3. Preparing for Phase 2 needs an operational owner

The cross-functional nature of Phase 2 means the preparation work doesn’t belong to any one team by default. Designing a process that spans repairs, building safety, compliance, neighbourhood housing, and specialist contractors — and then standing it up so it actually runs — is a substantial piece of work in its own right.

It needs someone who owns it. Not governance oversight. A named lead whose job is to design the process, get the right people across it, and make sure it runs consistently once Phase 2 lands.

Without that, the reality is you’ll find yourself trying to pull it all together at the last minute. Processes that haven’t been properly designed. Teams that haven’t been properly briefed. Cases that fall through the gaps because nobody agreed who was responsible.

With Phase 2 adding five new hazard categories, there are simply more things that can slip. More places where an unclear process means a missed deadline. More cases where the wrong team owns the response — or nobody does.

Phase 2 is more complex than Phase 1. The cost of not having a clear owner this time is higher.

4. You’ll need policies that might not exist yet

Some of the hazards in Phase 2 will force decisions that providers haven’t had to make at scale before.

The most significant is relocation. When a property is assessed as presenting a serious risk from excess cold, structural instability, or fire, what happens to the tenant? What are your criteria for a temporary move? What’s the process for managing that, communicating it, and evidencing it?

At the volume that Phase 2 is likely to generate, an improvised approach won’t hold.

What to do before Phase 2 arrives

You don’t need to wait for a confirmed implementation date to start preparing. The hazards are known. The direction is set. Here’s where to focus now:

• Audit your team structure. For each Phase 2 hazard category, who in your organisation would own the response? Is that clear? Do they know?
• Identify your process gaps. Where Phase 1 required you to build a new process, Phase 2 will require more. Map what you have. Name what you don’t.
• Define your relocation criteria. Don’t leave this until a case forces the issue. A short internal policy – what triggers a relocation, how it’s approved, and how it’s documented – will save significant time and protect you legally.
• Assign a programme lead. Ideally, someone with the authority to convene the right teams and the mandate to make process decisions.

How Made Tech’s case management software helps

The thread running through all of this is coordination. Phase 2 compliance isn’t just an operational challenge – it’s an organisational one. The right people need to know what they’re responsible for. Cases need to be tracked across teams and contractors. Deadlines need to be visible. Evidence needs to be captured consistently.

Our Hazard Case Management software is built for exactly this. It gives housing providers a single place to manage hazard cases from ‘becoming aware’ through to resolution – tracking deadlines, coordinating across teams, capturing tenant communication, and generating the audit trail that Awaab’s Law requires. It integrates with existing housing management and repairs systems, or works standalone.

If you’re thinking about how to get your organisation ready for Phase 2, we’d be happy to show you what that looks like in practice and share what we’ve learnt from phase 1. 

The post Awaab’s Law Phase 2: What it covers and what housing providers should be doing now appeared first on Made Tech.

This post is part of our Delivering Public Safety Outcomes at Pace series.

A few standout digital services have changed what people expect from technology. Whether that’s Uber reducing the friction of booking a ride, Netflix recommending the next big Korean hit or Amazon recommending the must-have accessory to complement your last purchase, today’s digital world feels simple and intuitive.

Once people get used to that kind of experience, it quickly becomes the benchmark for everything else they use and public services are no exception.

For teams delivering vital services, that shift in expectation creates a difficult balance. Citizens and businesses want services that feel quick and easy to use. At the same time, public sector delivery sits alongside policy requirements, operational realities and tight budgets. According to Sarah Ward, Delivery Director at Made Tech, designing around user needs is not about ignoring those constraints, but is about navigating them carefully while still building something people will actually use.

User needs meet policy and operational reality

One of the biggest challenges is often cultural rather than technical. Many public sector organisations still carry the memory of large IT programmes that ran over budget or failed to deliver what they promised. Those experiences continue to shape how new services are approached today.

“Our customers are still scarred by decades of IT delivery challenges,” Sarah says. “They still struggle with the concept of a minimum viable product that is then iteratively delivered and improved.”

Launching something that is not yet fully complete can feel risky in that environment, particularly when funding cycles are structured around fixed annual budgets. Departments worry that if something launches unfinished, the money will disappear and they will be left with a half-built system. The key, however, is to consistently build and demonstrate the value creation that the product and service bring to citizens.

James West, Made Tech’s Industry Director for Public Safety, Security and Defence, believes part of the answer lies in rethinking how digital services are viewed in the first place. “Too often services are treated as large, one-off programmes rather than products that evolve,” he says. “The service design and the product you build are never finished. Ultimately, you’re balancing the needs of citizens, what the service users need and what government can actually afford. These decisions continuously change over time, and that is right.”

That balancing act is the inflection point where many of the real delivery decisions happen. Policy teams may define the outcome they want to achieve, but translating that into a service that works for real users requires constant adjustment. James argues that the traditional model, where policy defines the requirements and then hands them over to delivery teams, often creates friction.

“Policy do their bit, then they fence it over to delivery,” James says. “And there’s a constant to and fro between the two sides.”

For James, the answer is not more process but closer collaboration, with digital thinking embedded much earlier in policy design.

Why early delivery matters

Even when teams agree on the approach, releasing something early can feel uncomfortable. Sarah recalls one project where an organisation agreed to launch a new digital service even though it did not yet match every feature of the system it was replacing.

“I think trust is huge,” Sarah says. “That’s the only way we got through it.”

The decision was not universally popular. As feedback started coming in, stakeholders questioned whether the organisation had moved too quickly.

“They did wobble,” Sarah says. “They nearly rolled back because they didn’t like the negative feedback. This is where experience, guidance and trust with proven operators really come to the fore.”

But launching early also revealed something not highlighted during user research. Once users started interacting with the service, one request kept appearing in the feedback.

“One of the things users really valued was widgets on their phone,” Sarah explains. “That hadn’t come up in any of the research we’d done.”

Because the service had been released to a small group first, the team could respond quickly. The team built a simple widget over a short sprint cycle and released it before the full rollout.

“That’s the value of launching early,” Sarah says. “If we’d waited, we wouldn’t have known.”

For James, examples like this illustrate why approaching programmes differently enables success. “When projects become too big – or the delivery partner is too big – they slow down decision-making and make it harder to respond to what users actually need.

“Big doesn’t mean best,” James says. “Big usually means status quo.”

Adoption is the real test

Ultimately, the success of a service is not defined by the scale of the programme that created it. It is defined by whether people choose to use it.

That is why listening to users once a service launches is so important. On one project, Sarah and the delivery team received thousands of pieces of feedback from people using the service. The Data and Insights team was prepared and quickly grouped the feedback, which was used to prioritise improvements.

“We could say we’ve heard you,” Sarah explains. “Here are the top things people are asking for, and here’s when they’re coming.”

This kind of transparency helps build confidence while services continue to develop.

Process or impact?

For James, there is also a broader question about how the UK approaches digital delivery in government. James believes departments sometimes prioritise process and safety over impact.

“We are now in a world where the speed of technology change requires leaders to act with more entrepreneurial spirit in service delivery, while acknowledging regulation and guardrails to ensure public trust is maintained,” he says. “We need to operate as leaders, not managers, to create a thriving future.”

That cautious mindset can slow progress at a time when expectations continue to rise. According to James, other countries have moved faster by treating digital services as ongoing products rather than fixed projects. It is, however, fair to acknowledge that some countries cited as examples don’t have the same issues around legacy debt that we have in the UK.

He does, however, believe that effective progress is still possible if organisations focus on outcomes and impact. “Start smaller, build the minimum viable product, release it and learn from it,” he suggests. “You might get some things wrong, but the overall cost will be lower and the service will improve faster.”

For Sarah, the practical advice is straightforward. “Be clear about the outcome you want to achieve. Define what a minimum viable product looks like. And be honest about what will come later. 

“Don’t be afraid to go with a minimum viable product. You learn so much once people actually start using it.”

Designing services around user needs does not mean ignoring the realities of government. It means working within them while keeping the focus firmly on what matters most.

James concludes by providing a trio of key takeaways that will drive technology change and enable leaders to put citizens and businesses at the heart of public services:

1. Policy is Digital and Digital is Policy: the two areas need to align further for future success
2. Adopt a product thinking approach to service delivery
3. Accelerate delivery and bring users closer via fast sprints and feature releases

“This is about leadership. Be clear on the outcome, give teams the space to deliver and stay close to what users actually need. If you do that, everything else starts to fall into place naturally.”

Learn more about our public safety and defence expertise and how Made Tech can help your organisation.

The post Putting citizens and businesses at the heart of public services appeared first on Made Tech.

Recently, I found myself in an unfamiliar position. I’d done thorough research, validated the findings, and used AI appropriately to synthesise a large volume of data. And yet, when I presented the work, it didn’t land in the way I expected.

The issue wasn’t the quality of the insights. It was the story I told with them, and how subtly that story had been shaped by the tools I used along the way.

This is a reflection on using AI in research storytelling: where it helped, where it quietly constrained my thinking, and what I’ll do differently next time.

The context: lots of data, sensible intentions

I’m currently working on a programme integrating a new off-the-shelf online data management system. As part of this work, I conducted research with two different internal stakeholder teams, as well as external users of the existing process/system.

The aim was to understand the “as-is” experience in full detail: the challenges, how they showed up across teams, and how they played out across the end-to-end journey.

The interviews returned a lot of data. Rich, nuanced, and detailed. The kind of dataset that’s incredibly valuable and slightly intimidating.

Where AI genuinely helped

This is where AI did exactly what it promised.

I used it to help:

• Synthesise large volumes of qualitative data
• Identify recurring themes and patterns
• Surface challenges across the end-to-end journey

It gave me speed, confidence, and reassurance that key insights weren’t being missed. I mapped the findings out across the “as-is” journey on a MIRO board and structured a report that presented challenges by each stage of the process.

At the outset, this felt entirely reasonable. Logical, even. If the team could clearly see where the pain was occurring, they could start to address it.

The problem I realised too late

As I moved into report writing – and later, presenting the findings – I could feel something wasn’t quite right.

The work was thorough.
The insights were accurate.
The facts were checked.

And yet, the findings felt repetitive. The narrative felt flat. Instead of a clear articulation of the big issues, the audience was being taken through a long list of challenges without a strong sense of what really mattered or how it all connected.

This was unusual for me. I’ve always considered storytelling a strength when presenting research. Normally, I move from synthesis on a MIRO or Mural board into a deck with relative ease, shaping insights into a narrative that helps teams think and act differently.

This time, that flow wasn’t there.

The subtle trap of AI-assisted structure

After the session, I spent time reflecting on what I’d done differently.

The key difference wasn’t the project or the complexity of the work; it was my starting point.

This time, I began with two detailed word reports that AI had helped me generate, outlining challenges by process stage. That’s not how I usually work. In the past, I’ve tended to move straight from visual synthesis into storytelling, shaping the narrative myself as I go.

Instead, I found myself reacting to a structure that already existed.

The structure made sense. It was coherent and comprehensive. But it wasn’t necessarily the story that needed to be told.

This is where AI can quietly lead you down a path you didn’t consciously choose:

• It produces a logical, complete structure
• That structure feels “right,” so it goes largely unquestioned
• You start optimising within it, rather than stepping back and reframing

Fact-checking didn’t solve this, because the problem wasn’t accuracy – it was meaning.

Why checking the facts isn’t enough

Everything in the report was correct.
That didn’t make it effective.

Good research storytelling isn’t just about describing what’s happening at each step of a journey. It’s about:

• What really matters
• What connects issues together
• What explains why things are breaking down
• What decision-makers actually need to understand

AI is excellent at surfacing what.
It’s far less capable of deciding so what.

That still requires human judgement, context, and a point of view.

Going back (and reframing the story)

I went back to the findings and reworked them into a shorter report with a very different structure. Instead of following the process end to end, it focused on a clear narrative about the core issues shaping the experience overall.

The result was:

• Shorter
• Clearer
• Easier to follow
• More actionable

In the process, I created two detailed Word reports, a needlessly long deck, and finally the report I should have produced at the outset.

That’s not time I’ll get back, but it is a lesson I’ll take forward.

What I’ve taken away

A few reflections I’ll be carrying with me:

1. AI is extremely helpful in making sense of complexity
   Especially when working with large volumes of qualitative data and needing confidence that key themes haven’t been missed.
2. The biggest risk isn’t over-reliance, it’s unexamined influence
   I didn’t outsource my thinking to AI, but I did allow an AI-generated structure to become the default frame for the story. That influence was subtle, logical, and easy to accept, which is exactly why it’s worth paying attention to.
3. Accuracy alone doesn’t create insight
   Everything in the report was correct. That didn’t make it coherent, compelling, or easy to act on.
4. Storytelling requires conscious human framing
   I was using my judgement throughout, but I wasn’t always aware of how my framing had been shaped upstream. The lesson wasn’t to “use my brain more,” but to pause earlier and ask whether this was truly the story I wanted to tell.

AI didn’t weaken this work, but it did make it easier to follow a path I wouldn’t have consciously chosen.

What I’ll do differently next time

• Use AI heavily for synthesis, but pause before locking in any AI-generated structure
• Sense-check the narrative before writing detailed reports or decks
• Ask: “If I had to explain this in three slides, what’s the story?”
• Separate process mapping from insight storytelling more deliberately
• Treat AI outputs as prompts, not starting points

AI can help you find the insights, but it’s still up to you to decide which story is worth telling.

The post When AI gets in the way of the story appeared first on Made Tech.

Why does this happen? Developing a data strategy is often treated as a one-off project or a purely technical exercise rather than a continuous, human-centred effort. Below, we explore some common pitfalls that can undermine a public sector data strategy and how to overcome them.

Common Pitfalls in Public Sector Data Strategy

Treating Strategy as a Document Instead of a Practice

It’s a mistake to focus on writing a “perfect” data strategy document and assume that alone will ensure success. In reality, a strategy that just sits on a shelf delivers no value unless people actually use it. A data strategy’s worth is measured by the actions and changes it drives, not by the weight of the document.

Overlooking People and Culture

Another common pitfall is fixating on technology while neglecting the human factor. Without the right skills, mindset, and data-friendly culture, even the best technology will fall flat. Successful data initiatives require investing in your people by building data literacy, encouraging collaboration, and getting buy-in at all levels. People are ultimately the ones who turn data strategy into real results.

Lack of Clear Purpose or Alignment

A strategy without a clear purpose or audience can become an academic exercise detached from reality. If it’s not clear who will benefit from your data initiatives or what value they will derive, the strategy will likely have little real impact. Ensure every data project is tied to a specific user need or organisational goal. A user-centred, mission-aligned strategy rallies support and delivers tangible outcomes because everyone can see the “why” and the “who” behind the effort.

Treating Data Strategy as One-Off, Not Ongoing

It’s tempting to consider your data strategy “done” once the document is published. In truth, a data strategy must be continually revisited and refined. The data landscape, public needs, and technologies are always evolving. If you treat your strategy as static, it will quickly become outdated. Instead, approach it as a dynamic, ongoing process (as Gartner puts it, a “highly dynamic process… in support of business objectives”). Regular reviews and updates will keep your strategy relevant and effective as conditions change.

From Pitfalls to Progress: How to Build a Successful Data Strategy

Avoiding the pitfalls above requires a holistic approach – one that combines people, process, and technology, and treats the strategy as a journey rather than a destination. Here are some steps public sector digital leaders can consider to turn a stalled data strategy into real-world progress:

Understand Your Starting Point (Data Maturity)

Before plotting where to go, you need to know where you are. A Data Maturity Assessment evaluates your organisation’s current data capabilities and highlights gaps in skills, processes, governance, or technology. At Made Tech, we often begin with this step – mapping out your data maturity provides a baseline and helps create a realistic roadmap for progress.

Align Strategy with Mission and Users

Audit your current data landscape and clarify your goals so that your data strategy directly supports your organisation’s mission and the needs of its users. Every project or initiative should tie back to a clear business objective or user outcome. At Made Tech, we collaborate through Data Strategy Support to help public sector teams define a clear vision and an actionable plan aligned to their purpose. This ensures the strategy is practical and focused on delivering value from day one.

Get the Right Technology and Architecture

Even a great plan can stall if your technical foundations can’t support it. It’s important to review whether your data infrastructure is fit for purpose – for example, ensure your data pipelines and storage solutions are modern and scalable, and that the right people have access to analytics tools. A thorough Technology and Architecture Review will highlight any gaps so you can address them early. By shoring up your tech stack, you ensure technology doesn’t become a bottleneck to your strategy’s success.

Invest in People and Skills

Technology alone can’t deliver a data-driven transformation – you need to empower the people behind it. Upskill your staff through training and mentoring so they have the confidence and capability to work with data effectively. Encourage a “one team” culture where technologists and domain experts collaborate closely. When people feel supported and see data making their jobs easier, they become champions of the strategy.

Establish Strong Data Governance and Ethics

Maintaining public trust is essential. Build governance into your strategy from the start – ensure privacy, security, and compliance (e.g. GDPR) are properly managed. Set clear policies, data quality standards, and access controls. Good governance not only prevents missteps but also builds confidence that data is handled responsibly. With the right framework in place, your organisation can innovate while staying within legal and ethical bounds.

Map Your Data Ecosystem

Public sector data environments are often complex and siloed. By visualising how data flows between teams and systems (using tools like the ODI’s mapping approach), you can uncover hidden bottlenecks and identify key data sources, stakeholders, and dependencies. This big-picture view highlights where processes could be streamlined or where risks (like bottlenecks or compliance gaps) exist. Ultimately, mapping your ecosystem leads to better oversight and more informed decisions.

Embrace Continuous Improvement and Innovation

A data strategy isn’t static – it should evolve with new learnings and changing technology. Once you have a solid foundation, you can explore advanced analytics or AI in a controlled, mission-aligned way. Keep treating your strategy as an ongoing journey: regularly review progress, measure outcomes, and be ready to adjust course as needs change. This commitment to continuous improvement ensures your strategy stays relevant and impactful.

Driving Data Success

Building a data-driven public sector organisation is no small task – but you don’t have to tackle it alone. At Made Tech, our 450+ experts have helped many public sector organisations navigate this journey, from assessing data maturity to implementing cutting-edge solutions. We work shoulder-to-shoulder with civil servants to build capability and deliver lasting outcomes.

Ultimately, a data strategy is not just a document – it’s a living program of change. By avoiding the common pitfalls and focusing on people, purpose, and continuous improvement, you can unlock the power of data to improve public services. If you’re ready to accelerate your organisation’s data journey or revive a stalled initiative, we invite you to explore Made Tech’s Data & AI services.

The post Unlocking the Power of Public Sector Data by Overcoming Common Strategy Pitfalls appeared first on Made Tech.

I’ve always been taught to use the Testing Pyramid¹.

The basic idea is to write the most unit tests, as they are the smallest in scope and fastest to run. Then you write fewer integration tests, which are larger in scope and slower to run, before you finally write an even smaller number of end-to-end tests, which are the largest in scope and slowest to run.

I’ve always been taught to use Test Driven Development²³ (TDD).

The basic idea of this is that you should write your tests before you write any code. Your tests codify the required behaviours of the software you then write, giving you an easy way to know when the feature you’re working on is complete. This should also document the context of the code you’ve written, making future changes theoretically easier.

But I keep observing common issues with unit testing on the digital delivery teams I’ve worked with over the past several years.

Recognise either of these from projects you’ve worked on?

Problem 1: Lack of test confidence – Your application fails when you deploy it, despite all the unit tests you’ve written for the change you’re making and high test coverage.

Problem 2: Testing stalls change – You make a simple change to your code, but you then need to totally restructure lots of unit tests in order to do it.

Problem 3: High cognitive load – You want to understand the behaviour of a section of your codebase, but reading the unit tests provides little help.

I’ve observed these problems dozens of times and they’ve always frustrated me because they seem to directly oppose the entire point of testing!

I believe good testing provides several significant benefits in software delivery:

1. Good tests should give us confidence in the correctness of our changes
2. Good tests should allow us to make changes more quickly
3. Good tests should document how our system behaves

Introducing the Testing Trophy

The culprit is the Testing Pyramid. It’s outdated and obsolete.

I’d like to introduce you to the Testing Trophy⁴⁵⁶ as a replacement. This is also sometimes known as the Testing Vase or Testing Honeycomb, but it’s essentially the same thing.

Integration tests are now the widest layer

The goal of these tests is to codify business logic. This typically means each test maps to either an individual acceptance criterion or an obvious, easy-to-understand part of a user journey.

For example, if your user journey is “to allow users to log in and check their health records”, you might have an integration test to check they can log in, another to check that a logged-in user can access their health records, and a third to check that a person’s health record displays the correct information.

Integration tests shouldn’t really care about the internals of your code. In theory, if you re-wrote your codebase in a new language, you should still be able to run the existing integration tests with minimal change needed.

Integration testing also avoids some of the common problems attributed to end-to-end testing – extremely long, brittle tests which fail intermittently. By splitting these long journeys up, integration tests are more reliable.

To address the three problems described above (lack of test confidence, testing stalls, and high cognitive load), I recommend migrating the bulk of your unit tests to integration tests.

End-to-end tests stay very thin

The goal of end-to-end testing is to ensure your application works as expected in an environment that closely replicates the production environment. In other words, they’re infrastructure tests. Only a few of these tests are needed, and they should cover complete user journeys.

To keep your end-to-end testbench manageable, it needs to rely on the presence of your integration testbench. This means you can keep the number of expensive end-to-end tests to a minimum.

Unit testing is now also a very thin layer

There are two goals for unit testing now: exhaustive testing and complex-subsystem testing. Both of these rely on your integration testbench to assert that your codebase actually works in a general sense, and only test very specific functionality that would otherwise slip through the cracks.

Exhaustive testing is for when you want to test all possible values or combinations within a feature. You could integration test the “common” combinations to check that the code works overall, but you could then add a unit test that would loop through every possible single value or combination of values to ensure they all still work.

For example, imagine you’re building an online shop, and you have integration tests that verify that users can successfully purchase green paint. Exhaustive unit tests could build on this to ensure the paint is also available in the 100s of other colours your shop offers.

Complex-subsystem testing is for when you have an isolated nugget of complexity in your codebase that you want to test in isolation. Because it has many edge cases and is complex, highly focused unit testing is important to ensure it works correctly. In essence, this pattern uses the same philosophy as integration testing our services as opaque boxes – just zoomed in to treat a specific class, module, or function as an opaque box instead.

For example, I once wrote a set of complex-subsystem unit tests for a smart rate limiter I was working on. You could integration test that the rate limiter works for several examples in the wider context of the application it lived within, but then add unit tests on top of this for every edge case you can think of for just the rate limiting logic.

Linting/Static analysis is the new base layer of the model

The goal of this layer is simply to speed up our ability to write quality code and tests. By using automated tools, we can catch more careless errors without having to test for them specifically.

And that’s the Testing Trophy!

What does this look like in practice though?

But what about the real world? It’s all well and good to evangelise a theoretical testing model, but how would you go about applying this to a real project you’re working on?

Below are some examples of common queries, and how I’d approach addressing them.

“I’m on a project with an OO codebase and lots of unit tests for each class. How can I introduce integration testing?”

• You can probably use your existing test runner (jest, junit, pytest, etc.) and extend it with tools like Localstack, Wiremock, or Test Containers.
• You can then write integration tests which read like chunks of a user journey or individual acceptance criteria. Something like “I want to allow users with an existing account to log in” or “I want to reject users who log in with the wrong password”. This is often referred to as Behavior Driven Development (BDD).
• You can convince your team with working code examples to back up what you’re saying. Hopefully, it shouldn’t take them long to see that writing a handful of integration tests with very few mocks saves them considerable time and effort!

“I’m working on a frontend using a modern JS framework. What does the testing trophy even look like for this codebase?”

• Render the entire app (and spin up any backend services) and use tools like Cypress or Playwright to end-to-end test full user journeys (e.g., logging in, adding a product to the basket, checking out, and requesting a refund).
• Render each page and click through multiple components to integration test. These tests should naturally make sense as parts of a user journey (i.e, a login flow).
• Render each significant visual component and verify that it renders correctly on screen during unit testing (exhaustive unit testing). You can also use tools such as Storybook or Chromatic to help with this.
• Render each complex (think lots of gnarly state logic, etc.) component and run through edge cases (complex subsystem unit testing).

“Our team has an end-to-end testbench which has all of our user stories in but is flakey, expensive to run, and breaks all the time. How do we fix this?”

• Is your entire end-to-end test stack running in a production-like environment? If not, fix this first! Even if it means you’re no longer able to run these tests locally, that’s an acceptable tradeoff.
• Are your tests actually written as full user journeys? Or do they try to do much more, testing edge cases or individual chunks of a user journey? If the test isn’t a full user journey through your system (e.g, I want to buy new shoes → my new shoes are on my feet), it probably belongs as an integration test.

“What’s the problem with just having lots of integration and lots of unit tests?”

• It’s fine to have partially overlapping tests! This is often a good pattern: an exhaustive unit test (the login button renders), an integration test (I can log in), and a larger e2e test (I can log in, buy something, and pay for it).
• If your integration tests are easy to run, can be run locally and debugged, having equivalent unit tests that try to do exactly the same thing is unnecessary, increases cognitive load, and runs the risk of rotting over time.

“My manager/boss says that we should aim for X% code coverage”

• Code coverage has diminishing returns (beyond 70%)⁷. It’s often good at revealing which chunks of a codebase haven’t been tested, but it’s bad at revealing which lines of code you should/shouldn’t be hitting.
• If their focus is on overall system performance, you could consider trialling DORA metrics⁸ within your team or organisation instead.
• They might start to trust you more when your new testbench starts automatically catching issues that the existing unit tests miss. I added a simple end-to-end testbench to a service our team owned, which had previously been very heavily unit-tested. It caught 5 bugs in the first month that would’ve otherwise gone to production without being spotted by the existing testbench.

“Our team has dedicated testers/SDETs, I don’t want to upset them by changing how we test”

• Most organisations employ testers to be test experts, not human computers. Most organisations and testers welcome automation and the increased confidence it brings through better testing.
• Bring them into the conversation early if you can. They’re likely to be highly in favour of new testbenches and better automation! After all, these tools make their jobs easier, freeing them up to focus on more important work like paying down test technical debt or activities like user acceptance testing (putting new stuff in front of actual users).

Annex – The types of tests

I want to take the time to define exactly what I mean when referring to all the different types of tests. In my experience, everyone has a subtly different definition of them – so for the sake of my sanity and your understanding, here are the definitions I’m using⁹¹⁰:

End-To-End (E2E) testing

Sometimes referred to as Functional, Integrated, System, or Smoke testing.

End-to-end tests are typically scoped to Level 1 (Software System) of the C4 model. Of all the tests, end-to-end tests are as realistic as you’re able to get and often need to be run in a production-like environment. These tests typically read like fully complete user-journeys.

External software systems are mocked as needed and pragmatic infrastructure changes are made (for example, running with fewer replicas than the production instance to save on server costs).

End-to-end tests are meant to be wide-reaching and realistic, at the expense of speed and ease of being run.

Integration testing

Sometimes referred to  as Functional, Component or Service testing.

Integration tests are typically scoped to Level 2 (Containers) of the C4 model. Integration tests are the middle child between end-to-end and unit tests, carefully balancing scope, speed, ease of running, and realism. These tests typically read like chunks of a user-journey, or specific acceptance criteria.

Other major components of your software system are mocked out, and tightly-coupled parts aren’t. For example, integration tests for a login API might mock everything except the API, a database storing login credentials, and a queue which login requests are read from. Infrastructure is also often mocked, with tools such as docker, localstack, or lightweight kubernetes clusters being popular choices to only stand up a small handful of tightly-coupled services.

Integration tests are a balance between being closer to reality, treating your software as an opaque box unlike unit testing; and fast and simple to write/run, unlike slower and more brittle end-to-end tests.

Unit testing

Unit tests don’t really go by any other names, but there are a million competing definitions of what constitutes a “unit” of software!

Unit tests are typically scoped to either Level 3 (Components) or Level 4 (Code) of the C4 model. Due to the limited scope of these tests, other classes/modules/functions/objects within the same codebase are mocked as needed.

Unit tests are meant to be quick to write and run, at the expense of scope and realism.

Static analysis

Sometimes also known as linting. Static analysis covers a vast array of tools and automations and can often be found in places like pre-commit hooks, continuous integration pipelines, and even your code editor. This bundles together linters, formatters, type checkers,

Static analysis tools are typically scoped to Level 4 (Code) of the C4 model. They aren’t really “tests” in the traditional sense, but enforce things like code styling and good practices.

Ideally, they should be run as close to code being written as possible for the shortest feedback loop possible.

1. Mark Cohn – Succeeding with Agile: Software Development Using Scrum, 2009 ↩︎
2. https://martinfowler.com/bliki/TestDrivenDevelopment.html ↩︎
3. https://www.madetech.com/blog/messy-software-projects/ ↩︎
4. https://www.wiremock.io/post/rethinking-the-testing-pyramid ↩︎
5. https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications ↩︎
6. https://kentcdodds.com/blog/write-tests ↩︎
7. https://kentcdodds.com/blog/write-tests#not-too-many ↩︎
8. https://www.thoughtworks.com/en-gb/insights/articles/improving-your-bottom-line-with-four-key-metrics ↩︎
9. https://martinfowler.com/bliki/UnitTest.html#SolitaryOrSociable ↩︎
10. https://martinfowler.com/articles/practical-test-pyramid.html ↩︎

The post A pyramid scheme! Have we been unit testing wrong? appeared first on Made Tech.