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.
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.
What you are 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.
Freelance contractor versus 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. |
The four risks that 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 a freelancer is 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.
Eight questions that 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 to 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 Solzet delivers 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.
Frequently Asked Questions
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.
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.
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.