When to Hire a Dynamics 365 Consultant vs. DIY Implementation
A decision guide for teams asking whether their Dynamics 365 or Power Platform project really needs a developer, and which parts of it do.
Can you really implement Dynamics 365 or the Power Platform without a developer? For a large part of a first rollout, yes. Forms, views, business rules, business process flows, dashboards, security roles, and most Power Automate cloud flows are configuration, and a capable maker can take a team a long way with none of it written in code. Expert help becomes necessary at a predictable set of walls: pricing and discount rules the price list cannot express, SLA behaviour beyond status and calendar, data migration that has to preserve relationships and history, real record volumes, integrations with their own authentication, and separated environments with managed solutions. This guide names those walls so you can tell which side of them you are on. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy delivering from Yerevan, Armenia.
Two notes before the detail. First, we sell exactly the thing this page is asking you to consider buying, so the test we hold ourselves to below is that every wall is a documented platform behaviour you can verify yourself rather than a scare story. Where the do it yourself route is genuinely the right one, the page says so. Second, we publish no benchmark figures and no percentages here. What a Dynamics 365 implementation costs, and what a stalled one costs to repair, depends on scope, data, and how much has already been built, and any number quoted without seeing an environment is decoration. Platform limits and configuration surfaces are Microsoft behaviour and Microsoft revises them, so check the current documentation before you build a plan on any single one of them.
The decision in three lines
Build it yourself when
The process you are automating is close to how the standard apps already work, the record volumes are ordinary, the data you are bringing in is small and clean, nothing outside Microsoft has to be integrated in a bespoke way, and being wrong is cheap to redo. This describes a great many first Power Platform builds, and a maker with time and a sandbox will beat waiting three weeks for a proposal.
Hire expert help when
You have hit one of the walls below and the workaround is starting to look like a second system: pricing rules the price list cannot express, SLA conditions beyond status and business hours, a migration carrying relationships and history, volumes that make canvas queries misbehave, an integration that needs its own authentication and retry logic, or a production environment with no separation and no managed solutions. Also hire when the build is now business critical and one person holds all of it in their head.
Either way, settle this first
Who owns this in year two, and where does it run. Most builds we are asked to rescue were not badly made. They were made in one environment, in the default solution, by one person who has since changed roles, and nobody decided any of that. Those two answers cost nothing to write down at the start and are expensive to reconstruct later.
What you genuinely can build without a developer
Worth being precise about, because the honest answer to the question in the title starts here. This is real, supported maker surface, and a team that uses it well needs far less custom development than it expects.
The data model and the apps on top of it
Tables, columns, relationships, choice sets, forms, views, charts, and dashboards are all designed in the maker portal. A model driven app is generated from that model rather than laid out by hand, which is exactly why a functional consultant or a strong business analyst can produce a working Sales or Customer Service app without a developer anywhere near it.
Rules that live on the form and on the table
Business rules set values, set requirement levels, show and hide fields, and validate input without code. Scoped to a form they can drive visibility; scoped to the table they apply wherever the record is written, with a narrower set of actions. For most field level logic this is the correct tool, and reaching for JavaScript before trying it is one of the more common self inflicted maintenance costs we find.
Process guidance and stages
Business process flows put a visible stage bar on the record and can require fields before a user moves on. They are configuration, they are solution aware, and they cover the majority of "make people follow the process" requirements without anything custom.
Automation with Power Automate
Cloud flows triggered by a Dataverse row change, a schedule, an approval, or an email cover a very large share of real automation. Approvals, notifications, document generation, and pushing a record into another Microsoft 365 service are all first party connector work. Classic workflows are the previous generation of this and new automation belongs in Power Automate.
The standard modules, properly configured
Sales has price lists, discount lists, quotes, orders, forecasting, and goal management. Customer Service has queues, routing, entitlements, knowledge, and service level agreements. Field Service has work orders, bookings, and a schedule board. A great deal of what buyers assume is custom development is a standard module nobody switched on or nobody configured past the demo.
Reporting and analysis
Views, charts, and dashboards inside the app, and Power BI on top of Dataverse for anything wider. Because the data sits in Dataverse rather than in a product silo, reporting across sales, service, and the rest of the business does not require an export layer somebody has to maintain.
A related trap sits on the other side of this list: assuming a requirement needs custom work when a standard module already covers it. Our guide to the customization mistakes we see most often covers the code that should never have been written in the first place.
The eight walls where no code runs out
Each one states what the platform gives you, where it stops, and what crossing it costs. If none of these describe your project, you probably do not need us yet. If two or three do, the question has already changed from whether to hire help to how much.
1. Pricing and discounts the price list cannot express
Dynamics 365 Sales gives you real pricing configuration: price lists per currency and per customer segment, price list items with pricing methods based on a currency amount, a percentage of list, or a markup or margin on cost, rounding rules, and discount lists that apply an amount or a percentage across quantity bands. That covers standard commercial models and it covers them without code. It stops when the price depends on something the price list does not know: a negotiated agreement per customer with its own validity dates, bundle logic where the discount depends on what else is on the quote, tiered rules that compound, a margin floor that has to block a save, or a rate imported from another system at the moment of quoting.
What crossing it costs. Sales exposes this deliberately. You can turn the system pricing calculation off in the Sales settings and register a plug-in that responds to the pricing messages, so your own code returns the price for a quote, order, and invoice line. That extension point exists precisely because configuration cannot express every commercial model. It is also the point where you now own compiled code in a production environment, with the testing, source control, and deployment that implies. This is the single most common reason a DIY Sales build ends up needing a developer.
2. SLA rules beyond status and business hours
Service level agreements in Customer Service are configuration too, and quite deep configuration. Enhanced SLA items carry applicable when, success, pause, and warning and failure conditions, each with its own KPI, and the clock can be measured against a customer service schedule so it does not run outside working hours. Pause behaviour is driven from case statuses nominated in the service configuration settings. It stops when the clock has to obey something that is not a status and not a calendar: a different clock per contract or per region, a pause that depends on who you are waiting for rather than what the status says, an escalation chain with its own approval, or a KPI that has to survive a case being reassigned between teams with different hours.
What crossing it costs. The usual crossing is a Power Automate flow or a plug-in that writes the status or an SLA related field on the case, and it is worth knowing that these are also the two most common causes of SLA timers that appear to pause at random. Our guide to fixing SLA timer pauses walks through diagnosing exactly that, and it is a good illustration of the wider point: the automation somebody added to work around a configuration limit becomes the thing the next person has to debug.
3. Migration that has to keep relationships and history
Bringing data in is where most DIY implementations first discover they are past the line, because the easy path works right up until it does not. The import wizard and an Excel template are genuinely fine for reference data and small lists. They stop at the point where rows have to resolve lookups to records that do not exist yet, where the same record arrives twice from two sources and has to be matched rather than duplicated, where created on dates and record ownership have to be preserved so the history means anything, where notes and attachments have to come across as files, and where the row count is high enough that per row logic and platform throttling become the constraint rather than the file size.
What crossing it costs. The competent version of this is a staged migration: clean and key the data outside the platform, load in dependency order using alternate keys on source identifiers, disable the per row logic while loading, write in bulk rather than one row per request, and reconcile before switching automation back on. That is a workstream with its own plan and its own rehearsal, not a task somebody does on the Friday before go live. Two pages on this site go through it in detail, one for a Salesforce source and one for volume in general.
4. Volume the app was never tested against
This one is invisible in a demo and obvious in production. Canvas apps delegate what they can to Dataverse, and everything they cannot delegate is evaluated only against the rows they have already pulled back, which is a few hundred by default and capped in the low thousands even when you raise the setting. A filter or a lookup written the wrong way against a large table therefore returns an answer that is wrong rather than slow, and it is right during testing because the test data was small. Model driven views, plug-ins written without regard for query cost, and flows that loop row by row have their own versions of the same surprise.
What crossing it costs. The fix is usually design rather than code: delegable queries, filtering at the source, aggregation done in Dataverse or in Power BI, and testing at realistic volume before anybody trusts a number on a screen. Where the requirement genuinely cannot be delegated, the answer is a proper server side component rather than a bigger row limit. Knowing which of those two situations you are in is the expertise being bought.
5. Integrations with their own authentication and failure modes
The connector library covers an enormous amount, and if the other system has a maintained connector then a maker can integrate it. It stops when the other side needs a client credentials flow you have to configure, a custom pagination or batching scheme, a webhook you have to receive and authenticate, ordering guarantees, or idempotency so that a retry does not create a duplicate record. It also stops at error handling: a flow that has never been given a retry policy or configured run after behaviour looks fine for months and then silently drops the record that mattered.
What crossing it costs. Custom connectors, Azure Functions, service principals, and plug-ins registered on the right message in the right stage. This is ordinary engineering, but it is engineering, and the part that most often gets skipped is not the happy path. It is what happens on the second attempt, on a partial failure, and at three in the morning when nobody is watching.
6. One environment, unmanaged, with no way back
This is the wall that costs the most and the one that looks like nothing at the time. Application lifecycle management on the Power Platform means separate development, test, and production environments, changes made in a named unmanaged solution rather than in the default one, and deployment into production as a managed solution so layers behave predictably and a component can actually be removed again. A DIY build almost always starts as the opposite: one production environment, everything in the default solution, changes made live.
What crossing it costs. Unwinding it later is real work: identifying what was customized, separating it into solutions, standing up the other environments, and moving to managed deployment without breaking what users depend on. Nothing about this is dramatic on any given day, which is exactly why it is left, and it is the reason a build that worked perfectly well for a year becomes unmaintainable in its second year.
7. A security model designed after the fact
Security roles are configuration, and for a single team with one way of working they are simple. The design questions arrive with the second team: business units and how ownership maps to them, teams as owners rather than individuals, sharing, hierarchy security for managers, and field level security for the handful of columns not everyone should read. The model is straightforward to design at the start and disruptive to change later, because ownership and business unit changes move records rather than just permissions.
What crossing it costs. There is no code required here, which is what makes it a different kind of wall. What is required is somebody who has seen the model fail before and asks the awkward questions in week one, when the answer is a design decision rather than a migration.
8. Interface behaviour the form designer does not have
Most requests to make a screen behave differently are met by the standard designers, and should be. What the designers do not give you is a genuinely different component: a board a user drags cards across, a chart from a specific library, a scheduler, a map, an editable grid with rules of its own, or a rich viewer for data that arrives as raw text. Those are code components built with the PowerApps Component Framework in TypeScript, packaged into a solution and imported like any other component.
What crossing it costs. A code component is the clean way to cross this line, because it is a supported, packaged, versioned artefact rather than script layered onto a form. The tempting alternative, JavaScript pasted onto form events with no repository behind it, is the version we most often meet during a rescue, and by then nobody can say what it does or whether it is safe to remove.
Three of those walls have full guides on this site. For service level agreements, see why SLA timers appear to pause at random and how to fix it. For migration, see the Salesforce to Dynamics 365 data migration guide and, for volume specifically, importing millions of rows into Dataverse.
For custom interface components, the PCF controls development service page explains what a code component is, and team versus freelancer for PCF work is the buying decision one level down from this page.
Signs the build has already gone past the line
These are the patterns we meet when we are asked to take over an environment somebody else built. None of them mean the work is worthless, and most of what we inherit is worth keeping. They do mean the next change will cost more than the last one.
Changes are made directly in production because there is nowhere else to make them, and everything lives in the default solution.
Production flows and connections are owned by one person's account, and that person has changed role, changed team, or left.
There is JavaScript on forms or a plug-in in the environment, and nobody currently employed can say what it does or where the source is.
Users have quietly gone back to a spreadsheet for the part of the process the system was bought to fix, and are re-entering the result afterwards.
Every new requirement now starts with a workaround for a previous workaround, and estimates keep growing for changes that sound small.
Reports disagree with each other, and the conversation has moved from what the numbers mean to which report to trust.
The go live date has moved more than once and nobody can state, in one sentence, what is left to do.
If several of those are true, the useful next step is an assessment rather than another sprint. Our rescue and takeover guide sets out what a proper assessment covers, and the health check is the smaller version for a build that is running but unproven.
The middle path most teams should take
The choice is rarely do everything yourself or hand everything over. Four shapes of engagement sit between those two, and for most in house teams one of them is the right answer.
A design review before you build
The cheapest expert hours in a Power Platform project are the ones spent before anything exists. Someone reads your process, your intended data model, your environment plan, and your security requirements, and tells you which parts are standard configuration and which parts are the walls above. Buyers who do this arrive at the same destination having built less.
A specialist for the part that is genuinely code
Your makers keep the apps, the flows, and the model, and a developer builds the piece that has to be built: the pricing plug-in, the integration, the code component, the migration. This is the most common shape of our work with in house teams, and it keeps ownership where it belongs rather than making a consultancy the permanent gatekeeper of your own system.
A health check on what already exists
If a build is running but you cannot tell whether it is sound, an assessment of the environment, the solutions, the customizations, the security model, and the integrations tells you what is fine, what needs work, and what has to be rebuilt. It is a much smaller purchase than a rescue and it is the one that prevents needing a rescue.
A takeover when the project has stopped
Where an implementation has stalled or a supplier relationship has ended, the work is to assess honestly, stabilise what users depend on, and finish. We do this as a named service, including on environments built by somebody else, and the first deliverable is always an assessment rather than a promise.
What this actually costs, honestly
We publish no percentages and no benchmark figures on this page, because we cannot evidence them for your project. What we can tell you is where the money goes.
Do it yourself is not free, it is differently paid for
The licences are the same either way. What changes is whose time is spent, and it is usually the time of the person who understands the business best, taken from the job they were hired to do. That cost is real and it never appears on an invoice, which is why it is systematically left out of the comparison.
The expensive line item is rework, not build
Almost nothing we are called in to fix was expensive to build. It was expensive to unwind: a data model that has to change after a year of records, a security model that has to be redesigned once a second business unit exists, a single environment that has to be split, an integration that has been silently dropping records. The cost of getting these wrong is not proportional to the cost of getting them right.
Ask what the second year costs, not the first
Any route can deliver something that works in month one. The question that separates them is what happens at the next release wave, at the next change request, and on the day the person who built it is unavailable. Decide who owns the system, where its source lives, and how a change reaches production, and the first year price is much easier to compare honestly.
What actually drives a quote
We do not publish fixed prices, because scope drives everything: how many users and apps, how much of the process is standard configuration against custom development, how much data has to be migrated, and how many systems have to talk to each other. We quote on time and materials or fixed price per milestone after a scoping conversation, so you see the basis before you commit. Delivering from Yerevan puts our rates well below Western European and US consultancies for the same seniority of engineer.
Eight questions that settle it
Answer these about your own project. Each one points at a specific wall above, so the output is a list of the parts you need help with rather than a verdict on the whole thing.
Does anything in your pricing depend on more than a price list and a quantity band?
If yes, you are at wall one. Confirm it early, because the workaround people reach for first is a flow that overwrites the line total, and that is the version that breaks quietly.
Do your service commitments vary by customer, contract, or region?
If yes, map them against applicable when, pause, and success conditions before you promise them to anyone. If they do not map, the requirement needs design work rather than more configuration.
Are you bringing in history, or just today?
History means relationships, ownership, original dates, and attachments, and it means reconciliation. Starting clean is a legitimate and much cheaper decision, and it should be a decision rather than a discovery.
How many rows will the biggest table hold in three years?
If the honest answer is hundreds of thousands or more, canvas app delegation and query design stop being theory. Test against realistic volume before anybody depends on a screen.
Does anything outside Microsoft 365 have to read or write records?
If yes, the questions are authentication, retry, duplicate prevention, and who gets told when it fails. A connector answers the first part of that and none of the rest.
Where do you make changes today?
If the answer is production, that is the wall that costs the most later. Splitting environments and moving to managed solutions is easier now than at any point in the future.
If the person who built this were unavailable for a month, what would happen?
If the answer is that changes stop, you have a single point of failure regardless of how good the build is, and that is an ownership problem rather than a technical one.
Is anyone still doing the old process in parallel?
A spreadsheet running alongside the system is the clearest signal that a requirement was never actually met. Find out which one before adding anything new.
How Solzet fits in
Stated plainly, so you can hold it against doing it yourself or against another supplier.
One platform, not a general software shop
We work on Dynamics 365 Customer Engagement and the Power Platform: Sales, Customer Service, Field Service, Customer Insights, Power Apps, Power Automate, Power Pages, Dataverse, and PCF code components in TypeScript and React. That is the whole of our scope, narrow on purpose, because the walls on this page are only routine to a team that meets them every week. If what you need sits outside it, you will hear that at the first conversation rather than three weeks into a project.
Buy the part you need
Three engagement models: a dedicated resource on a three to twelve month contract, time and materials against a backlog, or a fixed price deliverable. A design review, one plug-in, one migration, or a full implementation are all normal sizes of work. We would rather scope the piece you cannot do than replace a team that is doing fine.
You own the result
Source in a repository you own, solutions your admin imports, and documentation good enough for another developer to pick the work up. We use your Azure DevOps, GitHub, or Jira and meet over Teams or Zoom. Contracts are B2B, with NDA, a GDPR compliant data processing agreement, and IP ownership set out in the statement of work.
Certified engineers, one time zone, three languages
We deliver from a single hub in Yerevan, Armenia, at GMT+4, which leaves roughly four to six hours of daily overlap with Western Europe 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, and we work in English, Armenian, and Russian.
The services themselves are described under Dynamics 365 Customer Engagement consulting and Power Platform consulting, and if you are a Microsoft partner rather than an end client, the same team works white-label under Dynamics 365 subcontracting.
Кратко по-русски: реально ли без разработчика?
Во многом да. Формы, представления, бизнес-правила, бизнес-процессы, роли безопасности, дашборды и большинство облачных потоков Power Automate настраиваются без единой строки кода, и значительная часть внедрений Dynamics 365 действительно начинается именно так.
Разработчик становится необходим там, где заканчивается конфигурация: нестандартное ценообразование и скидки, которые не выражаются прайс-листом; SLA-правила сложнее статуса и календаря рабочего времени; миграция данных с сохранением связей, истории и вложений; большие объёмы записей, где перестаёт работать делегирование запросов в canvas-приложениях; интеграции с собственной аутентификацией и обработкой ошибок; разделение сред разработки, тестирования и продуктива с управляемыми решениями; продуманная модель безопасности; и собственные элементы интерфейса на PowerApps Component Framework.
Разумный вариант для большинства команд не «отдать всё подрядчику», а купить именно ту часть, которую невозможно сделать конфигурацией. Мы работаем из Еревана на английском, армянском и русском языках.
Frequently Asked Questions
Can we really implement Dynamics 365 without a developer?
For a large part of a first implementation, yes. Tables, relationships, forms, views, business rules, business process flows, security roles, dashboards, and most Power Automate cloud flows are configuration, and a capable functional consultant or business analyst can deliver a working Sales or Customer Service app without writing code. What reliably requires a developer is a shorter list than most vendors imply: pricing and discount logic the price list cannot express, service level agreement behaviour beyond status and business hours, data migration that has to preserve relationships and history, real record volumes where canvas app delegation limits start returning wrong answers rather than slow ones, integrations that need their own authentication and retry handling, environment separation with managed solutions, and custom interface components built with the PowerApps Component Framework. The useful question is not whether you need a developer for the project. It is which of those walls your particular project actually hits.
What is the first thing that usually forces a DIY Dynamics 365 project to hire someone?
In our experience it is pricing, and closely behind it, data migration. Dynamics 365 Sales price lists, price list items, and discount lists cover standard commercial models well, but as soon as pricing depends on a negotiated customer agreement, on what else is on the quote, on compounding tiers, or on a margin floor that has to block a save, configuration runs out. Sales anticipates this: the system pricing calculation can be switched off so a plug-in supplies the price instead. That is a supported extension point and it is also compiled code in your production environment, which is a different kind of commitment from a business rule. Migration forces the issue for a different reason: the import wizard works right up until rows have to resolve lookups, match rather than duplicate, and carry original dates and attachments across.
How do I know if my Power Platform build has already gone too far to fix myself?
The reliable signals are ownership and environment signals rather than technical ones. Changes are made directly in production because there is nowhere else to make them. Everything is in the default solution. Production flows and connections are owned by an individual account belonging to someone who has moved on. There is script on a form or a plug-in in the environment and nobody can say what it does. Users have quietly gone back to a spreadsheet for the part of the process the system was supposed to fix. Every new requirement starts with a workaround for a previous workaround. None of these mean the build is worthless, and most of what we take over is worth keeping. They do mean the next change costs more than the last one, and that curve does not flatten on its own.
Is it cheaper to build it ourselves?
On the invoice, yes. The comparison people usually miss is that a do it yourself build spends the time of whoever understands the business best, taken from the job they were actually hired for, and that the expensive part of these projects is rarely the build. It is the rework: a data model changed after a year of records, a security model redesigned once a second business unit exists, a single environment split into three, an integration that has been quietly dropping records. A middle route is normally the best value. Keep the apps, flows, and model with your own people, and buy the specific pieces that are genuinely code, plus a design review early enough to matter. We do not publish fixed prices because scope drives everything, and we quote on time and materials or fixed price per milestone after a scoping conversation.
What can a citizen developer safely own long term?
The app layer and the process layer, provided the environment underneath them is set up properly by somebody who knows how. Forms, views, dashboards, business rules, business process flows, and most cloud flows are exactly what the maker tools were designed for, and a business owned team maintains them faster than an external supplier can. What should not sit with a single citizen developer is the environment strategy, the solution and deployment approach, the security model, anything holding compiled code, and any integration with an external system. The healthy pattern is a maker team that owns the everyday build on foundations a specialist laid, with a named person to call when a requirement crosses one of those lines.
Can you work with our internal team rather than taking the project over?
Yes, and it is a common arrangement. Your makers keep the model, the apps, and the flows, and we take the parts that are genuinely engineering: a pricing plug-in, an integration, a code component, a migration, or the environment and solution setup. We can also work the other way round, reviewing a design before anything is built or auditing what already exists and telling you plainly what is sound. Engagement models are a dedicated resource for three to twelve months, time and materials against a backlog, or a fixed price deliverable, whichever matches how you buy. The point of every one of them is that your team keeps ownership of your own system.
Our implementation has stalled. Do we start again?
Usually not. Most stalled implementations contain a large amount of work worth keeping, and the problem is a specific set of decisions rather than the whole build. The first step is an honest assessment: requirements and process fit, how the standard modules are configured, the state of the customizations and code, security and data quality, integrations, platform health, and who actually owns delivery. That produces a list of what is fine, what needs work, and what has to be rebuilt, with an estimate against each. Only then is starting again a decision anybody can make with information. We run this as a named rescue and takeover service, including on environments originally built by another supplier.
Реально ли внедрить Dynamics 365 без разработчика?
Во многом да. Формы, представления, бизнес-правила, бизнес-процессы, роли безопасности, дашборды и большинство облачных потоков Power Automate настраиваются без кода, и значительная часть первого внедрения действительно делается силами функционального специалиста. Разработчик нужен там, где заканчивается конфигурация: нестандартное ценообразование и скидки, которые не выражаются прайс-листом и требуют плагина; SLA-правила сложнее статуса и календаря рабочего времени; миграция данных с сохранением связей, истории и вложений; большие объёмы записей, где перестаёт работать делегирование запросов; интеграции с собственной аутентификацией и обработкой ошибок; разделение сред и управляемые решения; и собственные элементы интерфейса на PowerApps Component Framework. Solzet работает из Еревана на английском, армянском и русском языках, и мы одинаково спокойно берём как отдельный кусок работы, так и внедрение целиком.
Not sure which side of the line you are on?
Describe the process, the volumes, and what you have built so far. You will get a straight answer about which parts are configuration your own team can own and which parts are genuinely engineering, and a scope for only the second list. Solzet delivers Dynamics 365 Customer Engagement and Power Platform work from Yerevan, Armenia, to clients and Microsoft partners across Europe and the US.