Most Power Platform builds that go wrong were never technically difficult. They go wrong after handover: a flow stops when the consultant's account is disabled, a licence bill nobody mentioned lands in month three, or the only person who understands the app has moved on. You can screen for all of that before you sign, and you don't need to be technical to do it.
Questions to ask in the first conversation
Ask the same questions of every firm you speak to, and write down the answers.
| Question | A good answer | Worry if you hear |
|---|---|---|
| Where will you build it? | In our tenant, in a development environment we own | "We'll build it in ours and move it across later" |
| Whose accounts run the flows? | A service account in our tenant, documented | Silence, or the consultant's own login |
| What licences will our users need? | A named list per user group, with what triggers each | "We'll sort licensing at the end" |
| Who will do the work? | Named people, and who replaces them on leave | Only the person selling it |
| What do we get at handover? | Documentation, exported solutions and a walkthrough | "It's all in the app" |
| How do changes work after go-live? | A clear choice: do it yourselves, ad hoc or a retainer | Changes only through them, at an unstated rate |
The licensing answer deserves a follow-up. Ask which features in the design need a premium licence per user, and how many people that touches. A good partner will tell you to check Microsoft's current pricing and may suggest a design that avoids premium features altogether. Power Apps licensing explained covers what triggers a paid licence, so you can test the answer.
Red flags
Any one of these is worth a direct question. Two or more, and keep looking.
- Builds in their tenant. Convenient for them, risky for you: moving it later is a project, and until then your process runs on someone else's infrastructure.
- Flows under a personal account. When that person leaves, whether a consultant or your own staff member, the flows stop. Connections belong to a service account your IT team controls.
- No named owner on your side. A partner who never asks who will own the process after go-live is planning to own it themselves.
- No documentation in the quote. If handover isn't a line item, it won't happen. What handover documentation should contain is a fair benchmark.
- Licence surprises. Premium connectors or Dataverse appearing late in the design, after the budget is agreed.
- Vague scope with a fixed price. Either the scope will be squeezed or the variations will be expensive.
What a good proposal contains
A proposal is the first piece of documentation you get. If it is vague, the handover will be too.
- The problem in your words, with the process owner named
- What is in scope, and what is explicitly out
- Where it will be built and who will own every component
- Licences each user group will need, with assumptions stated
- Named people doing the work
- Milestones with something you can see or test at each
- Handover: documents, exported solutions and a training session
- How changes and support work after go-live, and what they cost
Price matters, but compare like with like. A cheaper quote that leaves out documentation, testing or a development environment is not cheaper; it moves that cost to you later. Ask each firm to price the same scope, and ask what they would cut if the budget were 30% lower. How they answer shows how they think.
Check the fit, not just the badges
Microsoft partner designations show a firm has met Microsoft's requirements. They don't tell you who will be doing your build or whether they understand your industry. A few checks do:
- Ask for a referee who has run the build for a year. Ask them what happened the first time something broke, and how long changes take.
- Ask to see a redacted handover document. It shows more about a firm's habits than any case study.
- Ask about your industry's constraints. Site connectivity in construction, client confidentiality in professional services, funder reporting in for-purpose organisations. A partner who has worked with them will raise these before you do.
Large and small firms both do good work. A larger firm brings bench depth and cover; a smaller one usually means the person you meet is the person who builds. Decide which matters more for this project, then ask how they handle the other.
What to do next
Send the same six questions to every firm on your shortlist, in writing, before the first meeting. Compare the answers side by side, then ask the best two for a referee and a sample handover document. Read who owns what you build for the ownership checks to write into the contract.
Want the version for your business?
Work out what manual processes are costing you — three minutes, no contact details needed.
Work out the cost