Separate the work from the tools
A business solution has two different kinds of cost: the work to plan, build, and support it, and the software and services that allow it to operate. Understanding both helps you compare proposals and plan beyond launch.
Solvency Studio’s service fees are separate from software and operating costs. Your proposal should explain what each charge covers, who supplies the service, and who is responsible for paying it.
What belongs in each category?
Not every project needs every item below. Use these categories to understand the proposal, rather than assuming every item is included or billed separately.
| Item | Cost category | What it covers |
|---|---|---|
| Assessment and planning | Solvency Studio service work | Review the process, requirements, feasibility, and proposed approach. |
| Development and testing | Solvency Studio service work | Build, connect, validate, and prepare the agreed solution. |
| Training and handover | Solvency Studio service work, as scoped | Prepare documentation, access, walkthroughs, and user guidance. |
| Software licenses | Software or platform costs | Rights to use the products and capabilities needed by the solution. |
| Usage, capacity, and hosting | Operating costs | Resources consumed or reserved to keep the solution running. |
| Support and improvements | Service work and potentially related software costs | Agreed troubleshooting, maintenance, monitoring, or additional development. |
What affects the project scope?
The number of screens or workflows tells only part of the story. A simple-looking form may need complex approval rules, several system connections, or different permissions for each audience.
Scope is shaped by the process, the quality and volume of existing data, the systems involved, exception handling, access requirements, testing, training, and handover. Migrating older records or repairing an existing solution can also require investigation.
Specialist input is included where the work requires it. Solvency Studio coordinates the contribution, responsibilities, and associated costs within the agreed project.
Why discovery can be a separate engagement
Sometimes the desired outcome is clear, but the work needed to achieve it is not. An assessment can examine the process, available access, existing software, and possible approaches before a development scope is agreed.
An assessment should have its own stated deliverables and fee. It should explain what you will receive, such as a process review, options, or a recommended project scope. Do not assume it is free or that its fee will automatically be credited against later work; any such arrangement belongs in the written proposal.
How Microsoft licensing fits in
Power Platform capabilities may be covered through standalone licenses, rights included with other Microsoft products, capacity add-ons, or usage-based arrangements. The appropriate combination depends on the actual solution.
A Microsoft 365 subscription may include some capabilities without covering every proposed application, connection, or automation. Check existing entitlements against the planned use before purchasing anything.
The person building the solution is not necessarily the only person or activity that needs licensing. Review everyone who will use it, how they access it, and any process or capacity options that apply. Connecting through another application does not automatically remove licensing requirements.
Understand what the software charge measures
A license can be tied to a user, a process, capacity, or another defined unit. The meaning depends on the product and plan. Ask what triggers a charge and which assumptions were used to estimate it.
For a portal, review the audience, sign-in model, and visitor usage. For an assistant, review its expected use and the actions or services it calls. For reporting, review how content will be shared and who needs access. For an application or workflow, review users, connections, and the way it runs.
This guide does not quote rates or recommend a particular license. Current product terms and the project design must be checked when the proposal is prepared.
Plan for ongoing operation
A solution may need storage, hosting, integrations, monitoring, or other services after development finishes. Some costs are recurring subscriptions; others vary with activity or capacity.
Ask which services are essential, which are optional, and what could change the bill. Agree who monitors usage, who receives alerts where supported, and who can authorize additional spending. An alert is not automatically a hard spending limit.
Also allow for your organization’s contribution: reviewing requirements, preparing information, testing, and helping people adopt the new process.
An example: a request-management solution
Imagine a team wants a request form, an approval workflow, and a progress report.
Service work could include mapping the approval rules, building the form and workflow, connecting the data, validating the report, and training the team. Software costs depend on the chosen products, users, connections, and storage. Ongoing support could cover agreed monitoring, troubleshooting, and maintenance.
If the team later adds a customer portal, that introduces a new audience, access design, and possible licensing or capacity needs. It is a scope change to review, even if the portal uses the same underlying records.
This is an illustrative cost breakdown, not a quote or a completed client case study.
Compare proposals on the same basis
Check what is included, what is excluded, and which assumptions could change the work. A lower initial fee may cover fewer deliverables or leave more responsibilities with your team.
Look for acceptance criteria, review milestones, data preparation, required integrations, documentation, training, and support terms. Distinguish confirmed charges from estimates that depend on usage or third-party prices.
Review payment milestones, renewal terms, cancellation conditions, and applicable taxes where relevant. These must come from the actual agreement; this guide does not establish payment or contract terms.
Keep changes visible
When requirements change, the effect may reach beyond development time. A new integration could alter licensing, a larger audience could affect capacity, and a new approval stage could need additional testing.
Solvency Studio reviews the impact on scope, cost, and timing, then agrees the update in writing before additional work begins. A phased approach can separate the essential first release from later improvements.
Clarify support and ownership
Software subscriptions and development fees do not automatically include ongoing support from Solvency Studio. Agree coverage, response expectations, maintenance, and the handling of future improvements.
Clarify which work is a correction within agreed acceptance or support terms and which is a new request. Identify who owns or controls the accounts, administrator access, source files, documentation, and business data, and how handover will work.
If an engagement ends, understand which third-party subscriptions continue and who manages them. Ownership and exit arrangements should be documented rather than assumed.
Questions to ask before agreeing the work
What outcome and deliverables does the service fee cover?
Which software costs are already covered by our existing licenses?
What additional licenses or operating services are needed, and who pays each provider?
Which charges are fixed, recurring, or dependent on usage?
What assumptions or changes could affect the estimate?
What do we need to contribute during the project?
What happens after launch, and what support is included?
How will we access our accounts, information, and documentation at handover?
You do not need a finished budget or technical plan to start a conversation. Tell us your priorities and any budget constraints you want considered, and we’ll help define a suitable engagement.