Microsoft Power Platform and the Rise of Low-Code

Low-Code has been sold as a way for anyone in the organisation to ship software, fast. In practice the picture is more nuanced. Low-Code earns its place on a specific class of problem and falls short on others. This post is an honest look at where it works, where it doesn’t and how we’ve used Microsoft’s Power Platform without overpromising.

Understanding Pro Code

Pro Code is traditional software development: a developer writes code directly, tests it, deploys it. It’s the right model for systems where correctness and performance are non-negotiable: life-critical embedded software, high-throughput infrastructure, anything that touches sensitive data at scale.

The trade-off is investment. Pro Code requires skilled developers, architectural discipline and ongoing maintenance, all of which costs time and money. For organisations whose competitive edge comes from custom software, the investment makes sense. For everyone else, it’s worth asking whether every piece of internal software needs that depth.

The need for development

Most organisations have processes that don’t fit off-the-shelf software. Sometimes the right answer is to change the process; other times the process is the differentiator and software needs to bend to it. That’s where in-house development comes in, and where Low-Code is starting to change the equation.

The question is no longer “should we build?” but “who should build it, and how deep does the build need to go?”

Structuring development for success

Whether you’re using Pro Code or Low-Code, the practices that keep software healthy don’t change:

• CI/CD: releases that are reproducible, automated and small.
• ALM: applications managed across their full lifecycle, not abandoned at go-live.
• QA: tests that prevent regressions, not just catch them.

What changes between Pro Code and Low-Code is how much architecture you have to do explicitly versus how much is implicit in the platform. Skip the architecture step at your peril: projects fail not because the code is wrong, but because no one agreed on the shape of the whole.

The appeal of Low-Code

Low-Code platforms compress the time from idea to running software. A workflow that would take a developer a week to build can be assembled by a business analyst in a day, provided the workflow stays within the platform’s idioms.

The economics matter. Hiring and retaining a Pro Code team is expensive; enabling “citizen developers” within the business inverts the cost curve for a large class of internal workflows. This isn’t a replacement for engineering. It’s a different tool for a different shape of problem.

Understanding Low-Code with Microsoft’s Power Platform

Power Platform (Power Apps, Power Automate, Power BI, Dataverse, Copilot Studio) is Microsoft’s bet on Low-Code at enterprise scale. The strength of the platform is its tight integration with the Microsoft 365 stack: an app built on Power Apps already knows about your tenant’s users, your SharePoint sites, your Dataverse entities. The friction of integration, which dominates traditional development effort, is removed by default.

The risk is the same as the strength. Removing friction means more people can ship more software faster, including software that should never have shipped. Without governance, citizen development produces app sprawl, security drift and a maintenance burden that lands on IT years later.

The misconception of cost and time savings

The pitch of “more software for less money, faster” is true for a specific class of work. It’s not true for software with non-trivial security requirements, complex back-end logic or performance-sensitive workloads. Power Platform handles those badly, not because it’s broken, but because it’s the wrong tool for them.

The discipline is recognising the difference. A leave-request workflow with a four-step approval is a perfect Power Platform candidate. A trading engine, a regulatory reporting pipeline or a customer-facing transactional system is not. The cost saving on the first is real; the attempt at the second is a tax you pay later.

Embracing Low-Code at SPEX

We adopted Power Platform deliberately. The licensing model has surprised us more than once. Features that appear included require Premium connectors or per-app plans that aren’t obvious from the marketing. We’ve learned to scope clients’ Power Platform initiatives against the licensing terms before promising delivery.

The wins, on the right work, are real: weeks-to-days on internal workflow automation, no separate hosting infrastructure to maintain, integration with the Microsoft 365 estate that comes for free. The losses are real too: a Premium-connector dependency that escalates a budget, a citizen-developer app that becomes business-critical with no maintainability plan. We’ve ended up doing both: building on Power Platform where it fits and steering away when it doesn’t.

Citizen vs. professional developer: a double-edged sword

A citizen developer is someone in the business (a finance analyst, an HR coordinator) who builds applications without a software engineering background. The advantage is domain knowledge in the same person as the build: nobody needs to translate requirements.

The disadvantage is the absent disciplines: data modelling, error handling, security boundaries, performance under load, dependency management, what happens when the citizen developer leaves. These aren’t optional concerns. They’re the reason professional developers exist.

The realistic answer isn’t either-or. Citizen developers ship the long tail of internal workflows; professional developers build the foundation (the shared components, the integrations, the governance) that lets citizen development happen safely. Both are necessary.

The role of AI and governance challenges

AI assistants (Copilot inside Power Platform, code generation in Pro Code IDEs) accelerate both modes of development. They also create new failure modes: a Copilot-generated formula that produces wrong results without flagging anything, a generated Power Automate flow that exposes data outside the tenant.

Governance is the answer to both the original Low-Code and the AI-augmented Low-Code: who can build what, who reviews it, where it deploys, what data it touches, how it’s monitored, what happens when the person who built it leaves. The governance question doesn’t change with AI, but the speed at which problems compound does.

Balancing Pro Code and Low-Code

Power Platform is the right answer for most internal-facing workflow software in a Microsoft 365 estate. It’s the wrong answer for customer-facing, transactional or regulated systems.

The judgement call is whether a given piece of software is sufficiently bounded and sufficiently low-risk to ship on Low-Code, or whether the long-term cost of running it on Low-Code exceeds the short-term cost of building it in Pro Code. We get this call wrong sometimes, usually by being too optimistic about a Low-Code candidate that turns out to need engineering depth. But the call is the work.

Conclusion: the role of professional developers in Low-Code

Low-Code doesn’t eliminate the need for professional developers. It changes what they spend their time on. Less hand-coding of CRUD screens; more architecting the foundation that citizen developers build on, governing the platform, integrating with the systems that don’t fit the Low-Code model and being the safety net when something built fast turns out to be load-bearing.

If you’re considering Power Platform adoption, a few honest steps:

• Inventory the problem first. Decide what Low-Code is and isn’t being asked to do.
• Set governance from day one. Retro-fitting governance to a working Power Platform estate is painful.
• Budget for both the platform and the engineering. Power Platform without professional developers is fine until it isn’t.
• Pilot with a high-fit workflow: internal, low-risk, clear ROI. Use the pilot to calibrate licensing and governance.
• Plan for the long-tail. What happens to an app when the person who built it moves on? Decide that before the question becomes urgent.

The path from Pro Code to Power Platform

We’ve spent two decades building software in everything from assembly and C to C# and modern web stacks, and we’ve watched cloud-native architecture change what “shipping software” means. Power Platform (and Low-Code more broadly) is another inflection point in the same direction: more people empowered to ship, with more responsibility falling on the platform team to make that safe.

If you’re navigating that inflection and want a second opinion on where Low-Code fits in your stack, get in touch. We’re always happy to connect and share.