Conversational app building makes the first implementation unusually persuasive. A sponsor can describe an onboarding tracker or field-service screen and receive a working scaffold within minutes. Microsoft says its Copilot Studio and Cowork app experiences can connect business data, use open standards, support Git-backed source control and appear in centralized administration.
Those capabilities are meaningful, but a product announcement is not an architecture assessment. Power Apps and custom code also cover wide and overlapping territory. The decision should begin with the future service, not the speed of the first demo.
Apply disqualifiers before scoring
Before comparing preferences, identify any requirement that an option demonstrably cannot meet. Examples include a mandated offline mode, a certified device integration, a particular data-residency model, external anonymous users, hard latency targets, unsupported transactions or a portability obligation.
Test uncertain disqualifiers with a small spike. Do not award a low score to an impossible requirement and then allow other attractive features to average it away. If the requirement is essential, failure removes the option.
Score eight operating factors
1. Interaction and channels
Define required screens, device behavior, accessibility, offline work, external access and embedded experience. Managed generation may be strongest for bounded internal interaction; Power Apps offers established canvas and model-driven patterns; custom code permits the widest control at the highest ownership cost.
2. Data model and transactions
Assess entities, relationships, audit, concurrency, transaction boundaries, retention and system-of-record status. Dataverse can provide structured tables, business rules and security. A lightweight app should not accidentally become the master for complex regulated records.
3. Identity and security
Map users, service identities, row and field access, secrets, guests and privileged administration. Platform defaults reduce work only when they match the needed boundary.
4. Integration and extensibility
List connectors, APIs, event patterns, files, devices and external networks. Include rate limits, error handling and ownership of every dependency. Custom code can reach unusual systems, but the team then owns more integration behavior.
5. Scale and performance
Use expected users, data volume, concurrency, geographic reach and response targets. Validate the most uncertain path with production-shaped data rather than extrapolating from a demo.
6. Lifecycle and change
Compare source visibility, environments, testing, deployment, rollback, version isolation and migration. Power Platform pipelines support governed promotion for solution components. For a preview app runtime, verify which artefacts and settings are actually exportable and recoverable.
7. Operations and skills
Identify monitoring, incident response, support hours and the people able to maintain the system. A low-code platform may fit an existing centre of excellence; custom code may fit an established product engineering team. The cheapest build can become the most expensive orphan.
8. Economics and exit
Model licenses, consumption, environments, engineering, support and change over the expected lifetime. Include the cost and feasibility of extracting data, replacing the runtime and retiring dependent integrations.
Score with evidence and state confidence. An unknown is not a neutral value.
A worked decision: field inspection
A manufacturer needs an inspection app for 300 technicians. It captures measurements and photos, works in locations with poor connectivity, opens repair cases and keeps an auditable inspection history for seven years.
The generated managed-app prototype provides a strong interface and rapid stakeholder feedback. Offline behavior and long-term export guarantees are not sufficiently evidenced, so it remains a discovery tool rather than the selected runtime.
Power Apps scores well for Microsoft identity, Dataverse records, device support, connectors, governed environments and the internal support team. A technical spike tests offline synchronization with large photos and conflict handling. Custom code scores higher for complete offline control but would require a new mobile release and support capability.
The team selects a Power App because the spike meets the critical offline and data requirements. A small Azure component handles image processing that does not fit comfortably in the app. The hybrid boundary has a named API owner, retry behavior and monitoring. The generated prototype’s interaction learning is retained even though its runtime is not.
Use hybrids deliberately
Hybrid architecture is legitimate when each boundary has a reason. A Power App may use an Azure service for a specialized calculation; a generated managed app may call an existing governed API; custom code may embed a platform workflow.
Every boundary adds identity, latency, failure, version and support paths. Document who owns the contract, what happens on timeout, how changes remain compatible and where telemetry joins. A hybrid created merely to bypass unclear platform limits often becomes harder than either primary option.
Revisit the decision as evidence matures
Preview platforms evolve, business volumes change and native capability expands. Record the selected option, rejected alternatives, assumptions, disqualifiers and review trigger. A major product release, changed scale or new external audience should reopen the scorecard.
Do not require perfect certainty before learning, but keep experiments portable and data recoverable while confidence is low.
Amplified Pi makes the runtime choice explicit before implementation becomes inertia. The best architecture is not the one that produces the fastest demonstration. It is the simplest one the organization can operate, change and eventually leave.