The questions we would ask.

An unmanaged solution file, the documentation written during the build, and a walkthrough of what is in it. The solution file is the deliverable — you import it into your own environment yourself.

Unmanaged means the components stay editable. You can open the app in the maker portal, change a screen, add a column, or hand the whole thing to another supplier without asking us for anything.

You do, outright. There is no licence to renew, no component that stops working if you stop paying us, and no runtime that depends on our infrastructure continuing to exist.

That is a constraint we have put on the business rather than a concession we make case by case, and it is the specific reason we deliver unmanaged rather than managed solutions.

No. We build in our own development environment, against the data model agreed during scoping, and you import the finished solution into your tenant yourself.

Your change control, your admin rights and your security boundary stay entirely yours. The handover is a file rather than a set of permissions somebody has to be trusted with.

It depends on what the solution uses. Dataverse, model-driven apps and premium connectors carry different licensing implications to a canvas app sitting over SharePoint. We will tell you what a build requires before you commit to it, so licensing does not arrive as a surprise after handover.

We do not resell Microsoft licences. That relationship stays between you and Microsoft.

We stop and re-quote before continuing. A change is either inside the agreed scope, in which case it is already paid for, or it is outside it, in which case it gets its own price and its own decision.

What does not happen is silent absorption followed by a larger invoice at the end. The written scope exists so that conversation has something specific to point at.

Not as a managed service. There is no support desk and no retainer, because promising a guaranteed response from a practice this size would not be true.

Enhancements are quoted individually, one at a time, the same way the original build was. If you never come back, nothing degrades — you hold the solution file and the documentation.

Because a large part of a Power Platform build is repetitive — scaffolding screens, wiring data sources, writing formulas to a known pattern, producing documentation — and that work is genuinely faster with AI assistance in the loop.

Faster repetitive work makes the estimate tighter, and a tighter estimate is what makes a fixed price survivable rather than reckless. The practical effect is that estimation risk sits with us instead of with you.

Yes. If you already have naming conventions, a solution structure, an environment strategy or a design system, send them during scoping and we will build to yours rather than to ours.

If you do not have them, ours are written down and handed over with the build, so whoever maintains it afterwards has something to follow.

A description of the problem, who uses the solution and roughly how many of them, where the data lives today, and any deadline that genuinely matters. A few paragraphs is enough for a first pass.

From there it is usually a single call and a follow-up before there is a written scope and a fixed price to approve or decline.

Ask anyway. The catalogue is narrow deliberately — canvas apps, model-driven apps with Dataverse, and Power Automate cloud flows — and we would rather say during scoping that we are the wrong people than take the work and learn on your budget.

Where we can point you somewhere more suitable, we will.

The United Kingdom, remote. Because everything is delivered as artefacts you import yourself, physical location rarely affects the work.