One process, chosen on evidence
We pick the single workflow where a pilot answers a real question — the one with the most manual handling, the most re-keying, or the loudest complaints — rather than the one that demos best.
Power Apps proof of concept services
Power Apps proof of concept services that prove one process before you commit to a build
A time-boxed, fixed-scope pilot with a fixed end date: we take a single business process, build a working app your own people use with your own records inside your own Microsoft 365 tenant, then hold a decision meeting and hand over a written account of exactly what it would take to run it in production. The engagement ends with a decision you can defend — including the decision not to build.
Representative dashboard — sample data
What you get
What a time-boxed pilot actually hands over
Six things, all of them defined before the engagement starts. A pilot with an open-ended scope is just a build with a smaller invoice attached to it.
A working app, not a clickable mock
Real screens over real records in your own tenant, on a phone if the work happens on a phone. Prototypes that only move between static images answer a design question, not a feasibility one.
Your own people using it
The test that matters is whether the person who does the job today can do it faster tomorrow. They use it during the pilot, in working sessions, and what they say goes into the written outcome.
A decision meeting, not a status email
The engagement ends with a walkthrough for the people who hold the budget, a recommendation in plain language, and the evidence behind it. Go, no-go, or go with a narrower scope.
A written production gap
What exists between the pilot and something you could run the business on: the data layer, the security model, the environments, the licence position, the integrations, and who owns it afterwards.
A usable no
If the honest answer is buy a product, write code, or fix the process first, that is what you get — in writing, with the reason. A pilot that rules the platform out has done its job.
How it works
Three steps from an unproven idea to a defensible decision
- 1
Agree the question and the end date
A free consultation settles which single process is in scope, what would count as success, which data the pilot touches, and who uses it. You get a written scope, one fixed price, and a date the engagement stops — before anything is built.
- 2
Build it in the open
A senior engineer builds the app in your tenant, inside a named solution, with short working sessions instead of a reveal at the end. We deliberately probe the limits that only bite at scale — query delegation, premium connectors, who is allowed to open the app — while it is still cheap to find out.
- 3
Decide, and take the work with you
A demo and a decision meeting, a recommendation, and the production-gap document. The solution file, the app and the notes are handed over and stay in your tenant whichever way the decision goes. There is no obligation to buy the build from us.
What a pilot is for, and what it is not
A pilot answers a feasibility question, not a delivery question. The question is always some version of does this shape of tool fit this process at all, and it is worth paying to answer because the alternative is discovering the answer halfway through a full build. What a pilot is not is a discounted build: the scope is one process rather than a system, and the deliverable is a decision rather than a finished tool.
Microsoft treats this as a first-class activity rather than a workaround. Its documentation on Power Platform trial environments (opens in new tab) describes the subscription-based trial type as the one that lets companies “develop larger, multiuser, and multiple-department solutions and perform proof-of-concept reviews”, alongside a standard 30-day trial that any suitably licensed user can create. Neither type consumes paid capacity, which is exactly why a pilot can be run without buying anything first.
The same documentation carries the detail that decides where we build. A standard trial environment lasts 30 days and, in Microsoft’s words, “after 30 days, the environment is disabled and deleted”; a single self-service extension of 30 days is available in the final seven days, and after that the environment has to be converted to production or lost. Administrative operations — copy, backup, restore, reset — are not supported on a standard trial. So a pilot parked in a trial environment has an expiry date attached to it, and converting one to production requires spare production database capacity in your tenant. We choose the environment with the decision timeline in mind and say which one we used, rather than leaving you with a working app and a countdown nobody mentioned.
The commitment level is the whole point
This page exists because two different purchases keep getting quoted as one. Our custom Power Apps development service sells the build: the full set of screens, the data model, security, deployment, training and 30 days of hypercare, bought once the decision is already made. This engagement sells the validation that comes before it — one process, one working app, a decision meeting, and an explicit handover of what production would take. Buying the second when you needed the first wastes a few weeks; buying the first when you needed the second is how a project gets abandoned in month four. A third purchase comes later still: once the app is live, Power Apps support and maintenance services cover the fixes and changes that keep it trustworthy after the build team has gone.
Money is deliberately absent from this page. A pilot is a fixed fee agreed in writing after a free consultation, like everything else we sell, and the drivers behind a build quote — screens, data structures, integrations, security, and the recurring licence underneath it — are set out in our guide to what a Power Apps build actually costs. Quoting a day rate on a page about de-risking a decision would invite exactly the comparison a pilot exists to prevent.
| Question on the table | Answered by the proof of concept | Deliberately left to the build |
|---|---|---|
| Does the platform fit this process at all? | Yes — this is the question the engagement is bought to settle, tested against the real workflow rather than a description of it | — |
| Will the people who do the job actually use it? | Yes — they use the app during the pilot and their reaction is part of the written outcome | Rollout, training and change management across every team |
| Does the data behave the way we assumed? | Partly — a representative slice of real records, enough to expose bad assumptions about structure and volume | Full migration, deduplication, reconciliation and history |
| What will it cost to run every month? | Named, not modelled — we identify which connectors and capabilities carry a licence consequence | A per-head licence position confirmed against your renewal and seat counts |
| Is it secure enough for real use? | No — pilot access is limited to a named handful of people and we say so plainly | Role design, row-level security, environment separation and a DLP position |
| Will it survive year two? | Assessed, not delivered — the production-gap document names what is missing | Error handling, monitoring, ALM through test to production, documentation and hypercare |
The limits we go looking for while it is still cheap
A pilot built on fifty rows hides the thing that breaks on fifty thousand, and the most common example is query delegation. Microsoft’s guidance on delegation in canvas apps (opens in new tab) explains that when a query cannot be delegated to the data source, Power Apps retrieves the first 500 records and processes them locally — a limit you can raise to 2,000 — so a filter over a large table can quietly return a confidently wrong answer rather than an error. Microsoft’s own advice for pilots is blunt: set the data row limit to 1 while testing, because “anything that can't be delegated returns a single record, which is easy to detect when testing your app. This helps you avoid surprises when moving a proof-of-concept app to production.”
That is precisely the kind of thing a pilot should be run to find, so we run it that way on purpose. The same treatment goes to the other limits that are cheap to discover now and expensive to discover later: which connectors in the design are premium and therefore change what every user must be licensed for, whether anyone who needs the app sits outside your organization, how the process behaves offline if the work happens in a vehicle or on a roof, and whether the records are relational enough that a list will not hold them. Our comparison of Power Apps against custom software development sets out the documented ceilings that honestly rule the platform out, and it is the page we point to when a pilot ends in a no.
Where the work is built, and why that decides what happens next
Everything is built inside a named solution with your own publisher prefix rather than loose in a default environment. Microsoft’s documentation on solutions in Power Apps (opens in new tab) states plainly that “solutions are used to transport apps and components from one environment to another” and that they are the mechanism for application lifecycle management across Power Platform. The practical consequence for a pilot is portability: the work can be exported, moved into a development environment, and carried forward through test to production without being rebuilt.
That matters more for a pilot than for a build, because a pilot is the thing most likely to be thrown away. Work done straight into the default environment, outside a solution, tends to be unmovable by the time anyone wants to move it — which turns a successful pilot into a second first draft. Doing it properly costs nothing extra at this size, and it is the difference between the decision meeting ending in “promote this” and ending in “start again, properly this time”.
From pilot to production: the gap we hand you
The production-gap document is the deliverable clients quote back to us most often, because it is the part a marketplace listing for a fixed-duration pilot never includes. It is written for the person who has to approve the next spend, and it covers each area below with a specific answer for your situation rather than a generic checklist.
| Area | What the pilot has | What production needs |
|---|---|---|
| Data layer | A working structure sized for one process, often a list, holding a representative slice of real records | A modelled backend with relationships, typed columns and validation where the process genuinely needs them |
| Security | The app shared with a named handful of pilot users | Roles mapped to real job functions, row-level access where teams must not see each other’s work, and sharing by security group |
| Environments and ALM | A single environment with the work held in one named solution | Development, test and production environments, with changes promoted in solutions rather than edited live |
| Licensing | The connectors and capabilities in the design identified, and any premium ones flagged | A per-head position confirmed against your actual seats and renewal date before anyone is asked to approve it |
| Integrations | The minimum needed to make the pilot honest — often one connection, sometimes none | The systems the process really touches, with failure handling for when one of them is unavailable |
| Support and ownership | A senior engineer available for the duration of the engagement | A named owner inside your organization, documentation, and a route for changes after go-live |
Two of those rows regularly change the answer on their own. A licence consequence discovered in week one is a scoping conversation; the same consequence discovered after a rollout is a budget problem — our guide to what it costs to run a Power App every month covers that side in detail. And a data layer that was fine for one process and one team frequently is not fine for four, which is the decision our comparison of Dataverse against SharePoint lists works through.
Who this suits, and when to skip it entirely
It suits a team that has been quoted for something and cannot tell whether the quote is reasonable, an operations leader who has been asked to justify a build to a board that has been burned before, and anyone whose real blocker is internal scepticism rather than technical doubt — a working app that people have actually used settles an argument that a slide deck cannot.
Skip it in three cases, and we will say so during the free consultation rather than sell you a pilot anyway. If the requirement is already settled and the shape of the answer is obvious, go straight to the build. If the honest comparison is against a packaged product rather than against building anything, our guide to Power Apps versus buying software makes that call faster and for nothing. And if the process itself is broken, automating it in a pilot produces a faster version of the wrong thing — that is a process conversation first, and often a Power Automate one second.
What you keep when the engagement ends
Everything, and in your own tenant rather than ours: the environment, the solution file, the app, the data it collected, and the written outcome. There is no licence to us, no hosting relationship, and no obligation to commission the build — a pilot you take to another partner is a pilot that did its job. Our fixed-fee process page sets out how the written scope is produced and what handover covers, and the work is performed remotely by senior US-based engineers from our Orange County, CA base, serving every US state.
Related services
What usually follows a go decision
Power Apps Consulting
The full build once the decision is made — canvas and model-driven apps, fixed fee, typically two to four weeks, 30 days of hypercare.
Microsoft Dataverse Consulting
The modelled data layer a pilot usually proves it needs — tables, relationships, security roles, environments and solutions.
Power Automate Consulting
The approvals, routing and integrations that sit behind the screens once the process is worth automating properly.
Further reading
Guides worth reading before you commission one
Hand-written guides from our article library.
Power Apps development cost
What drives a build quote, what the licence underneath it adds, and how fixed-fee pricing is put together.
Canvas apps vs model-driven apps
The app-shape decision a pilot usually settles, and the asymmetric licence consequence that comes with each answer.
Power Apps vs Dynamics 365
When the prebuilt Microsoft application is the better answer than anything you would pilot, and why the data model is portable either way.
FAQ
Pilot questions, answered
It is a short, fixed-scope engagement that answers one question: does this shape of tool actually fit this process? We build a working app for a single workflow, with your real data, in your own tenant, and your own people use it before anyone commits to a full build.
A build assumes the decision is made and delivers the finished system: every screen, the full data model, security, deployment and training. A pilot deliberately covers one process and stops at a decision. It is bought to reduce the risk of the build, not to replace it or to get the build cheaper.
The end date is agreed in writing before work starts, which is the point of a time-boxed engagement. Pilots sit at the short end of our typical two-to-four-week delivery window because the scope is one process. If the date and the scope ever conflict, we cut scope rather than move the date.
Sometimes, and we tell you which case you are in rather than assuming. Everything is built inside a named solution so it can be moved between environments. What usually still has to be added is the full data model, real security roles, deployment through test, and the error handling a pilot does not need.
Two roles, and neither full time. Someone who does the work today, to tell us where the current process actually hurts and to use the app during the pilot, and someone with tenant admin rights to create the environment and approve connections. A budget holder attends the decision meeting at the end.
You get that in writing, with the reason, and the engagement ends there. A pilot that rules the platform out has done its job and saved you the build. We would rather deliver an honest no than sell a project that hits a documented limit in its fourth month.
Book a free consultation
Get more from the Microsoft tools you already pay for
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
- Fixed-fee scope agreed before any work starts
- Senior, US-based Microsoft engineers — no handoffs
- Typical 2–4 week delivery
- 30 days of post-delivery hypercare included
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.