Hire PCF Developers: In-House Team vs. Upwork or Toptal Freelancers
A decision guide for buyers choosing how to commission PowerApps Component Framework development: a freelance contractor from a marketplace, or a dedicated Dynamics 365 and Power Platform team.
Should you hire a freelance PCF developer on Upwork, or engage a dedicated team? For one small, tightly specified control, a freelancer is a reasonable and fast choice. For a control your business depends on, a set of controls, or anything that has to survive Microsoft release waves, a specialist team is the safer buy. The real trade is speed and low overhead against knowledge silos and quality you screen yourself. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia, and PowerApps Component Framework development in TypeScript and React is one of our core services, delivered to end clients and white-label to other Microsoft partners.
This guide is written for the technical buyer doing the comparison, not as an argument that marketplaces are bad. Upwork and Toptal are legitimate ways to buy development, and we have no interest in pretending otherwise. What follows is what a PCF engagement actually contains beyond writing React, where each buying route tends to hold up or fall over, and the questions that separate a developer who has shipped PowerApps Component Framework controls into production from one who has read about them.
What is the decision, in three lines?
Hire a freelancer when
The control is small, the specification is unambiguous, someone technical on your side can review what comes back, and you can live with rebuilding it if the developer becomes unavailable.
Engage a specialist team when
The control is business critical, more than one is coming, it touches the wider Dynamics 365 build, or it has to be maintained through Microsoft release waves by somebody with a name and a contract.
Either way, decide this first
Who owns the control in eighteen months, and what the deliverable contains beyond a working demo. Buyers who settle those two questions before contracting rarely regret the route they chose. Buyers who do not usually regret both.
Your PCF developer has left and the deadline has not moved: what are your options?
If your only PCF developer has resigned and the client date has not moved, you have four honest routes. Phase the delivery and renegotiate scope with the client, so the critical control ships on time and the rest follows. Bring in senior PCF capacity on a short engagement, which costs more per day but can start within days if the repository and environments are in order. Simplify the module to supported out-of-the-box controls, trading fit for certainty. Or slip the date, early and in writing. Whichever you choose, hand the new developer the repo, build chain, solution layering and control manifests on day one, and test their skill with a small paid task rather than a CV.
| Route | Cost | Risk | How fast it starts |
|---|---|---|---|
| Phase the delivery and renegotiate scope | Lowest direct cost. The price is commercial: a harder client conversation and possibly a concession on the later phase. | Low technical risk if the phase one control is genuinely self-contained. Relationship risk if the client hears about it late. | Immediately. It is a conversation and a revised plan, not a hire. |
| Short senior PCF engagement | Higher per day than the developer who left, but bounded by a defined scope and end date, with no recruitment cost. | Moderate. Depends heavily on the state of the handover pack below; a missing repository or unreproducible build eats the first days. | Days, not weeks, when access and source are ready. Longer if the build only ever ran on the laptop of the developer who left. |
| Simplify to supported out-of-the-box controls | Low build cost. Rework later if the custom UI was a firm client requirement rather than a preference. | Low platform risk, since Microsoft maintains first party grids, forms and business rules. Acceptance risk if users expected the custom experience. | Immediately, with an admin or functional consultant rather than a PCF specialist. |
| Slip the date | No extra build cost. Commercial cost in penalties, goodwill or a delayed invoice, depending on the contract. | Low delivery risk, high relationship risk if it is announced late. Also the risk that a second slip follows if nothing else changes. | Immediately, but it only helps if you also start one of the other three routes. |
The routes combine. The most common workable plan is to phase scope with the client so the one control they cannot go live without is protected, put senior capacity on that control, and fall back to first party controls for the screens where a standard grid or form is good enough. Before simplifying, check the gates in the build versus buy section below: the platform may already cover more of the module than the original brief assumed.
The day-one handover pack
Whoever picks the work up, the first days are lost or saved by what is ready for them. If the developer is still serving notice, collect this before they go.
The repository, complete and pushed
Every control project in source control you own, including branches with unmerged work, package.json and the lock file. Confirm this before the developer leaves, because local-only commits are the most common thing that disappears.
A build chain someone else can run
The Node.js version, the Power Platform CLI version, how the control is built and how the solution project is packaged. The test is simple: a second person clones the repository on a clean machine and produces the same solution file.
Solution layering and versions
Which solution each control ships in, the publisher prefix, managed or unmanaged in each environment, and the current version numbers. A new developer who imports an unmanaged copy over a managed control creates a layering problem that costs more time than the control itself.
Control manifests, explained
ControlManifest.Input.xml for each control, plus a short note on why properties are bound, input or output, which features are declared, and which hosts the control supports. The manifest is the contract with the forms that use it.
The test harness and test data
How the control is run locally in the PCF test harness, and a record or view in a development environment with realistic data volumes and a restricted test user.
Environment access and the open backlog
Accounts with the right security roles in development and test, access to the pipeline or the deployment steps, and the list of what is done, half done and not started against the client commitment.
Verify skill with a small paid task, not a CV
A CV and a confident interview do not tell you whether someone can work in your codebase this week. A short paid task does. Ask the candidate to clone your repository, reproduce the build on their own machine, then fix one known defect or add one bound property, and deliver a versioned solution that imports cleanly into a development environment. Paying for it keeps it fair and lets you give them real code under NDA. Watch whether they ask about the manifest, the hosts and the solution version before they start, which tells you as much as the result. The screening questions further down this page make a good follow-up conversation.
Solzet takes on exactly this kind of short, senior engagement: picking up an existing control, reproducing its build and finishing it against a fixed date, described on our PCF controls development page. Microsoft partners with a client commitment can bring us in under their own brand through white-label Dynamics 365 subcontracting, and if the gap is wider than one developer, our guide to Dynamics 365 staff augmentation covers adding senior capacity for longer. If the deadline pressure is a sign the platform itself is the wrong fit, we also build custom CRMs without Microsoft licensing.
What are you actually buying when you hire a PCF developer?
The reason this comparison is harder than hiring a front end developer is that a PowerApps Component Framework control is only partly a front end job. Five things sit underneath every engagement, and how a supplier handles them is what you are really choosing between.
The manifest and the component lifecycle, not just a React tree
A PCF control is declared in ControlManifest.Input.xml, which defines whether it is a field or dataset control, which properties are bound, input, or output, what resources it loads, and which features it needs. The code implements a lifecycle the platform drives: init, updateView, getOutputs, and destroy. Most of the defects we are asked to fix in controls built by someone else come from misunderstanding that lifecycle, typically work that belongs in init being repeated on every updateView, or state that should have been released in destroy leaking every time a user navigates between records.
Dataverse behaviour, not a generic REST API
Bound columns arrive through the context with their own formatting and type metadata. Dataset controls have paging, sorting, filtering, and selection that the host expects you to honour. Anything else you need comes through the Dataverse Web API, subject to the calling user security roles rather than yours. A control that ignores paging or assumes the developer own privileges looks perfect in a demo with twenty rows and fails in production against a real view and a restricted user.
The hosting context you are actually targeting
A control for a model-driven app form is not automatically a control that works in a canvas app or on the mobile app. Canvas hosting uses the virtual control type and canvas properties rather than Dataverse columns directly, and mobile and tablet layouts have to be designed rather than hoped for. Deciding the hosts up front is a scoping question, and it is the one most commonly left out of a marketplace job post, which is exactly where change requests and disputes come from later.
Packaging, solutions, and deployment
The deliverable is not a repository. It is a solution your admin can import: built with the Power Platform CLI, packaged as managed for the environments where nobody should be layering changes, versioned so an upgrade replaces the old control rather than sitting beside it. If the person who built the control is the only one who can produce that package on their own machine, you do not own a deliverable, you own a dependency.
Life after go live
Power Platform ships release waves twice a year. Controls carry dependencies on React and a component library, both of which move. Business requirements move faster than either. Someone has to own the control the day a dependency is deprecated or the form it lives on is redesigned, and whether that someone exists is a procurement decision you make at the start, not a technicality you discover later.
For a concrete example of the engineering involved, our guide to integrating third-party libraries such as Highcharts into a PCF control walks through webpack configuration, lifecycle handling, and the cleanup that keeps a control from leaking memory.
When should you build vs. buy vs. use free PCF controls?
Before you decide who builds the control, decide whether it needs building at all. There are three honest routes to a PCF control, and the hiring question only applies to one of them. A free component from a community gallery costs nothing and comes with nobody attached to it. A managed solution from Microsoft AppSource comes with a vendor and a subscription. A custom build costs the most once and is the only route where fit is guaranteed. Most requirements have a correct answer here, and it is not always the expensive one.
The short version: use free controls for generic UI on forms where being wrong is cheap, buy from AppSource when a vendor has already solved a whole commercial category and you want somebody accountable for it, and build when the control has to know your business rules. Everything below is the working.
Where to find open source PCF controls
Free PowerApps Component Framework controls are not hidden, but they are scattered across six places rather than one, and each is useful for a different reason.
PCF Gallery
The best known community catalogue of PowerApps Component Framework controls, at pcf.gallery. It is an index rather than a store: each entry is a screenshot, a short description, and a link out to the author repository or download. Most of what it lists is free and open source. Use it the way you would use a package index, which means treat the listing as the advertisement and the repository as the evidence.
GitHub directly
Search GitHub for the pcf and powerapps-component-framework topics and you will find controls that never made it into any catalogue, including forks that fixed the bug in the version you were about to install. Sorting by recently updated rather than by stars is the more useful filter here, because in this ecosystem a control that has not been touched in two release waves matters more than one with a modest star count.
The Microsoft sample repositories
Microsoft publishes code component samples in its PowerApps-Samples repository on GitHub and documents them on Microsoft Learn. These are written to demonstrate a technique rather than to be run in production, which makes them the best available reference for how a manifest, a dataset control, or a React based component is meant to be structured, and a poor choice for importing directly into a live environment.
The Creator Kit
A Microsoft published set of Fluent UI based components and templates for makers, distributed as a solution you import. It is closer to a supported starting point than a typical community control, and it is worth checking before you commission anything that is essentially a standard input, a rating, a breadcrumb, or a dialog.
Microsoft AppSource
The commercial end of the market. Here you are buying a managed solution from a vendor with a support address, a licence, and usually a per user or per tenant subscription. The important difference from a gallery control is not quality, it is that somebody is contractually on the hook for it.
Consultancy libraries
Firms that build controls for a living publish their own, in a mix of free and licensed. Ours are listed in our PCF controls library. The commercial terms vary widely, so the question to ask any consultancy library is the same one you would ask a vendor: what happens to this control at the next release wave, and who pays for that.
Whatever the source, do the same three checks before a free control touches a production environment: when it was last updated and against which tooling version, whether anyone is answering issues, and whether it talks to any service outside your tenant. The licence matters too, because it decides whether you may fork the control when you inevitably need to. None of this makes free controls a bad idea. It makes them a dependency, which is a different thing from a product. Our own published controls, free and licensed, are listed in the Solzet PCF controls library, and they should be read with exactly the same scepticism.
The decision matrix
The same factors, scored across all three routes. The free column wins several rows outright, and pretending otherwise would make the rest of this table worthless.
| Factor | Free open source control | AppSource managed solution | Custom built control |
|---|---|---|---|
| Upfront cost | Usually nothing. Download the solution or clone the repository and import it. | Low to start. Most listings offer a trial, and the first invoice is a subscription rather than a project. | The highest of the three, paid once. The specification work happens before the price exists. |
| Cost over five years | Nothing in licence fees, and whatever your own team spends keeping it alive. That second number is the one nobody budgets. | The same subscription every year, rising with your user count, for as long as the control is on the form. | The build, plus whatever maintenance you choose to buy. Beyond roughly year two or three this is often the cheaper line. |
| Fit to your process | Generic by design. Galleries are full of the controls that generalize well, which is precisely why they are free. | Configurable within the range the vendor anticipated. If your requirement sits outside it, no amount of settings will get you there. | Exact, because the requirement is the specification. This is the only route where fit is a decision rather than a coincidence. |
| Support commitment | None. An author answering issues is a courtesy, not an obligation, and it can stop without notice. | A real one, at the level the licence describes. Read what the SLA actually promises rather than what the listing implies. | Whatever your contract says. With a specialist partner this is normally a named support arrangement with the engineers who wrote the control. |
| Source code and IP | Open, and the licence decides what you may do with it. You can fork, which is a genuine advantage over the commercial route. | Closed. You hold a licence to use the control, not the control. | Yours, if you contract for it. Insist on explicit IP assignment and a build another developer can reproduce. |
| Who owns the next release wave | You do, the moment you import it. A free control that becomes load bearing has quietly made your team its maintainer. | The vendor, which is most of what the subscription buys. | Whoever you contracted. This is the question to settle before signing rather than after. |
| Feature ceiling | Fixed at whatever the author needed. Extending it means forking it, and a fork stops receiving upstream fixes on the day you create it. | Set by the vendor roadmap. You can request features and you cannot schedule them. | No ceiling other than the platform and your budget. Configurable properties can be designed in so makers change behaviour without a developer. |
| Review burden before go live | Highest. You are importing code Microsoft did not write into your tenant, so somebody has to read it, check what it calls, and decide it is safe. | Lower. The listing has passed Microsoft certification, and the vendor is identifiable and accountable. | Low, and internal. You reviewed the specification, and the supplier reviews the code before you see it. |
| Time to something working | Days. Nothing else is this fast when the control genuinely fits. | Days to weeks, mostly procurement rather than technology. | Weeks, and longer for a dataset control. The specification stage is a real part of the calendar. |
| Best fit | Generic UI, internal or low risk forms, a proof of concept, or a team with the capacity to own a fork deliberately. | A well understood commercial category such as a calendar, a document viewer, or a mapping component, where a vendor already solved it properly. | Your own business rules rendered in the UI, a control on a business critical form, or anything where the requirement is the point rather than an inconvenience. |
Five gates, in order
Read these top to bottom and stop at the first one that fires. That is your route.
Does the platform already do it?
Stop here first. The modern Power Apps grid, the editable grid, first party map controls backed by Azure Maps, business rules, and a well designed view cover more requirements than most PCF briefs assume. If a supported first party feature gets you most of the way, take it. The cheapest control is the one you never commission.
Is the behaviour generic?
If what you need is a tag renderer, a colour coded choice, an input mask, a rating, or a formatted number, a free gallery control probably exists. Search PCF Gallery and GitHub before you write a job post. Route: free and open source.
Is it a solved commercial category, and is the form business critical?
Calendars, document viewers, signature capture, and mapping components are categories where vendors have already invested years. If one fits and you want somebody contractually responsible for it, buy it. Route: AppSource.
Does it have to know your business rules?
The moment the control enforces your booking logic, your pricing, your approval sequence, or your stage transitions, ready made stops being an option. Configuration will get you approximately right, and approximately right on a form people use all day is a support ticket generator. Route: custom build.
Do you have the second half of the skill set in house?
PCF sits between TypeScript and React on one side and Dataverse, manifest design, and solution ALM on the other. If your team has both, build it internally. If it has the React half only, which is the common case, a specialist partner is the realistic route, and the questions further down this page are how you screen one.
Where the free and bought routes run out
Gates one to three cover a surprising amount of what arrives described as a PCF requirement, and if one of them answers your case you should take it and spend the money elsewhere. Gates four and five are where the market stops helping. Once the control has to enforce your rules, run on your own tables, render your own card fields, or move records through your own stages, there is no gallery entry and no AppSource listing that will get there, because the thing that makes the requirement yours is exactly the thing a generic component cannot contain. At that point the options reduce to two: an in house team that holds both the React half and the Dataverse and solution ALM half, or a specialist partner who does this as their trade. Most organizations do not hold both halves, which is why for complex custom UI a partner such as Solzet is realistically the only route that ends in a control you can still change in three years.
That is the work described on our PCF controls development service page. For the same decision worked through end to end with costed examples for schedulers, map pickers, and large dataset viewers, see our buy, build, or customize decision guide. For the same question answered against one concrete requirement, our custom Kanban board PCF guide compares the out of the box control, the community gallery controls, and a custom build, and custom Kanban board versus AppSource takes the commercial side of that comparison apart in detail.
How does a freelance contractor compare with a specialist team, factor by factor?
An even handed read on where each route holds up. The marketplace route wins on speed and on price, and those are real advantages, not consolation prizes.
| Factor | Freelancer on Upwork or Toptal | Dedicated PCF team |
|---|---|---|
| Speed to start | Fastest. You can post a job and be reviewing candidates the same day, and on a matched network like Toptal you can be talking to a screened developer within days. | Slower at the front. A specialist firm normally wants a scoping conversation and a written specification before quoting, which costs you time before any code exists. |
| Screening for the actual skill | On an open marketplace you own the screening. Profiles and ratings tell you about reliability and general development skill, not about whether someone has shipped a managed PCF solution into a production Dataverse environment. A curated network removes some of that burden but is organized around general software engineering roles rather than the Power Platform specifically. | Screening is the firm business. A specialist Dynamics 365 and Power Platform team is judged on its Power Platform work, and its people can be asked about certifications, published controls, and previous production deployments. |
| Knowledge silo and continuity | The engagement is one person. Everything they learn about your data model, your form, and your users lives with them, and it leaves when they do. If they become unavailable mid build, the work usually restarts. | More than one person can read the code, and context lives in the specification, the repository, and the documentation rather than in one head. A handover inside the team is inconvenient rather than fatal. |
| Review and consistency | Whatever the individual brings. There is no second pair of eyes unless you supply one, so quality is consistent within an engagement and varies a lot between engagements. If you have a strong Power Platform lead in house who can review the work, this matters far less. | Work is reviewed internally against a shared way of building controls, so a second and third control resemble the first rather than reflecting a different developer preferences. |
| Packaging and deployment discipline | Varies. Some freelancers deliver a clean versioned managed solution and a reproducible build. Others deliver a zip that was built once on their laptop. Ask before you contract, not after. | Solution packaging, versioning, and environment strategy are part of the standard deliverable because the firm expects to ship the next version too. |
| Maintenance after handover | Depends entirely on whether that person is still available and still interested. A control with no owner is fine until the first release wave or the first change request. | A named owner you can go back to, usually under a support arrangement, with the people who built the control still reachable. |
| Contracting, NDA, and IP | Marketplace terms plus whatever you add. Workable, but you are contracting with an individual, and your recourse if something goes wrong is limited in practice. | A B2B contract with a company, with NDA and data protection terms and explicit IP assignment. This is often the deciding factor for regulated buyers and for partners who need to pass their own client obligations down the chain. |
| Cost shape | Usually the lowest hourly rate, with no overhead attached. The cost you cannot see up front is the screening time, your own management time, and rework if the first attempt misses. | Higher rate, and normally a fixed price once the specification is approved, so the cost of a miss sits with the supplier rather than with you. You are buying a delivered control rather than hours. |
| Best fit | One isolated control, a clear specification, a low blast radius if it is wrong, and someone technical on your side to review the result. | Business critical controls, several controls, work that touches the wider Dynamics 365 build, or any situation where the control has to be maintained for years. |
Which four risks actually materialize?
These are the patterns we meet when a client asks us to take over a control somebody else built. None of them show up during the engagement. All of them show up afterwards.
The knowledge silo
A single developer builds the control, learns your data model and your users along the way, delivers, and goes. None of that context is written down anywhere, so the next change costs a rediscovery exercise. This is the risk that actually bites, and it bites late, usually when the original developer is no longer answering messages and the control needs a change the week of a rollout.
Quality you have to screen for yourself
PCF sits at an unusual intersection: TypeScript and React on one side, Dataverse and solution ALM on the other. Plenty of excellent React developers have never packaged a managed solution, and plenty of experienced Dynamics consultants have never written a component with a real render lifecycle. A marketplace profile does not distinguish those cases for you, which is why the screening questions further down this page matter more than the rate.
The handover gap
The engagement ends when the control works on the demo form. What is often missing is the part that makes it yours: the source in your repository, a build that runs on a machine other than theirs, the manifest choices explained, the solution versioning, and a note on what the control assumes about your data. Without those you have bought a working control and an undocumented liability.
No owner at the next release wave
Twice a year the platform moves, and your control dependencies move on their own schedule. Nothing dramatic usually happens on the day, which is the problem: the control quietly falls behind until something breaks and there is nobody whose job it is to fix it. Deciding who owns the control in year two is part of choosing how to buy it in year one.
When is a freelancer genuinely the right call?
We would rather tell you this than win an engagement that was never a good fit. If most of the following are true, hire the freelancer and spend the saving elsewhere.
The control is small and self-contained, such as a formatted field display, an input mask, or a simple choice renderer, and the specification is unambiguous.
You have a Power Platform lead in house who can review the code, the manifest, and the solution package, and who will own the control afterwards.
It is a proof of concept or an internal tool where being wrong is cheap and easy to redo.
You have already worked with the individual, know how they build, and are hiring them again rather than hiring from a profile.
Budget is the binding constraint and the honest alternative is not building the control at all.
Which eight questions screen any PCF developer?
Use these on a freelancer, on an agency, and on us. They are cheap to ask and they separate someone who has shipped controls into production from someone who has read the documentation carefully.
Walk me through the control lifecycle and what belongs in each method.
You want init for one time setup, updateView for reacting to changed inputs, getOutputs for values written back to the host, and destroy for tearing down listeners and instances. Someone who has only read the documentation tends to describe the methods correctly but not what belongs where.
What happens if you create your chart or grid instance inside updateView every time it fires?
The right answer is flicker, leaked DOM and listeners, and degrading performance as a user moves through records. This one question separates people who have shipped a stateful control from people who have not.
How do you handle a dataset with more rows than the page size?
Dataset controls receive a page, not the whole view. The answer should mention paging through the dataset API and what the control shows while more records load, rather than an assumption that everything is already in memory.
Which manifest property types will you use, and why?
Bound, input, and output properties behave differently, and the choice determines what the maker can configure without a code change. A developer who has done this a few times will ask what should be configurable before answering.
Where does the control run: model-driven form, canvas app, mobile?
Canvas hosting means a virtual control and canvas properties, mobile means a layout decision. If this does not come up before pricing, the scope is not settled and the change request is already written.
What exactly do I receive at the end?
A managed solution ready to import, the source in a repository you own, a build another developer can reproduce, and enough documentation to change it. Anything short of that is a control you rent.
How do you test it before I see it?
The local test harness for development, then a real environment with real data volumes, real security roles, and the browsers your users actually run. A demo on a form with a handful of rows proves very little.
What happens to this control at the next release wave?
Less about the technical answer and more about whether anyone has thought about it. Ask who you contact in eighteen months and what that costs, and get the answer before you sign rather than after.
What should you prepare before you hire anyone?
Most disappointing PCF engagements were underspecified rather than badly built. Arriving with these six answers gets you a better price and a better control from either route.
Data in and data out
Which table and columns the control reads, what it writes back, and what happens on save and on cancel. If it needs related records, say which relationships and roughly how many rows.
Where it lives
The exact form, view, or canvas screen, whether it replaces a field or a whole grid, and which apps and devices it has to work on.
The behaviour, in the language of your users
What someone can do with it, what happens when they do, what is disabled and when. A short list of concrete interactions is worth more than a mockup with no rules attached.
Volume and performance expectations
How many records realistically arrive, and what the control does when it is more than expected. This is what separates a control that survives production from one that only ever met test data.
Security and configurability
Which users see it, whether it must respect field level security, and which parts a maker should be able to change without calling a developer.
The deliverable itself
Managed or unmanaged solution, which environment it is imported into first, where the source lives, and who owns the intellectual property. Agreeing this before work starts avoids the most common end of engagement argument.
How does Solzet deliver PCF controls?
For completeness, here is the other side of the comparison stated plainly, so you can hold it against whatever a freelancer offers you.
A specialist stack rather than a general one
Our standard build is TypeScript and React with Fluent UI so controls look native inside a model-driven app, built with the Power Platform CLI and bundled with webpack. 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, which is what makes that stack routine rather than a first attempt.
A specification before a price
We scope what the control reads and writes, where it is hosted, and how it must behave, and quote a fixed price once that specification is approved. The point is not paperwork, it is that the risk of a misunderstanding sits with us rather than turning into your change request.
A deliverable you own
A managed solution ready to import into your Dataverse environment, the source code, and documentation your team can build from. If we disappeared tomorrow, another developer could pick the control up, which is the only sensible test of whether a handover was real.
The same people afterwards
Controls need changes as forms, data, and release waves move. Ongoing support and enhancement of what we built is a normal part of our work, done by the engineers who wrote it rather than by a support tier meeting the code for the first time.
Direct or white-label
Microsoft partners hire us to build PCF controls under their brand for their end clients, working under NDA with their tooling and their communication channels. Engagement models are a dedicated resource for a defined period, time and materials against a backlog, or a fixed price deliverable, whichever matches how you buy.
Certified engineers in one time zone
We deliver from a single hub in Yerevan, Armenia, at GMT+4, which gives a working day that overlaps Western European hours and reaches into 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.
More detail on the service is on our PCF controls development page, the controls we have published are in our PCF controls library, and the partner side of the work is described under Dynamics 365 subcontracting. If a control you already commissioned has stalled, our rescue and takeover guide covers how we assess and finish somebody else's work.
What do buyers ask about hiring PCF developers?
Should I hire a PCF developer on Upwork or engage a dedicated team?
Hire on a marketplace when the control is small and clearly specified, when you have someone technical in house to review the result, and when being wrong is cheap. Engage a dedicated team when the control is business critical, when several controls are coming, when it interacts with the wider Dynamics 365 build, or when it has to be maintained for years. The difference that matters is not the hourly rate, it is who carries the risk of a misunderstanding and who owns the control after the invoice is paid. On a marketplace both of those stay with you.
What is the difference between Upwork, a curated network like Toptal, and a specialist Power Platform firm?
Upwork is an open marketplace: anyone can create a profile, and you do the screening yourself against ratings and history. A curated network such as Toptal screens applicants centrally and matches you with someone from its pool, which removes part of the screening burden, though the pool is organized around general software engineering and design roles rather than the Power Platform in particular. A specialist firm sells a delivered outcome rather than a person: it scopes the work, prices it, reviews it internally, and remains contactable for the next version. All three routes are legitimate, and they suit different sizes of problem and different tolerances for risk.
Is a strong React developer enough to build a PCF control?
Not on their own, in most cases. PowerApps Component Framework work sits between two skill sets. On one side is TypeScript and React, which a strong front end developer already has. On the other is Dataverse and application lifecycle management: manifest design, bound and dataset properties, the Web API under the calling user security, paging and formatting from the host, and packaging into a versioned managed solution that an admin can import and upgrade. A React developer without the second half will usually produce something that demonstrates well and behaves badly in a real environment with real volumes and restricted users.
Where can I find open source PCF controls?
Six places, and each is useful for a different reason. PCF Gallery at pcf.gallery is the best known community catalogue and links out to author repositories, most of which are free and open source. GitHub itself, searched on the pcf and powerapps-component-framework topics, holds controls and forks that never reached a catalogue. Microsoft publishes code component samples in its PowerApps-Samples repository and documents them on Microsoft Learn, which are written to demonstrate technique rather than to run in production. The Creator Kit is a Microsoft published solution of Fluent UI components and templates worth checking before commissioning anything standard. Microsoft AppSource is the commercial end, where you buy a managed solution with a vendor and a licence behind it. Consultancies also publish their own libraries, ours included. Whichever source you use, check when the control was last updated, whether issues are being answered, what it calls outside your tenant, and what the licence permits, because once you import a free control into production you have become its maintainer.
Is it better to use a free PCF control, buy from AppSource, or build a custom one?
Work through it in order. If a first party platform feature already does it, take that. If the behaviour is generic, such as a tag renderer, an input mask, or a formatted display, a free gallery control probably exists and costs nothing but your own review time and your own maintenance. If it is a solved commercial category such as a calendar, a document viewer, or a mapping component and the form is business critical, buying from AppSource gets you a vendor who is contractually responsible for it. Build custom when the control has to enforce your own business rules, run on your own tables, or fit a process no vendor anticipated, because configuration will only ever get you approximately right and approximately right on a form people use all day generates support tickets. The cost lines cross too: a subscription is paid every year forever, while a commissioned control is paid once plus whatever maintenance you buy, and somewhere around year two or three the custom route usually becomes the cheaper one.
What should a PCF control deliverable actually include?
A managed solution file ready to import into your Dataverse environment, versioned so that an upgrade replaces the control rather than sitting alongside it. The source code in a repository you own, with a build that 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. Confirmation of 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 much 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 visualization is a project in its own right. The larger cost drivers are usually the ones 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.
Can I hire Solzet as a white-label PCF subcontractor?
Yes. Microsoft partners regularly hire us to build PCF controls under their brand for their end clients. We work under NDA, use your tooling and communication channels, and deliver controls your team packages and deploys as its own. It suits partners who need TypeScript and React expertise for a specific project without adding a permanent developer to the payroll. The commercial relationship stays between your organization and Solzet under a B2B contract that sets out scope, IP ownership, and confidentiality.
Can you take over a PCF control someone else started or abandoned?
Yes, and it is a common request. We read the manifest, the lifecycle implementation, and the solution packaging, tell you plainly what is salvageable and what is not, and then either finish it or rebuild the parts that cannot be saved. Where the control is one symptom of a wider stalled implementation, the same assessment applies to the whole environment rather than to the control alone.
Do you build PCF components for canvas apps as well as model-driven apps?
Yes. Code components have been supported in canvas apps for several years, and we build for both. The codebase is the same TypeScript and React, but a canvas component is declared as a virtual control in the manifest and interacts with canvas properties rather than with Dataverse columns directly. Which hosts a control must support is a scoping decision we settle before pricing, because retrofitting canvas support to a control designed only for a model-driven form is rarely a small change.
Our only PCF developer quit and the client deadline is fixed. What are our options?
Four realistic routes. Phase the delivery and renegotiate scope so the critical control ships on time. Bring in senior PCF capacity on a short engagement, which can start within days if the repository and environments are ready. Simplify the module to supported out-of-the-box controls. Or slip the date early and in writing. Many teams combine two, for example phasing scope while a senior contractor finishes the control the client cannot do without.
What should we hand a new PCF developer on day one?
The complete repository with any unmerged branches, the Node.js and Power Platform CLI versions and build steps, the solution names, publisher prefix, managed or unmanaged status and version numbers per environment, each ControlManifest.Input.xml with a note on its properties and hosts, the local test harness setup with realistic test data, environment access with the right security roles, and the open backlog against the client commitment.
How do we check a PCF contractor can really do the work before the deadline?
Pay for a small, real task instead of reading a CV. Ask them to clone your repository, reproduce the build, fix one known defect or add one bound property, and deliver a versioned solution that imports cleanly into a development environment. It takes little time, it is fair to the contractor because it is paid, and it shows in practice whether they understand the manifest, the lifecycle and solution packaging.
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.
Need a PCF control built properly?
Tell us what the control has to do and where it lives. You will get a scoped specification, a fixed price once it is approved, and a managed solution with source and documentation at the end. Solzet builds PowerApps Component Framework controls from Yerevan, Armenia, for end clients and white-label for Microsoft partners across Europe and the US.