After the app goes live
Your app is in daily use and nobody wants to replace it — but a flow stopped running last week, a connection broke when someone changed their password, and there is a list of small changes nobody has time to make. Our Power Apps support and maintenance services handle that list: senior US-based engineers scope each batch of fixes at one fixed fee you approve first. No retainer, no bank of hours.
Representative dashboard — sample data
What you get
A Power App rarely fails all at once. It works on launch day, then the people, data and permissions around it change while the app does not. Maintenance is keeping the two in step.
A cloud flow that fails usually fails quietly: an approval never arrives, a record is never created. We find which runs failed and why, fix the cause rather than resubmitting the run, and add error handling so the next failure reaches a person.
Apps and flows authenticate through somebody’s connection. When that person changes a password, changes role or leaves, the app breaks for everyone. We re-point connections to accounts that will still exist, and record which piece depends on which.
An app built against a few hundred rows can silently stop showing records once the list grows. We rewrite the queries so the data source does the filtering, and the app sees every record rather than the first page of them.
A new field, a renamed status, an extra approver, a column the team keeps asking for. None of it justifies a project; all of it matters to the people using the app. We batch the list and price it once.
People join, move teams and leave, and the app’s sharing and the permissions on its data drift away from who should actually see what. We bring both back into line and write down who owns and co-owns the app.
Every change we make is recorded against the app: what changed, why, and what it depends on. Over a few batches that becomes the documentation most small-business apps never had.
How it works
Through the form below: what broke, what people keep asking for, and roughly how the app is used. A rough list is fine. We ask the questions needed to turn it into specific, testable items during a free consultation.
On the first engagement we read the app, its flows, its connections and its data source once, so the quote reflects what is actually there. You get a written list of changes and a single fixed fee, and nothing starts until you approve it.
Changes are made and tested away from the live app where the setup allows, released with your sign-off, and noted in the app’s change record. Each batch is followed by 30 days of hypercare in case something we touched misbehaves.
A Power App is not a sealed product. It is a set of screens sitting on top of connections, data sources and flows, each of which belongs to somebody and each of which can change underneath it. The app itself may not have been touched in a year and still stop working on a Tuesday, because the list it reads crossed a size threshold, or the person whose account runs the approval flow left the company. Most maintenance work is not bugs in the app’s logic; it is the world around the app moving while the app stood still.
Connections are the clearest example. Microsoft’s documentation on connection references in solutions (opens in new tab) explains that flows built inside a solution bind to a connection reference rather than to one person’s connection, so the credential behind them can be swapped in one place — but apps and flows created outside a solution are not upgraded to that model automatically. Many small-business apps were built exactly that way, which is why one password change can take several of them down at once. Data volume is the second example: Microsoft’s delegation overview (opens in new tab) sets out which formulas the data source can process for the app, and which ones only ever see the first few hundred records.
Support here means keeping a working app working and making it a little better over time. The line matters because a request on the wrong side of it needs a different kind of engagement, and pricing it as maintenance would short-change you.
| The request | Handled as support? | Notes |
|---|---|---|
| A flow has stopped running or fails intermittently | Yes | Cause found and fixed, plus error handling so the next failure notifies someone |
| The app broke after someone left or changed their password | Yes | Connections and ownership moved to accounts that will still exist; dependencies recorded |
| Records are missing now the list has grown | Yes | Queries rewritten so the data source does the filtering; delegation warnings cleared |
| New fields, columns, screens or approval rules | Yes | Batched into a written change list at one fixed fee |
| Sharing and data permissions no longer match the team | Yes | Access reconciled against who should see what; owners and co-owners named |
| The build never worked, or stalled halfway | No | That is a takeover, not maintenance — see Power Platform project rescue services |
| A new app for a different process | No | That is a build — see custom Power Apps consulting |
| A 24/7 on-call desk with a guaranteed response time | No | We do not offer a service-level agreement; a managed service provider is the right fit for that |
The single most useful question is whether the app works today. If people open it every morning and it mostly does its job, you need support: a list of fixes and changes, priced and delivered in batches. If it never reached the people it was built for, or it stalled when the builder left, or it works for one person and nobody else, you need our Power Platform project rescue services instead — a one-off intervention that starts with a full assessment and a repair-or-rebuild verdict. The two are scoped separately and a rescued app can move onto support afterwards, but starting with the wrong one wastes the first week. If the thing that needs looking after is a live dashboard rather than an app, the equivalent service is Power BI support and maintenance services.
The same honesty applies at the other end. If the item at the top of your list is really a second app, or a large new module bolted onto the first, that is a build, and pricing it as a series of small changes would hide its real cost. What drives Power Apps development cost explains how a build quote is put together. If you are not yet sure the new idea is worth building, a Power Apps proof of concept tests one process on real data before you commit. And how our fixed-fee process works is the same for a batch of fixes as it is for a full build.
Microsoft already provides technical support with your licences, and it is worth knowing where its line falls before paying anyone else. Its support overview for Power Platform (opens in new tab) distinguishes break-fix problems in the service from how-to and advisory questions, which it treats as knowledge transfer outside support plans, and for problems that trace back to customization it recommends consulting a partner or the community forums. Only users holding a Power Platform admin role can open a request in the admin center.
| The problem | Microsoft support | This service |
|---|---|---|
| Power Apps or Power Automate itself is down or misbehaving | Yes — platform break-fix, raised by a Power Platform admin | We help confirm the fault is the platform’s and gather what the ticket needs |
| Billing, licences or subscriptions | Yes | No |
| A formula, screen or flow in your app gives the wrong result | Customization — Microsoft recommends a partner | Yes |
| “How do we make the app do this?” | Advisory, outside standard support plans | Yes — scoped as a change |
| Adding fields, screens or approval steps | No | Yes |
The usual way to buy this is a monthly retainer for a set number of hours. We do not offer one. Maintenance work is lumpy — nothing for two months, then three things at once — and a flat monthly fee means paying for the quiet months while the busy ones still run over. Instead, each batch of fixes and changes is written down as a list of specific items, each described by what changes, and the whole list carries one fixed fee you approve before work starts. When the list is empty, there is nothing to pay. We do not publish a price list, because the fee depends on what is in the batch and on how the app is built; the quote comes after the free consultation and, on the first batch, after reading the app.
One safeguard is worth doing regardless of who maintains the app. Canvas apps keep a version history, and Microsoft’s guide to restoring a canvas app to a previous version (opens in new tab) shows how to roll back a change that went wrong. We note the version in use before each release, so rolling back is a known step rather than a search.
The usual fit is a small or mid-size business with one to a handful of Power Apps in daily use — an inspection app, a request-and-approval app, a job tracker — built by a contractor, an agency or a capable colleague who has since moved on to other work. The app is valued, nobody wants to replace it, and there is no one left whose job it is to keep it working.
It fits badly in two cases. If you need someone on call overnight with a contractual response time, that is a managed service provider, not us. And if the app never worked properly, the honest answer is a rescue or a rebuild, and we will say so during the consultation rather than sell a string of fixes that will not hold. Work is delivered remotely across all US states from our Orange County, CA base, by senior US-based engineers.
Related services
For a build that never worked or stalled halfway: an independent assessment, then a fixed-fee takeover.
A new custom app for a different process, designed and built at a fixed fee with 30 days of hypercare.
Prove one process on real data before committing to a full build.
FAQ
No. There is no retainer and no bank of hours to use up. You send us the list of what needs fixing or changing, we scope it, and the batch carries one fixed fee you approve in writing before any work starts. In a month when nothing needs doing, you pay nothing.
Yes, provided it works today. We start with a short read of the app, its flows, its connections and who owns them, because nobody can honestly price a change to something they have not seen. If that read shows the app is fundamentally broken, we will tell you it is a rescue, not support.
We do not sell a contractual response time, and we would rather say so here than in a dispute later. A fix is scoped and scheduled like any other piece of work, with the date written into the scope. If you need someone on call overnight, a managed service provider is the better fit.
Support is for an app that works and is in daily use but needs small fixes, changes and updates. Rescue is for a build that never worked or stalled halfway, and it starts with a full assessment and a repair-or-rebuild verdict. Same engineers, a different starting point, and a different scope.
Microsoft support covers the platform: billing, subscriptions and break-fix faults in the service itself. Your app's formulas, screens, flows and data design are your own customization, and for problems rooted there Microsoft's support overview recommends a partner. We cover that layer, and help you raise a Microsoft ticket when the fault is theirs.
Whatever is on your list, provided it is maintenance rather than a new app: a failing flow, a connection to re-authenticate, a new field on a form, an extra column in a gallery, a permissions change, an updated approval rule. Each item is described by what changes, tested before release, and covered by 30 days of hypercare.
Book a free consultation
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.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.