PCF Controls: Buy, Build, or Customize? A Decision Guide

How to choose between a ready made Power Apps Component Framework component, an in house build, and a tailored control from a specialist PCF development company.

Need a custom UI in Dynamics 365 or Power Apps? Power Apps Component Framework (PCF) controls give you almost complete freedom over how a field, a grid, or a whole section behaves, and they carry development cost and long term maintenance risk with them. This guide is the decision rather than the pitch: when to buy a ready made component from AppSource or a community gallery, when to build one in house from scratch, and when to hire a specialist PCF development company such as Solzet for a tailored control. Worked examples follow for the three requests we get most often, which are schedulers, map pickers, and large dataset viewers.

The short answer

  • Buy when the behaviour is generic, the lifespan is short or uncertain, the user count is small, and approximately right is good enough. Tags, colour coded choices, formatted fields, basic charts.
  • Build in house when you already have an engineer who has shipped a managed PCF solution before, and the control is small, internal, and cheap to be wrong about.
  • Commission a tailored control when it has to know your process, sits on a form the business runs on, has to survive years of release waves, or when the cost of a misunderstanding should sit with the supplier rather than with you.
  • Check first whether you need a control at all. Business rules, the modern Power Apps grid, first party map controls, the Field Service schedule board, and an embedded canvas app between them answer a large share of what arrives described as a PCF requirement.

Five questions that decide the route

Work through these in order. Most of the value is in the first one, and most of the cost is in the fourth.

  1. 1

    Does the platform already do this?

    Ask this before anything else, because the cheapest control is the one you never commission. Model-driven apps ship an editable grid and the modern Power Apps grid with in line filtering. Power Apps has first party map controls backed by Azure Maps. Dynamics 365 Field Service has a schedule board. Business rules, form scripting, a well designed view, or an embedded canvas app cover a surprising amount of what arrives on our desk described as a PCF requirement. If a supported first party feature gets you to eighty percent, take the eighty percent.

  2. 2

    How specific is the behaviour to your business?

    A control that renders a tag, a colour coded choice, or a formatted number is generic, and generic is exactly what the galleries are full of. A control that enforces your booking rules, your pricing logic, or your approval sequence is not generic, and no ready made component will get closer than approximately right. The more of your own process the control has to know, the further you move from buying and towards building or commissioning.

  3. 3

    How long does this have to live?

    A control for a campaign, a pilot, or an internal tool that will be redone next year has a very different economic answer from a control that sits on the main case form for the next five years. Ready made components are cheap to start and cost the same every year forever. A commissioned control costs more once and then costs whatever maintenance you choose to buy. Somewhere between year two and year four those two lines usually cross, and where they cross depends on your user count.

  4. 4

    Who owns it in year two?

    The Power Platform ships release waves twice a year, and a control also carries its own dependencies on React and a component library that move on their own schedule. Nothing dramatic happens on release day. The control quietly falls behind until a change request or a browser update exposes it. Whether a named person or supplier owns that control eighteen months from now is a procurement decision made at the start, not a technicality discovered later.

  5. 5

    What is the blast radius if it is wrong?

    A control on a form five people use in an internal process is cheap to get wrong and cheap to redo. A control that every seller or every service agent touches on every record, or one that writes to data your invoicing depends on, is not. High blast radius pushes you towards a route where somebody other than you carries the risk of a misunderstanding, which in practice means a fixed price against an approved specification.

The three routes side by side

The rows that decide this are rarely the ones on the quote. Cost every route across all three columns before comparing any two of them on price alone.

FactorBuy ready madeBuild in houseCommission tailored
Time to a working versionFastest by a wide margin. Import the solution, configure it on the form, and you are looking at it the same day.Slowest in practice, because the clock starts when somebody on your team has learned the framework, not when they start typing.In between. A scoping conversation and a written specification come first, then a build measured in days to a few weeks depending on complexity.
What you pay up frontLittle or nothing. Community gallery controls are usually free and open source, and AppSource apps normally start with a trial.Your own engineering time, which is real money even when it does not appear on an invoice, plus the learning curve if this is the first control.The largest single up front number of the three, and the only one of the three that is knowable before work starts.
What you pay every yearA per user or per tenant subscription in most commercial cases, which grows as your user count grows and never stops.Nothing to a vendor, and whatever internal capacity you keep aside for release waves and change requests, which teams routinely forget to budget.Whatever support you choose to buy, from nothing at all to a maintenance arrangement. The control itself is already yours.
Fit to your processAs close as the vendor decided to make it. Configuration options are generous in good components and are still someone else idea of what should be configurable.Exact, because you decide every behaviour. This is the whole point of the route.Exact, provided the specification was written properly. The specification is the deliverable that determines whether this is true.
Configurability without a developerUsually strong. Ready made components have to serve many customers, so they expose a lot of configuration.Whatever your team built. First controls tend to hard code the things that later need to change.A scoping decision. Deciding which behaviours a maker changes without calling a developer is part of designing the manifest properties.
Who owns the code and the IPThe vendor. You have a licence to use it, and open source community controls come with a licence you should read before you fork.You do, completely.You do, when the contract says so. Solzet assigns IP in the statement of work and delivers source alongside the managed solution.
Where your data goesWorth checking. Some components stay entirely inside your tenant. Others call a vendor service, a geocoding API, or a licence server, which is a data protection question and not just a technical one.Wherever you send it, and you know exactly where that is.Same as building. We work inside your tenant, and any external service a control depends on is named in the specification before it is built.
Release wave riskThe vendor problem, as long as the vendor still exists and still maintains the component. Abandoned gallery controls are a real category.Yours. Somebody has to test against the next release wave and keep the dependencies current.Yours to own, and a normal thing to hand back to the people who wrote it under a support arrangement.
Who fixes it the morning it breaksVendor support, at vendor speed, on vendor priorities. For a free community control, nobody in particular.Your own team, if the person who wrote it is still there and still remembers it.The engineers who built it, which is the main reason to keep a maintenance arrangement rather than take the control and walk away.
Best fitGeneric behaviour, a short or uncertain lifespan, a small user count, and a low blast radius if it is not quite right.Teams with an existing Power Platform engineer who already ships solutions, and controls that are small, internal, and cheap to be wrong about.Business critical controls, several controls at once, anything that has to survive years of release waves, and anywhere the cost of a misunderstanding should sit with the supplier.

If the choice you are actually making is between an individual developer and a firm rather than between buying and building, that comparison is covered separately in our guide to hiring PCF developers against freelancers.

What each route costs that nobody puts on the quote

Every route has a list like this, including ours. A guide that only makes two of the three uncomfortable is an advertisement.

Buying a ready made component

  • The subscription is per user in most commercial components, so the price you evaluated at twenty users is not the price you pay at two hundred.
  • Configuration ends where the vendor decided it ends. The last ten percent of fit is the part your users complain about, and no amount of budget buys it.
  • A free community control on a gallery is a gift, not a contract. Check the last commit date and the licence before it becomes load bearing, because there is no obligation on anyone to update it for the next release wave.
  • Some components call out to a vendor service, which means your data leaves your tenant. That is a question for whoever signs your data protection agreements, not for the maker who installed it.
  • Removing a component later is not free either. Once a field or a grid has been rendered by it for two years, the form, the training, and sometimes the data model have shaped themselves around it.

Building it in house

  • PCF sits at an unusual intersection. TypeScript and React on one side, Dataverse and solution application lifecycle management on the other. Strong React developers frequently have never packaged a managed solution, and experienced Dynamics consultants frequently have never written a component with a real render lifecycle.
  • The lifecycle is where first controls go wrong. Work that belongs in init gets repeated on every updateView, and state that should be released in destroy leaks every time a user moves between records. Both look fine in a demo.
  • A dataset control receives a page of records, not the whole view. Ignoring that produces a control that is perfect against twenty test rows and unusable against a real view.
  • The build has to be reproducible on a machine other than the one it was written on, or you own a person rather than a deliverable.
  • The genuine hidden cost is bus factor. One engineer learns your data model, your form, and your users, writes none of it down, and then changes team.

Commissioning a tailored control

  • It is the slowest of the three to start, because a specification comes before a price and writing one properly takes your time as well as ours.
  • It is the largest up front number. If the control is generic and short lived, this route is simply the wrong answer and we will say so on the call.
  • A bad specification produces an expensive control that is exactly wrong. The behaviour has to be described in the language of your users, with the volumes and the edge cases in it, or the change requests start on delivery day.
  • You still own the control afterwards. Commissioning transfers the build, not the twenty year maintenance question, unless you buy support as well.
  • If your requirement is generic, a specialist firm is the most expensive way to get something that already exists for free. The first job of a decent supplier is to check that before quoting.

Three real requests, and what we would actually advise

These are the three PCF requirements we are asked about most, and the answer is different for each one. Two of the three usually end in buying or extending something that already exists.

A scheduler or booking board

Check this first

Check what you already own first. If this is field service dispatch, Dynamics 365 Field Service ships a schedule board with resource scheduling, and rebuilding that in a control is an expensive way to arrive at a worse version of it.

What buying looks like

AppSource carries calendar and scheduling components, and for drag and drop over a single booking table with standard working hours they are usually good and quick. Priced per user in most cases.

What building actually involves

This is the request teams most often underestimate, and it is rarely the calendar rendering that costs the money. Recurrence, overlapping and conflicting bookings, resource working hours and exceptions, time zones per resource rather than per viewer, keyboard accessible drag and resize, and what happens when two dispatchers move the same booking at once. On top of that, the mature JavaScript scheduler libraries are commercial products with their own developer licences, so a component licence belongs in the budget before anyone estimates the build.

Our verdict

Buy or commission. Building a real scheduler in house from scratch is where we most often see a Power Platform team lose a quarter, and it is the example where the gap between a convincing demo and a production board is widest.

A map picker or location viewer

Check this first

Power Apps has first party map controls backed by Azure Maps, which need the geospatial features switched on for the environment and an Azure Maps key. Confirm those are not sufficient before commissioning anything.

What buying looks like

Map rendering is a solved problem, and there are good free options. Our own Solzet Map View control renders the records of any model-driven view or subgrid as markers on an interactive Leaflet map driven by latitude and longitude columns, and it is on our controls page alongside the free ones.

What building actually involves

The map is not the cost. Geocoding is. Turning addresses into coordinates is a paid API call for any provider worth using, it belongs cached in Dataverse columns rather than issued on every render, and somebody has to decide what happens to a record whose address does not resolve. There is a data protection question underneath it too, because sending customer addresses to a third party tile or geocoding provider is a decision for whoever owns your data agreements.

Our verdict

Buy or extend, in almost every case. The parts of a map requirement that are genuinely specific to you are the geocoding strategy, the marker clustering at your data volume, and what a click on a marker does next, and those are usually a small extension to an existing control rather than a new one.

A large dataset viewer or custom grid

Check this first

Model-driven apps ship an editable grid and the modern Power Apps grid with in line column filtering. If your requirement is mostly about editing in place or filtering faster, try those before commissioning a control.

What buying looks like

Generic grid components exist and are competent at generic grid things. They start to fall short exactly where your requirement stops being generic: conditional formatting driven by your own rules, columns computed from related records, or bulk actions specific to your process.

What building actually involves

This is where the framework itself sets the difficulty. A dataset control is handed a page of records, not the view. Rendering everything means paging through the dataset API, respecting Dataverse service protection limits, and not holding the whole result set in browser memory. Sorting and filtering belong pushed back to the dataset rather than performed in memory over a page you happen to hold, and rows need virtualising so scrolling stays smooth. None of that work is visible in a demo against twenty records, which is precisely why it gets left out of estimates.

Our verdict

Commission, or build only if you already have an engineer who has shipped a paged dataset control before. This is the example where a specialist earns the difference most clearly, because the entire gap between a demo and production sits in paging and virtualisation work that a demo will never reveal.

A fourth request, the Kanban board, gets a page of its own because the buy against build arithmetic there is unusually clean. See custom Kanban board against an AppSource app and the build guide for a Kanban PCF control. If your control needs a charting or visualisation library inside it, the guide to integrating third party libraries into a PCF control covers the licensing and bundling questions that come with that decision.

The fourth option: do not build a control at all

No supplier volunteers this one, which is exactly why it belongs on a decision guide. A meaningful share of the PCF requests we are asked to quote have a cheaper answer that is not a control.

  • Business rules and form logic cover conditional visibility, requirement levels, and simple calculations without any code component at all.
  • A well designed view with the right columns, sorting, and filters answers a lot of what arrives described as "we need a better grid".
  • An embedded canvas app gives you a custom screen inside a model-driven form, and a maker can change it without a developer or a deployment.
  • Power BI embedded in a form covers analytical display far better than a hand built chart control, and somebody else maintains the rendering.
  • Sometimes the honest answer is that the process is wrong rather than the user interface, and a control will make a bad process faster rather than better.

The wider version of this question, which is where no code configuration runs out and custom development begins, is covered in our guide to hiring a Dynamics 365 consultant against doing it yourself, and the failure modes of over customising a Dynamics 365 environment are in our customisation mistakes guide.

Total cost of ownership, which is where the decision actually lands

Comparing a subscription against a one off build price is comparing two different kinds of number, and it is why so many of these decisions get made on the wrong basis. A per user subscription is a line that keeps rising as your user count rises and never reaches zero. A commissioned control is a larger number once, followed by whatever maintenance you choose to buy. Somewhere between the second and fourth year those two lines usually cross, and exactly where depends on how many people use it.

That is not an argument for building. It is an argument for costing three years rather than one, in both directions. If the control will be replaced inside eighteen months because the process behind it is still moving, the subscription wins easily and the crossover never arrives. If it is going on the main case form for the rest of the decade at two hundred users, the arithmetic points the other way well before anyone has to argue about fit.

The number people leave out on the build side is year two onwards. A control is not finished at go live: release waves land twice a year, dependencies move on their own schedule, and the form it lives on will be redesigned by somebody eventually. Budget an allowance for that, however small, or you have not costed the build, you have costed the first version of it. This is the same discipline we apply on the licensing and renewal side, where the annual line is the one that decides the outcome.

If commissioning is the answer, what a specialist firm should give you

Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia, and PowerApps Component Framework development is one of our core services, delivered to end clients and white-label to other Microsoft partners. Here is what that looks like in practice, and it doubles as a checklist for evaluating anyone else.

We check the cheaper answers first

The first conversation is about whether you need a control at all, and then about whether one already exists. We publish free controls ourselves, so pointing you at an existing component rather than a quote is not a loss for us. A supplier who never reaches that conclusion is not scoping, they are selling.

A specification before a price

We scope what the control reads and writes, which hosts it must run in, what it does at your data volumes, and which behaviours a maker must be able to change without a developer. The price is fixed once that specification is approved, which puts the cost of a misunderstanding on us rather than into your change request budget.

A specialist stack rather than a general one

TypeScript and React with Fluent UI so controls look native inside a model-driven app, built with the Power Platform CLI. Simpler field controls are written in plain TypeScript where React would only add weight. We work on Dynamics 365 Customer Engagement and the Power Platform and nothing else.

A deliverable you own

A versioned managed solution ready to import into your Dataverse environment, the source code in a repository you own, a build another developer can reproduce, and documentation covering the manifest properties and what the control assumes about your data. If we vanished tomorrow, another developer could pick it up, which is the only sensible test of whether a handover was real.

Direct or white-label

Microsoft partners commission controls from us under their own brand for their end clients, working under NDA with their tooling and their repositories. Our case studies include a white-label engagement of eight controls for a UK Microsoft Solutions Partner, delivered into the partner Azure DevOps with their review process.

Certified engineers in one time zone

We deliver from a single hub in Yerevan, Armenia, at GMT+4, which overlaps the Western European working day and reaches the US morning. Our engineers hold Microsoft certifications including PL-200, PL-400, and PL-600 for the Power Platform and MB-210, MB-230, and MB-240 for Dynamics 365 Customer Engagement.

The full commercial detail sits on our PCF controls development service page, the controls we publish are on our PCF controls library, and the white-label engagement referenced above is written up as a PCF subcontracting case study.

Where we are the wrong answer

If your requirement is generic, commissioning a specialist firm is the most expensive possible way to obtain something that already exists, sometimes for free. A tag input, a colour coded choice, a JSON viewer, a formatted number: those are gallery territory, and several of them are on our own controls page at no cost. If you have a Power Platform engineer in house who has already shipped a managed solution, a small internal control is a good way for them to build the skill and a poor use of our invoice.

If the requirement is still moving, do not commission anything yet. A specification that changes weekly turns a fixed price into a change request argument, and neither side comes out of that well. Install something quickly, watch what real users complain about for a quarter, and let those complaints become the specification.

And if the problem lives in Business Central, Dynamics 365 Finance, or Supply Chain Management, that is outside what we do at all. We stay on the Customer Engagement side of Dynamics 365 and on the Power Platform. Where we are the right answer is a control that has to know your business, run against real data volumes, and still be working after several release waves, built by people who do this and nothing else.

Frequently Asked Questions

Should I buy a PCF control or build a custom one?

Buy when the behaviour is generic, the lifespan is short or uncertain, the user count is small, and being approximately right is acceptable. Build or commission when the control has to know your process, when it sits on a form your business runs on, or when it has to survive years of Microsoft release waves. The question that decides it is not the price of the component, it is what the control has to know about your business. A component that renders a tag or a colour coded choice knows nothing about you and should be bought. A component that enforces your booking rules or your pricing logic cannot be bought at any price.

What does a custom PCF control cost?

Effort varies far more by complexity than by supplier. A simple field level control such as a formatted display or an input mask is a short engagement. A medium control such as an interactive chart or a filtered lookup with custom UI is larger. A full dataset control such as a custom grid, a scheduler, or a map visualisation is a project in its own right. The larger cost drivers usually sit outside the code: how many hosts it must support, how much configurability the makers need, and how well specified the behaviour was before anyone started. Solzet quotes a fixed price once the specification is approved rather than an open hourly rate, and offers volume pricing to Microsoft partners commissioning several controls.

Are free PCF controls from a community gallery safe to use in production?

Frequently yes, and we publish free controls ourselves. Treat them as you would any other open source dependency rather than as a product. Read the licence before you fork it, look at when it was last updated and whether anyone is still answering issues, and check whether it calls any service outside your tenant. The risk is not that the code is bad, it is that nobody is under any obligation to update it for the next release wave. If a free control becomes load bearing for a business process, the sensible move is to take ownership of a fork deliberately and budget for maintaining it, rather than discovering the dependency the week it breaks.

Can we start with a ready made component and replace it later?

Yes, and for a genuinely uncertain requirement that is often the best sequence. Install something quickly, let real users work with it for a quarter, and use what they complain about as the specification for the tailored version. Two things make the swap cheaper later. Keep the data in your own Dataverse columns rather than in any structure the component owns, and avoid components that require their own tables to hold what should be your data. Where the swap gets expensive is when the form, the training, and sometimes the data model have shaped themselves around the component behaviour over two years.

Can we customise a PCF control we already have instead of rebuilding it?

Often, and it is usually the cheapest route when the base control is close. If it is open source, the licence decides what you may do, and forking means the fork is now yours and upstream fixes stop arriving on their own. If it is a control a previous supplier built for you, the questions are whether you hold the source, whether the build is reproducible outside their machine, and whether the manifest and packaging were done properly. We take over controls built by other suppliers, and the first piece of work is confirming those three things rather than reading the component code.

What should a commissioned PCF control deliverable include?

A managed solution file ready to import into your Dataverse environment, versioned so an upgrade replaces the control rather than sitting alongside it. The source code in a repository you own, with a build another developer can reproduce on their own machine. Documentation covering the manifest properties, what the control assumes about your data, and how to change it. And a written answer on who owns the intellectual property. If any of those are missing you have a control that works today and no ability to change it tomorrow.

How do we know whether our team can build the control in house?

Ask whoever would build it three questions. What belongs in init as against updateView, and what happens if you create your grid or chart instance inside updateView every time it fires. How you handle a dataset with more rows than the page size. And what exactly gets handed over at the end. The first separates people who have shipped a stateful control from people who have read the documentation, the second is the difference between a demo and production, and the third tells you whether you will own a deliverable or a person. Our guide on hiring PCF developers against freelancers has the full screening list.

Does Solzet build PCF controls for canvas apps as well as model-driven apps?

Yes, and the hosts are a scoping question rather than an afterthought. The same TypeScript and React codebase serves both, but data reaches the control differently: a canvas app has no Dataverse column to bind to, so values arrive through input properties set with Power Fx or a dataset bound to Items, and results go back through output properties. The component framework also has to be switched on per environment before code components appear in Power Apps Studio, and the Dataverse Web API is not available to a control running in a canvas app, so data access belongs on the app side.

Do you work on Business Central or Dynamics 365 Finance and Operations?

No. Solzet works on the Customer Engagement side of Dynamics 365, meaning Sales, Customer Service, Field Service, and Customer Insights, plus the Power Platform: Power Apps, Power Automate, Power Pages, Dataverse, and PCF controls. We do not work with Business Central, Finance, or Supply Chain Management. If a control has to display data that lives in one of those, we build the integration from the Power Platform side and work with whoever owns the ERP.

What if we already commissioned a control and it is not working properly?

That is a normal engagement for us and it starts with an assessment rather than a rewrite. Most of the defects we are asked to fix in controls built elsewhere come from the same handful of causes: work that belongs in init repeated on every updateView, state never released in destroy, a dataset control that assumed it received the whole view, or a control that assumed the developer own privileges rather than the calling user security roles. Several of those are cheaper to fix than to rebuild, and we will tell you which case you are in before quoting.

Not sure which route your control belongs in?

Tell us what the control has to do, where it lives, and how many records it faces. We will tell you whether something already does it, whether your own team should build it, or what a tailored one would cost. The first two answers are free and we give them regularly.

Get in TouchPCF Development Services

Building it yourself? Start with using PCF controls in canvas apps and browse the free controls we publish.