Owen Hodge

Product Manager

Owen Hodge has been with Headforwards for more than five years. He is a Product Manager currently working with Local Authorities and has more than 10 years' experience working in the software development industry, with roles spanning customer service, operations and product management. He and his wife have a four-month-old baby and a dog called Biscuit and enjoy getting outdoors and exploring Cornwall.


More and more vendors are providing basic and intermediate tools designed to help non-IT personnel create their own apps, systems and automation flows. It’s billed as a way to introduce efficiency and agility into your organisation, and help lighten your IT team’s workload.

The sales pitch for low code and no code may be incredibly slick, but it’s never going to give you the full picture of how the pros balance with the cons. And if you’re going to add citizen development tools to your users’ arsenal, it’s worth knowing everything upfront, rather than encountering a nasty surprise after everyone’s already started building.

So, what are the benefits and risks of citizen development?

The pros

  • You can ease the pressure on your central IT.
    IT teams are constantly looking at a growing list of existing systems that need attention and new systems that need building. By sharing some of the development responsibility with end users, you can help central IT focus on the specialist work.
  • Your end users understand their challenges better than anyone
    Everyone can name at least one stumbling block that gets in the way of their everyday tasks. And when there’s a clear fix – like automating a daily email, for example – it can be faster for your users to solve that challenge themselves.
  • Users can have ownership of their own systems
    It’s universal in organisations: users get attached to the systems they use every day, and they’ll tweak them to fit their own specific needs. It’s how we get the super-tailored Microsoft Excel spreadsheets that teams like finance rely on. Giving users the tools to make those tweaks more effectively can help you standardise while letting your people set up their workflows the way they like them.
  • You can boost employee engagement
    Ownership translates directly into engagement. When employees know their input can make positive changes to the way they work, they’re more likely to get involved with adapting the environment they work in – and once they’re taking a more active role, they’re more likely to stay in their role.
  • You’re less likely to encounter shadow IT
    It’s the universal challenge for central IT: trying to make sure your users aren’t getting their work tools from unsanctioned sources. Users who can build their own specific apps and flows are less likely to download a third-party piece of software to do the job.

The cons

  • Users can build unsupported, business-critical systems
    Citizen development is ideal for small bits of functionality – minor automation flows and basic apps. But if users are developing systems unchecked, you might find a few months down the line that they’ve come to rely almost entirely on an untested app. And if that breaks, central IT will need to help quickly fix a critical system that they’re completely unfamiliar with, without the benefit of code repositories or backups.
  • You risk replacing one bottleneck with another
    User-created apps might ease some of the pressure on professional developers, but without the structure of central IT, that pressure can manifest further down the line. Often, overstretched IT teams find themselves struggling to handle unexpected support requests for user apps, fighting small fires with resources that could be better spent on scheduled development and iteration. There’s also the question of whether your users really have extra time to spend on building apps outside of their everyday responsibilities.
  • Apps and flows are limited by the tools they’re built on
    By their very nature, low-code and no-code tools lack some of the more sophisticated capabilities of a professional-grade development suite, such as integration with central data sources. And that means along the way, some users will find themselves butting up against those limits when they need to add more complicated functionalities to their app. So, central IT will need to weigh in, working outside the limits to tack on extra code. That’s time – and resource – that your teams could use to create a purpose-built solution together.
  • Repeated work can be a knock to overall efficiency
    Some articles credit citizen development with breaking down silos in an organisation. But if you’re not careful, it can just make the issue worse. Without centralised development, people in different departments might end up building near-identical apps and flows to respond to similar challenges, replicating work that could be shared across the business.
  • User-built apps don’t undergo robust checks
    Apps built by central IT have a whole raft of quality controls, rules and regulations to comply with before they get deployed. There aren’t the same checks in place for citizen-developed apps and flows, which means you can’t guarantee security and compliance – and that’s a major concern if those systems are handling sensitive data.

You don’t have to say no to citizen developers

The secret to integrating citizen development practices into your organisation well is safe user enablement. Give your people the tools to build and experiment with apps and flows, but in environments that safeguard them (and your wider environment) from mishaps.

For some of our clients, we set up core IT systems in a different platform from user-developed apps, so they can create in a sandbox-type environment without breaks and outages affecting the rest of the organisation. They have access to some data, but not central data stores, and they have basic integrations that help their apps work alongside the organisation’s other tools.

When you have that environment set up, you can monitor it to ensure you have visibility of what users are building. That way, you can let them know how much support – if any – they can expect, and get them to confirm they understand, so they’re fully informed before they get started.

The main question to ask is whether an app is really suitable for citizen development, or whether it should be built by central IT as part of the strategic plan. If departments have specific or complex requirements, or it’s a tool that would benefit users business-wide, give them the opportunity to have something custom-made and supported by central IT. And for more simple apps and flows, provide a safe environment to let your users have at it – IT are empowering users where appropriate, without creating a support and platform management headache for themselves further down the line.

Want to know more about how we use mobbing to deliver quality software? Get in touch