The Microsoft technology stack

Dataverse is the piece most often overlooked and the one that decides whether this works.

The problem this addresses

Is your IT team constrained by budget, skill gaps and a shortage of resource? That combination limits what an organisation can build — and it is the reason low-code and no-code development moved from a curiosity to a mainstream option.

Low-code for the long tail of internal applications that would otherwise never be funded, and traditional development for the systems the business depends on.

What low-code and no-code mean here

Within the Microsoft stack, low-code and no-code describe building applications largely through configuration and visual design rather than by writing everything from scratch.

The distinction matters less than the consequence: people who understand the business process can build a working application for it, and developers are freed for the work that genuinely needs them.

The key technologies

• Power Apps — business applications built without a full development project
• Power Automate — workflow and approvals across systems
• Power BI — reporting and dashboards from the same data
• Dataverse — the shared data layer underneath, which is what stops each app becoming another silo
• Azure — where anything that outgrows low-code goes to live
• Microsoft 365 and Teams — where people already are, which is where the apps should surface

Dataverse is the piece most often overlooked and the one that decides whether this works. Low-code apps built on separate data stores recreate exactly the fragmentation you were trying to escape.

The benefits

• Speed — weeks rather than quarters for a well-scoped application
• Cost, both in build and in the specialist skills not required
• A licence you probably already hold, which changes the business case materially
• Integration, because these tools connect to the Microsoft estate natively
• Governance, since applications built on the platform are visible and manageable rather than being spreadsheets on somebody's desktop

What it looks like in practice

Notting Hill Genesis needed to move off SharePoint 2013 before Microsoft withdrew support for it, as part of a wider move away from on-premises data centres. The migration went straight to SharePoint Online rather than an interim step, chosen against NHG's own strategic direction, existing third-party arrangements and the practical impact on the people who used it daily — the kind of decision low-code tooling doesn't make for you, however good the platform is underneath it.

The honest limits

Low-code is excellent for forms, approvals, tracking and reporting over structured data. It is a poor choice for anything with complex logic, heavy transaction volumes, unusual integrations or demanding performance.

The failure mode is a successful prototype that grows past what the platform handles well, and becomes expensive to maintain and difficult to move. Decide the boundary early: what stays low-code, and what earns a proper build.

Where it fits

For most organisations the answer is a mix. Low-code for the long tail of internal applications that would otherwise never be funded, and traditional development for the systems the business depends on.

That combination is what actually addresses the budget and skills constraint — not choosing one over the other.