Subscribe, deploy or commission software: the three models and when each one pays off
Three ways to contract software, three cost curves and three divisions of responsibility. A decision guide by size of organization, with what to ask before signing any contract.
In short
- There are three models, and what separates them is not price: it is who adapts to whom and who answers for the system when it has to change.
- Subscribing to a finished SaaS is the route for a common process that has to be live in days. You pay monthly, inherit years of the vendor's work and adapt your operation to the product. It is the natural model for smaller organizations.
- Deploying and customizing gives you the product with your brand, your data and your rules. The cost is a monthly fee plus a customization charge, billed for each new module the operation asks for. It is the model for mid-sized organizations that already have a process of their own but do not want to maintain a system.
- Commissioning under a perpetual license trades the monthly fee for an upfront investment and ownership of the code. Instead of paying maintenance forever, the organization buys improvement consulting when it decides to evolve, or keeps the system as it is for as long as it serves. It is the model for large organizations whose process is a competitive advantage.
- Integrations, automation, use of artificial intelligence, contractual warranties and responsibility for personal data change in all three. Those five points, not the monthly fee, define the real cost of the choice.
The three models, one sentence each
When an organization decides to solve a process with software, it is not only choosing a tool. It is choosing a contracting model, and that model is what will decide how much it costs to change your mind two years from now.
There are three:
- Subscribe to a finished SaaS. You use a product that already exists, the same for every client, for a monthly fee. Your process adapts to the product.
- Deploy and customize a SaaS. You receive a product that already exists carrying your brand, your data and your rules. The base stays with the vendor; what is yours is configured, and each new module has its own price.
- Commission under a perpetual license. You pay for the development of software built for your operation and gain the right to use it forever. The product adapts to your process, and you decide when it changes.
The question that separates the three is not "which is best". It is a different one, in two parts: how much of your process is the same as everyone else's and how much you want to answer for the system. That is the same root as the decision between building and buying software, looked at here from the contract side.
Model 1: subscribe to a finished SaaS
What it is. An off-the-shelf product sold by subscription, usually per user and per module. The vendor hosts it, updates it, fixes it and evolves it for every client at the same time.
What you gain. A short timeline, low upfront cost and years of maturity you did not have to fund. A good market product has already solved problems your team does not yet know exist.
What you give up. The way you work. The product has its own way of doing things, and it is not going to change for you. When your rule does not fit, it turns into a spreadsheet next to the system, and the spreadsheet is where the process goes back to being manual.
When it pays off. When the process in question is common, when the organization is still small and needs results in weeks, when there is no team to look after any system, and when the cost of being wrong is low because the exit is cancelling the subscription.
In Dynamis Works' own work, Optvor is the example of this model. It is a platform of ours, live in three languages, that takes a proposal through to a signed contract and payment. The base is the same for every client: whoever subscribes is live in days and adapts the process to the product.
Model 2: deploy and customize
What it is. A product born to be installed wearing each client's face. The base is shared and keeps evolving for everyone; the brand, the plans, the wording, the flows and the integrations with the systems the organization already uses come in at deployment.
How you pay. In two parts: a monthly fee, which keeps the product running and brings the improvements made to the base, and a customization charge, billed for each new module the operation asks for. It is an honest model precisely because it separates the two bills: you know what you are paying for what already exists and what you are paying for what is yours alone.
What you gain. The product starts speaking the language of the house without you having to keep a software team. Specific rules fit, because they were designed as configuration rather than as exceptions.
What you give up. The base is not yours. If the vendor changes the direction of the product, you follow. And every new request has a price, which takes discipline to stop the roadmap becoming an endless list.
When it pays off. When the organization is mid-sized: it already has its own process, volume that justifies automation and integrations with management systems that have to work, but does not yet want, or should not, carry the maintenance of a whole system.
In Dynamis Works' own work, Movra is the example of this model. It is a platform of ours, built for communication in vehicle protection associations: each association comes in with its own brand, its own plans and its own rules, integrated with the management systems it already uses. The base evolves for all of them; what belongs to each one comes in at deployment.
Model 3: commission under a perpetual license
What it is. Software designed and built for one specific organization, delivered under a perpetual license: the right to use it forever, with the source code delivered or held in escrow.
How you pay. An investment concentrated in the development and, after that, nothing recurring is required. Instead of a maintenance fee running forever, the organization chooses: it contracts improvement consulting when it decides to evolve — a new module, a new integration, a change of rule — or carries on with the system as it is, code in hand, for as long as it serves.
What you gain. Ownership, predictability and independence. The system changes when you want it to and in the way you need. If the relationship with the vendor ends, the software keeps working and another team can take it over.
What you give up. Time and responsibility. It takes longer to go live, it requires someone inside who can make decisions about the product, and it assumes the organization will look after what is its own, including updating dependencies and keeping the environment secure.
When it pays off. When the organization is large, when that process is part of the competitive advantage, when the number of people using the system would make a subscription grow without end, or when security, audit and data sovereignty requirements do not fit inside a shared product.
In Dynamis Works' own work, the Vértebra transparency portal is the example: we designed and built it, and the software is theirs, under a perpetual license. It is where each of the agency's clients follows budgets, approvals, deliveries and results in real time.
The three side by side
| Subscribe | Deploy and customize | Commission | |
|---|---|---|---|
| Who adapts | You to the product | The product to you, as far as the base allows | The product to you, entirely |
| Time to launch | Days | Weeks | Months |
| Upfront cost | Low | Medium, the deployment | High, the development |
| Recurring cost | Monthly fee, grows with use | Monthly fee plus a charge per new module | None required; improvements on demand |
| Ownership of the code | The vendor's | The vendor's, with your configuration | Yours, source delivered or in escrow |
| Integrations | Whatever the catalogue offers | Designed at deployment | Designed with no catalogue limit |
| Automation | Within the product's rules | Within your operation's rules | Wherever you decide |
| Artificial intelligence | The vendor's, as offered | Pointed at your own content | Model, data and destination chosen by you |
| Warranty | Standard terms and the plan's SLA | Service contract with a fix deadline | Contractual warranty over what was delivered |
| Personal data | Vendor as processor, little room to negotiate | Vendor as processor, contract negotiated | You define hosting, access and retention |
| Typical size | Smaller organizations | Mid-sized organizations | Large organizations |
How to choose, in practice
The choice is rarely made for the whole organization: it is made for each process. The same company subscribes for payroll, deploys for customer service and commissions what sets it apart.
The model is chosen per process and by size, not per company. The highlighted area is where a perpetual license pays off.
What changes in integrations
Integration is where the difference between the three models shows up first, because it is the point at which the software has to talk to what is already in the house.
In a subscribed product, you have the vendor's catalogue. If the integration you need is in it, good. If it is not, what is left is exporting a spreadsheet and importing it on the other side, which is manual work dressed up as a process.
In a deployed SaaS, integrations come in at deployment and become part of the product: the management system the organization already uses, the CRM, the payment gateway, the messaging service. Data stops being typed twice.
In commissioned software there is no catalogue: there is whatever needs to exist. This is also where integrations fit that no product would ever build, because only your operation has that particular pair of systems.
In all three, the real gain is not the isolated connection: it is the chain. The enquiry that arrives through the site reaches the management system, the accepted proposal becomes a contract, the contract becomes billing, and everything shows up on the dashboard without being retyped. That is what holds up an integrated revenue operation.
What changes in automation
Automation is the step after integration: once data is moving, it starts triggering things on its own.
In a subscribed product you automate within its rules, and they are usually enough for the common cases: a payment reminder, a stage that changes, an email that goes out. In a deployed SaaS, automation follows your operation's rules, because those rules were configured. In commissioned software, the automation is the system itself.
The criterion for deciding what to automate is the same in all three, and it bears repeating: automate what is repetitive, has a clear rule and happens many times. Anything that depends on judgement, context or exception should stay human, with the system handing over the information ready for the decision. That is the difference between intelligent automation and blind automation.
Where artificial intelligence fits
AI changed the cost of building software, but it did not change the question in this article. What it changed is the ceiling on freedom in each model.
In a subscribed product, you use the AI the vendor built in, trained by them, with data passing wherever they decided. For generic tasks, such as summarizing a text or suggesting a reply, that is usually enough.
In a deployed SaaS, you can point the AI at the organization's own content: written procedures, support history, the product catalogue. The model is still the vendor's, but what it reads is yours, and the answers start sounding like the house.
In commissioned software you choose everything: which model, what goes into the prompt, where the data travels, whether it may be used for training and what happens when the AI gets it wrong. For sensitive data, that is the only setup in which you can answer an auditor precisely.
The warning we made in why AI projects fail still holds: in none of the three models does AI fix a process that does not exist. It speeds up what is already designed and amplifies what is wrong.
Warranties: what to require before signing
Warranties are the part nobody reads and the part that decides what happens on the worst day. The three models have different instruments, and in all of them what counts is what is written down.
- Time to fix. How long the vendor has to fix a defect, split by severity. Without that split, everything becomes "normal priority".
- Availability. What percentage is committed, how it is measured and what happens if it is not met.
- Fixes at no cost. What counts as a defect, covered by the warranty, and what counts as an improvement, billed separately. That boundary has to be defined beforehand, not afterwards.
- Source code. In the commissioned model, whether it is delivered on completion or held in escrow, and under what conditions it is released.
- Who looks after it afterwards. Under a perpetual license, who answers for dependency updates and security incidents from delivery onwards: you, a team of yours, or us, under an improvement contract. One line in the contract removes the doubt on the worst day.
- Portability. How you get your data out, in what format and how quickly, including if the relationship ends badly.
- Continuity. What happens if the vendor shuts down. It is the most uncomfortable question in the meeting and the most important one.
Personal data: who answers in each model
Brazil's General Data Protection Law (Law 13,709/2018) defines, in article 5, two roles that organize the conversation: the controller, who makes the decisions about processing, and the processor, who carries out the processing on the controller's behalf. The GDPR uses the same pair of roles, under the same names.
In the usual setup of all three models, the contracting organization is the controller, because it decides why and how people's data is processed. The vendor that hosts and processes it acts as the processor. What changes from one model to the next is not that division: it is how much room you have to negotiate it.
- In a subscribed product, the contract is take it or leave it. You accept the vendor's policy on where the data sits, who has access and for how long. Your real decision is choosing a vendor whose policy you accept.
- In a deployed SaaS, the contract is negotiated. You can set the hosting region, retention periods, access rules for the vendor's team and what happens to the data when the relationship ends.
- In commissioned software, those decisions are yours from the design onwards: where it runs, who gets in, what is logged, how long it is kept and how it is erased.
In all three, three obligations do not move: informing people clearly, answering data subject requests within the deadline and reporting incidents. They belong to the controller, and no contract transfers them.
The decision, step by step
- SeparateWhich processes are common and which set the business apart
- MeasureHow many people will use it and how many years the system will exist
- TestMarket products against your hard cases, not against the demo
- Add upTotal cost over the period, including integrations and the manual work left over
- NegotiateWarranties, portability and the data contract before signing
- DecidePer process: subscribe, deploy and customize, or commission
The order matters: negotiating warranties and portability after signing means the negotiation is already lost.
- Separate your processes into common and differentiating, talking to the people who run them every day.
- Measure how many people will use the system and how long it needs to exist. Those two numbers are what move the crossover point between a monthly fee and a perpetual license.
- Test market products against your hardest cases. A sales demo solves the easy case by definition.
- Add up the total cost over the period: subscriptions, customizations, integrations and the manual work left over on one side; development, environment and improvements on the other.
- Negotiate warranties, portability and the data processing contract while you can still say no.
- Decide process by process. The right answer almost always mixes all three models.
What Dynamis Works does in each one
We work in all three, and in two of them with a product of our own: Optvor, subscribed to by companies in several countries, and Movra, deployed in vehicle protection associations. We say that at the start of the conversation instead of claiming neutrality. Recommending well means knowing all three models and saying so when your case does not go through us.
When the route is to subscribe, the work is choosing well and connecting: integrating the systems the organization already uses, automating what is repetitive and building a dashboard that shows the whole operation rather than each tool separately.
When the route is to deploy and customize, the work is the deployment itself: brand, rules, integrations with management systems, training the people and the new modules the operation asks for over time.
When the route is to commission, the work runs from design to operation: architecture, development, security, applying artificial intelligence where it solves something, and delivering the code under a perpetual license.
In all three, the part that decides the outcome most is not technical: it is adoption. A system nobody uses is a cost, not an asset.
Frequently asked questions
What is the difference between subscribing to a SaaS and commissioning software under a perpetual license?
With a subscription, you pay for the right to use a product that remains the vendor's, and the vendor evolves it for every client at once. Stop paying and you lose access. With a perpetual license, you pay once for the development and gain the right to use that software forever, with the source code delivered or held in escrow. The product only changes when you decide, and future work is contracted separately.
What does it mean to deploy and customize a SaaS?
It means contracting a product that already exists and was built to take on each client's identity, rules and integrations. The base is shared and keeps evolving for everyone; what is yours — brand, plans, wording, flows and connections to your systems — is configured during deployment. Each new module your operation asks for comes in as a customization, with its own price, on top of the monthly fee.
Is a perpetual license cheaper than a subscription?
It depends on the timeframe and the size of the organization. A perpetual license concentrates spending at the start and charges little afterwards, only when improvements are contracted. A subscription starts cheap and grows with users, modules and price rises. There is a crossover point, and it usually appears when the number of people using the system is high or when the product is central to the business. The honest comparison is total cost across the period the system will exist, not the first invoice.
Who answers for personal data in each model?
In all three models as they are usually set up, the contracting organization is the controller, because it decides why and how the data is processed; the vendor that hosts and processes it is the processor. Brazil's data protection law, the LGPD, defines those roles in article 5 and liability in chapter VI. What changes between the models is the contract: where the data sits, who has access, for how long, and what happens to it when the relationship ends.
Can you start with one model and move to another later?
You can, and it is the most common path. Plenty of organizations subscribe to a finished product to validate the process, move to a deployed SaaS when their own rules start to weigh, and only commission software under a perpetual license once that process has become a competitive advantage. What makes the move expensive is not the model, it is the lack of portability: from the very first contract, require that your data can be exported in an open format.
Where does artificial intelligence fit into this decision?
Into all three, but with different freedom. In a subscribed product you use the AI the vendor offers, the way the vendor offers it. In a deployed SaaS you can point the AI at your own content, such as written procedures and support history. In commissioned software you choose the model, what goes into the prompt, where the data travels and whether it may be used for training. The more sensitive the data, the more that freedom matters.
From reading to practice
We work in all three models, and we tell you which one is yours.
Dynamis Works integrates systems, automates processes, applies artificial intelligence where it solves something, and builds platforms, for a whole sector or for you alone. We run platforms of our own in two of the three models, and we say so before any recommendation: the conversation starts with your process and your size, and ends at the model that serves you, even when that model does not go through us. If this decision is on your desk, let's talk.
Talk to Dynamis Works
