Building a Suite of Internal Apps on Power Platform: How to Scope, Sequence and Contract It

Why does a suite of internal apps go wrong when it is bought as one project?

A shelf of ageing internal tools usually looks like one problem: a few Access databases, some macro-heavy spreadsheets, an old intranet form, a line-of-business app written by someone who left. The natural response is to scope the lot, get one quote and one go-live date. That shape concentrates every risk at the end of the programme.

Acceptance happens late, so misunderstandings surface after most of the budget is spent. Handover happens late, so the organization spends the whole programme dependent on the partner and then receives everything at once, with no time to absorb it. Each app tends to be built slightly differently by whoever picked it up, so the suite ends up as several small platforms rather than one. And the tool that is actually hurting the business waits in the queue behind easier ones.

The alternative is not slower. It is a programme in which one app is built properly first, becomes the pattern, and every later app is cheaper and safer because it reuses what the first one established.

What should discovery cover before anyone quotes the whole suite?

Discovery should be a separate, fixed-scope piece of work with a defined output, bought before any build commitment. Its job is to turn "a shelf of tools" into an inventory you can make decisions on, and to give you something you own even if you choose a different partner for the build.

Which of the ageing tools probably should not be built at all?

An honest discovery removes work. In most estates of this kind, some tools fall into one of the categories below, and building them again on the Power Platform would spend budget reproducing a problem.

• Tools nobody really uses. Usage evidence beats opinion: if a database has not been opened by more than one person in months, archive its data in a readable form and retire it.
• Tools that duplicate something you already license. A request tracker that a SharePoint list, Microsoft Forms, Planner or a Teams approval would cover does not need a custom app.
• Tools that are really reports. If the tool exists to produce a monthly summary, the replacement is a Power BI report over the system of record, not an app that re-keys data.
• Tools that only hold history. Records you must keep but no longer change need a read-only archive with a retention rule, not a working application.
• Tools that are really a CRM. A customer database with pipelines, cases and activity history is a CRM decision: Dynamics 365 if you want the Microsoft ecosystem, or a custom-built CRM if you need full control without per-user licensing.
• Tools that are really finance or ERP. Solzet does not implement Dynamics 365 Finance, Business Central, NAV or Finance and Operations, and a Power Apps rebuild of accounting logic is rarely the right answer. Those tools belong to your ERP programme.
• For one tool on its own, rather than a suite, replacing a legacy Access database or in-house CRM sets out the replacement paths in detail.

How do you choose the first app to build?

Pick the app whose failure hurts most, provided it is also representative enough to establish the pattern. The first app is not a pilot you can throw away; it is the template every later app will copy, so it has to exercise the parts of the platform the rest of the suite will need.

What does building the pattern app to standard actually include?

The pattern app carries more one-off cost than any later app, because it establishes decisions the rest inherit. That extra effort should be visible in the plan and in the contract rather than hidden in an estimate. Governance for the wider platform, such as DLP policies and who may build what, is covered in our guide to building a Power Apps Center of Excellence with a nearshore team; this list is what the suite itself needs.

• Environments: development, test and production in your tenant, created for the programme rather than borrowed from the default environment.
• Solutions and ALM: every component in a solution, source in your repository, managed solutions only in test and production, and deployment by pipeline. The mechanics are in moving from manual ZIP files to PAC CLI and pipelines.
• A shared data model: the tables later apps will reuse, with naming conventions, keys and ownership agreed, so app three extends the model instead of copying it.
• A security model: security roles and team structures designed for the suite, not just for the first app.
• Environment variables and connection references for everything that differs between environments, so nothing development-specific reaches production.
• Flows with an error path: retries, logging and a named owner who is told when a flow fails.
• Shared components: a component library, standard screens or forms, and PCF controls only where standard controls genuinely cannot do the job.
• Documentation written for the people who will support it: a data dictionary, a runbook, known limitations and how to deploy a change.

How should the remaining apps be sequenced once the pattern exists?

After the pattern app is accepted, the order is driven by pain and by reuse. Apps that sit on the data model already built come first, because they are the cheapest proof that the pattern works. Apps that need new integrations or new data follow. Work can run in parallel only once the pattern is stable; parallel teams before that point produce parallel patterns.

How does progressive handover work with almost no internal developers?

Handover is a sequence of responsibilities, not a single event. For each app, your organization first runs it (business ownership, user support, access requests), then supports it (triage, configuration changes, simple flow fixes), and only then changes it (new features through the pipeline). A partner that keeps all three until the end of the programme leaves you with a cliff edge.

You do not need a development team to start. You need a business owner per app, one platform owner who holds the admin rights and the relationship, and ideally one or two people who want to become makers and who pair with the delivery team on the reuse wave. Where that capability should grow into a permanent function, the Center of Excellence guide sets out how. Where it will stay small, a managed support arrangement covers the harder changes; Power Platform development and support from Armenia describes how that runs.

• Each app has a named business owner before its build starts, and that person signs its acceptance.
• Your platform owner holds administrator rights on every environment from the first day, not at the end.
• Every deployment after the pattern app is run through the pipeline, so your team learns one way of releasing.
• Your makers pair on real work in the reuse wave rather than attending training in isolation.
• Support tickets move to your team app by app, with the delivery team as second line until each handover is confirmed.

How should the contract for an app suite be shaped?

The contract should make the programme shape enforceable: small commitments, testable milestones, and ownership that never sits with the partner. The elements below are the ones we would expect a buyer to ask for, and the ones we work to.

What should a documented exit contain?

Agree the exit pack at the start and deliver it incrementally, so it is always current rather than assembled in the last week. If the partner changes, or your team takes over completely, this is what makes the transition a handover instead of a rescue.

• Repository access and the pipeline definitions that build and deploy every solution.
• Deployment settings for each environment, with secrets held in your own key store.
• Service principals and integration accounts owned by your organization, not by partner staff.
• The data dictionary, security model, standards document and a runbook per app.
• The open defect list and the backlog of agreed but unbuilt changes.
• Recorded knowledge transfer sessions covering the data model, deployments and the most fragile integrations.

Is the Power Platform the right home for every app in the suite?

Usually for most of them, but not automatically for all. Internal tools built around approvals, inspections, requests, registers and case tracking fit the Power Platform well, especially where the organization already runs Microsoft 365. A tool that is really a customer relationship system is a different decision. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

For a CRM-shaped tool, that means Dynamics 365 where per-user Microsoft licensing and the Microsoft ecosystem make sense, and a custom CRM on React, Node.js, PostgreSQL or .NET where they do not. Discovery should say which applies to each tool rather than assume the whole shelf moves to one platform.

How does Solzet deliver an internal app suite programme?

Solzet is a scalable senior consultancy based in Yerevan, Armenia (GMT+4), with 8+ years in the Microsoft ecosystem. Our senior consultants and full-stack developers run the discovery, build the pattern app, and scale delivery capacity up for the reuse and extension waves and back down as your team takes over. We work on B2B contracts inside your Azure DevOps, GitHub or Jira, in English, Armenian or Russian, and the environments, source and solutions stay in your tenant throughout.

The detail on roles, app types and engagement models is on our Power Platform development service. We deliver Power Apps, Power Automate, Power Pages, Copilot Studio, Dataverse and PCF controls; we do not deliver Dynamics 365 Finance, Business Central or other ERP implementations. To start, send us the list of tools as it stands, however untidy, at contact@solzet.com or through the form below.