Before building a Power App, decide ten things: who uses it and how many, on what device, whether they have Microsoft accounts, where the data lives now, whether it needs to go back anywhere, how much data there is, who can see which records, what happens with no signal, what the exceptions are, and who owns it after go-live. Answer these ten before anyone starts building. Unanswered, each becomes a mid-build change request.
The list below is the one we work through on every first app. It is not about technology preferences. Each question is there because the answer changes the licence, the data store, the screens or the timeline, and changing any of those halfway through costs far more than deciding at the start.
The users
1. Who uses this, and how many? Named roles, real numbers. It changes the licence model and the interface. Twelve site supervisors entering pre-starts is a different app from 300 staff submitting leave, and if the app needs premium features, the licence applies to every person who uses it. Our Power Apps licensing explainer covers how that plays out.
2. On what device? A phone in a vehicle and a desktop in an office are different applications, not a responsive layout. A phone app for a site wants big buttons, the camera, location and as little typing as possible. A desktop app for a finance team wants tables, filters and keyboard entry. If the honest answer is "both", expect two sets of screens.
3. Do they have Microsoft accounts? External users — contractors, volunteers, clients — change the architecture entirely. Guest access, a portal, or a separate capture method each have their own licence and security implications. Find out now, not when the first subcontractor cannot log in.
The data
4. Where does the data live now? Existing systems, spreadsheets, paper. Collect actual examples: the spreadsheet, a photo of the paper form, a screenshot of the system screen. Real samples show the fields nobody mentions in a meeting.
5. Does it need to go back anywhere? A one-way capture app is far simpler than a two-way sync. "Push approved timesheets to payroll once a week" is a contained piece of work. "Keep the job list in step with the ERP in real time" is a project of its own, and may need a premium connector.
6. How much data, and how fast does it grow? This decides SharePoint versus Dataverse. A few thousand rows a year with simple relationships sits comfortably in SharePoint lists. Tens of thousands of rows, many related tables or offline use usually points to Dataverse, which carries a licence cost. The trade-offs are covered in Dataverse or SharePoint lists?.
7. Who is allowed to see which records? If the answer is "everyone sees everything", you have saved yourself significant complexity. If not, say so now. "Supervisors see their own crew, managers see their region, HR sees everything" is a perfectly normal requirement, but it shapes the data store and the security model from day one.
The edges
8. What happens with no signal? Offline capability is a design decision, not a setting. It affects the data store, how conflicts are handled when two people edit the same record, and how much testing is needed. If the work happens in basements, rural sites or plant rooms, decide it now.
9. What are the exceptions? The urgent case, the correction, the deletion, the approver on leave. The happy path is usually a third of the build. Write the exceptions down as short "what if" sentences and decide each one: handled in the app, handled by a person, or out of scope.
10. Who owns it after go-live? Named person. If nobody can be named, do not build it yet. The owner decides on changes, answers questions and is the first call when something looks wrong. Without one, the app drifts out of date and people quietly return to the spreadsheet.
How each answer moves the build
| Question | If the answer is simple | If it is not |
|---|---|---|
| Users and numbers | Standard licences, one interface | Licence review, possibly role-based screens |
| Device | One layout | Separate phone and desktop screens |
| Microsoft accounts | Staff only, normal sign-in | Guest access, a portal or another capture method |
| Data destination | Capture and report | Integration work, possibly premium connectors |
| Data volume | SharePoint lists | Dataverse and its licence |
| Record visibility | Everyone sees everything | Security roles designed and tested |
| Connectivity | Always online | Offline mode, sync and conflict handling |
| Exceptions | Few, handled by a person | Extra screens, statuses and flow branches |
| Owner | Named before build | Pause until someone is named |
Nothing in the right-hand column is a reason not to build. It is a reason to know before you quote, so the budget and timeline reflect the real job.
What it looks like when a question is missed
Here is an illustrative example of how one unanswered question travels through a build. A field inspection app is scoped and built for "the inspection team". In user testing, it turns out half the inspections are done by subcontractors without Microsoft accounts.
- 01Scoped for internal staffquestion 3 never asked
- 02Screens and data builtsign-in assumes Microsoft accounts
- 03Testing with real usershalf the inspectors are subcontractors
- 04Architecture revisitedguest access or a separate capture method
- 05Change request raisednew scope, new licence check, new timeline
- 06Same question asked at scopingone line in the brief, decided in a meeting
None of this is anyone's fault. It is what happens when the person requesting the app describes the work they see, not the edges of it.
How to use this
Send the ten questions to whoever is requesting the app before the first meeting. The questions they cannot answer are exactly what the first meeting should cover. That turns the first meeting from a general conversation into a working session that ends with decisions.
It also helps to write the answers into a one-page brief that both sides sign off. Keep it short:
- Purpose in one sentence, and the process it replaces
- Roles and real numbers of users, including any external users
- Devices and whether offline use is needed
- Where the data comes from and where it needs to go
- Who can see and edit which records
- The exceptions, each marked in scope or out of scope
- Sample documents: the current spreadsheet, form or screen
- Named owner after go-live, and a named backup
- How you will know it is working after 30 days
The last item matters more than it looks. If the app replaces a paper pre-start, "every pre-start for 30 days was submitted in the app" is a clear test. It also feeds straight into the launch plan; the first 30 days is where most apps succeed or fail.
Who should answer which questions
The person requesting the app can rarely answer all ten alone, and that is normal. Questions 1, 2, 9 and 10 belong to the business owner of the process: the operations manager, the site lead, the practice manager. Questions 4, 5 and 6 usually need someone who knows the existing systems, often finance or IT. Question 7 needs whoever is accountable for the data, such as HR for staff records or a project director for commercial information. Question 3 and question 8 need someone who has actually watched the work being done, which is often not the person in the meeting.
Getting the right three or four people into one hour is the most useful thing you can do before a build. Ten questions answered by the wrong person look decided and then come back as change requests anyway.
When the answer is "don't build an app"
Sometimes the checklist shows a Power App is the wrong tool. If the users are three people in one office, the data is a few dozen rows and nothing needs to go anywhere, a well-structured SharePoint list or a Microsoft Form may do the job with no build at all. If nobody can describe the process, the first step is writing it down, not building screens. Saying so early is cheaper than building something that gets ignored.
What to do next
Copy the ten questions into an email to the person asking for the app, and book an hour to go through the answers together. If most come back clear, you are ready to scope a build; single builds like this are typically scoped from $10,000, and the Power Apps service page explains what that covers. If several come back as "not sure", that is the useful finding, and those are the decisions to make before any money is spent.
Want the version for your business?
Work out what manual processes are costing you — three minutes, no contact details needed.
Work out the cost