Should this be a Power App, or a change to the system we already have?

Our first question is whether Business Central, Dynamics 365 or an existing product already owns the process. If it does, extending it is usually cheaper to run and easier to support. Power Apps earns its place for the process no product owns: inspections, requests, approvals, site data capture, and the work currently held in a spreadsheet.

What does a first Power App usually cost and take?

A focused first app with a real user group is typically a matter of weeks rather than months, and we scope it against a defined process rather than a wish list. We give a fixed shape and a clear boundary before you commit, and we will tell you if the process is not ready to be automated yet.

We already have apps built by people who have left. Can you help?

Yes. We review what exists, what it connects to and what would break if it stopped, then either take ownership, rebuild the ones worth keeping or retire the rest. The point is not to delete other people's work. It is to make sure something the business depends on has a named owner and a support route.

How do we stop this spreading out of control?

Environments, data loss prevention policies, a light approval route and clear guidance on what people can build themselves. Governance should make building easier, not slower. If the process is painful, people go back to spreadsheets.

What about licensing?

It depends on whether the app uses standard connectors or premium ones such as Dataverse, and on per-app or per-user licensing. We model the cost honestly before build, including what it looks like when usage grows, so the licensing conversation does not arrive as a surprise.

Power Apps

The process everybody relies on
and nobody has a system for.

Power Apps is at its best where a real process is being held together by a spreadsheet, an inbox and one very patient person. Built properly, on Dataverse, with an owner and a support route, it becomes part of the business. Built casually, it becomes next year's problem.

How we decide what to build

If the system you already have should do this, we will say so before we quote for an app.

Sound familiar?

Nobody asks for an app.

They ask why the same information gets typed in twice, why an approval took a week, and what happens when the person with the spreadsheet is on leave.

A spreadsheet is running something important
It has tabs, colour rules and one person who understands it.
The process lives in an inbox
Requests arrive by email, get forwarded, and nobody can say what stage anything is at.
Somebody built an app, then left
It still works. Nobody will touch it, and nobody knows what it connects to.
The ERP nearly does it
So people do the last part by hand, outside the system, every single time.
The team on site cannot use the system
The job happens on a phone in a van or on a factory floor, not at a desk.

Where we start

The process first. The app later.

Four steps, in this order. Some of this work finishes at step two, because the platform you already own could do it.

Step 1
Find the process, not the app idea
Who does what today, where it breaks, and what it costs when it goes wrong.
Step 2
Check the system of record first
If Business Central, Dynamics 365 or an existing product already holds it, a new app is the wrong answer.
Step 3
Build the smallest useful version
One process, real users, in weeks. Enough to learn from, small enough to change.
Step 4
Agree who owns it afterwards
Support route, environment, licensing and the person who approves changes. Before go-live, not after.

Whose decision is it?

Pick the person and see the question.

An app only earns its place when somebody with a job to do is better off for it.

Where is work getting stuck between people?

Built-in intelligence

From building screens to shaping the process.

Once the data model and ownership are settled, newer capability shortens the build without changing who is accountable for the result.

Power Apps1 of 4

Describe the app, then edit what comes back.

Copilot can draft screens, tables and formulas from a plain description of the process. The draft is a starting point, not a design, and it still needs someone who understands the business to review it.

What this gives you

Why it matters. Less time on the mechanical first build, more attention on whether the process itself is right.
How we help. We set the data model and permissions first, so generated screens sit on something governed rather than a new island of data.

Availability

Microsoft status: Availability varies by licence, region and tenant settings. We confirm what is actually enabled before designing around it.

Dataverse2 of 4

One place the app can be trusted to write to.

Dataverse gives an app a proper data layer: relationships, security roles, auditing and a supported route into Dynamics 365 rather than a hidden spreadsheet or list.

What this gives you

Why it matters. The information the app collects becomes reportable and defensible, not another silo.
How we help. We model the tables, set the security roles and agree what is master data and what the app is allowed to create.

Power Apps3 of 4

Work where the job actually happens.

Canvas apps run on a phone or tablet, can capture photos and signatures, and can hold work when connectivity drops on site.

What this gives you

Why it matters. The record is created at the point of work, so nobody re-keys it later from a notepad.
How we help. We test with the people doing the job, on their devices, before anything is rolled out more widely.

Governance4 of 4

Know what has been built across the tenant.

The Power Platform admin centre and managed environments show which apps and connectors exist, who owns them and where data is flowing.

What this gives you

Why it matters. Low code spreads quickly. Visibility is what keeps that useful rather than risky.
How we help. We set environments, data loss prevention policies and a simple approval route, so people can build without creating a support problem.

Swipe, drag or use the arrow keys to move between decisions.

Where the requirement is really about moving work between systems rather than collecting it, that is an automation conversation. Explore Power Automate

Customer experience

Customers describing what we are like to work with.

The strongest evidence of how we work comes from the organisations we work with.

80%

of our business comes from existing customers and referrals.

All customer stories

The best I’ve ever experienced in over 20 years of collaboration.
Programme Manager, Hill & Smith Plc

Before you call

The questions leaders ask us first.

A conversation, not a demo

Tell us which spreadsheet you would not want to lose.

Describe the process, who touches it and where it breaks. We will give you an honest view on whether that needs an app, a change to the system you already own, or simply a clearer way of working.

See customer stories

The process everybody relies onand nobody has a system for.

Nobody asks for an app.

A spreadsheet is running something important

The process lives in an inbox

Somebody built an app, then left

The ERP nearly does it

The team on site cannot use the system

The process first. The app later.

Find the process, not the app idea

Check the system of record first

Build the smallest useful version

Agree who owns it afterwards

Pick the person and see the question.

From building screens to shaping the process.

Describe the app, then edit what comes back.

Customers describing what we are like to work with.

The questions leaders ask us first.

Should this be a Power App, or a change to the system we already have?

What does a first Power App usually cost and take?

We already have apps built by people who have left. Can you help?

How do we stop this spreading out of control?

What about licensing?

Tell us which spreadsheet you would not want to lose.

Related

The process everybody relies on
and nobody has a system for.