There are two types of entrepreneurs. The first believes they are the owner because they pay for everything: payroll, suppliers, taxes, the "entire team," the tough months, mistakes, repetitive tasks... everything. The second is the true owner: because even if the key person leaves tomorrow, the business will continue.
The difference is not in the money. It is in the control of the asset.
That asset is not the premises. It is not the machinery. It is not the uniform. It is what cannot be seen: the code that generates revenue, the logic that makes decisions, the software that keeps the business running, the recipe that keeps customers coming back, the process that prevents losses, the know-how that turns an ordinary business into one with an advantage.
And when that asset is not tied to the company, all it takes is for the person who created it to leave the payroll—or for the third party hired to disagree—for the blow to strike: via WhatsApp... or by formal notification:
"I did that."
"That's in my name."
"You can't use it."
When you read that, you are not faced with a "legal issue." You are faced with an operational truth: your company was operating... but operating with borrowed assets.
THE REAL CASE OF THE MIXOLOGIST (DOMINICAN REPUBLIC)
A restaurant had a mixologist under an employment contract. The problem was not that "there was no contract." The problem was more common and more dangerous: there was an employment relationship, but the creative function was not detailed in writing, nor was it clearly agreed that the ownership and business use of the recipes, files, and standards created during the relationship belonged to the business.
The business grew. The drinks became an identity. And then what happens in real life happened: either the relationship breaks down, or the competition seduces you.
In either scenario, the blow comes via WhatsApp, email, or formal notification, with a sentence that paralyzes operations:
"The recipes are registered in my name. They are my property. You cannot continue to use them or even mention them on the menu."
Now imagine the real-life scenario: it's Friday, there are reservations, and the manager calls you with a question that isn't legal... it's about survival:
"Should we serve the signature drink or take it off the menu today?"
That's where the gray area comes in. And the gray area costs money, reputation, and sleep. Changing recipes means losing identity. Keeping them means operating at risk. Negotiating means paying ransom.
The lesson is not "let's fight." The lesson is simpler, and that's why almost no one applies it: document creative functions and agree on ownership from day one. Otherwise, you don't have an asset; you have a discussion waiting to happen.
If it is not agreed upon and controlled, it is not possessed.
WHAT THE LAW ACTUALLY PRESUMES (AND WHAT IT DOES NOT PRESUME)
1) Creative works under employment or commission: without an express agreement, you are exposed
Law 65-00 is stricter than most business owners believe: In works created under an employment relationship or on commission, the practical starting point is "what was agreed upon." If you do not leave a clear contractual stipulation regarding ownership/assignment of assets, you may end up arguing later about what should have been settled from the outset.
Straightforward translation: Manuals, documentation, procedures, technical and creative materials... are not "protected" simply by paying a salary. It must be agreed upon.
2) Software: the presumption exists, but the trick is who ended up as the "producer."
In computer programs, the law revolves around the "program producer": the person who takes the initiative and responsibility for the production. In this regime, there are presumptions in favor of the producer.
Now comes the detail that changes everything and that almost no one understands until it happens to them: Producer is not "the one who pays" by definition. Producer is the one who, in practice, directs, organizes, and controls the production.
The punchline to make sure this sticks:
If the repository and critical accounts are not in your company's name, the "actual producer" may, in practice, be someone else.
That's why, in software, you need two simultaneous lines: agreed ownership and designed operational control. If you only do one, you're left limping.
Legal presumption is not operational control.
The law can help argue rights. But it does not magically return the repository, cloud keys, documentation, or version history. Modern hijacking is not done with lawsuits: it is done with credentials.
This does not only apply to external providers. It also applies to internal developments: if the software is built by your own team, you need the same (agreed ownership + designed control), because the risk arises when someone leaves the payroll, takes credentials with them, or the know-how remains concentrated in a single person.
THE MOST COMMON PROBLEM WITH SOFTWARE (AND THE MOST EXPENSIVE): YOU FINANCE IT AND SOMEONE ELSE RESELLS IT
This happens a lot in fintech, logistics, healthcare, construction, and any business that commissions a "proprietary system" to support its operations or build a competitive advantage.
You pay for months of development. You pay for meetings, testing, adjustments, changes. You even pay for mistakes. In practice, you finance the maturation of a product.
And then one day, something happens that no one will ever forget: a client, friend, or employee sends you a link:
"Look, this is very similar to what you guys have..."
You open the demo and it hits you in the gut: the same flows, the same logic, the same user path. They changed the colors, they changed the logo, they changed the name... And they're selling to someone else what your money helped build.
That's a generic brand.
First mistake: believing that paying equals exclusivity
If the software development contract does not specifically prohibit reuse, adaptation, sale, licensing, or exploitation of derivatives for third parties, you paid for your version, not for control of the asset.
Second mistake: focusing only on "ownership" and forgetting "copy control"
If the provider controls the repository and environment, they can create forks, branches, and parallel versions without you noticing. And by the time you do notice, it's already too late.
The solution is to close the gap.
It must be agreed, clearly, enforceably, and unambiguously, that:
- The development financed by you belongs to the company as an asset.
- Exclusivity exists
- White labeling is prohibited (even if the name, logo, or part of the code is changed).
- It is prohibited to create functional equivalents for third parties using the same flows, rules, integrations, or architecture learned in your project.
- The supplier is obligated to deliver, through the Client's corporate repository, all source code, versions, history (commits), documentation, and associated artifacts.
Here is the phrase that separates the owner from the naive:
If you do not prohibit white labeling by contract and do not control the repository, you may be financing the product that will later compete with you.
PATENTS AND INVENTIONS (INCLUDING THE PHARMACEUTICAL INDUSTRY): WHERE STRICT RULES DO EXIST
In the case of patentable inventions, the rules change. Article 8 of Law 20-00 regulates inventions made in compliance with or in the performance of a contract for work/services or employment, and establishes that the right to a patent for such an invention belongs to the contracting party or employer, unless otherwise agreed.
Translation for entrepreneurs: in hard innovation, you can't "improvisationally own" something later. You either govern at the beginning or pay at the end.
KNOW-HOW AND TRADE SECRETS: HERE, THE ONE WHO SHOWS ORDER WINS
For recipes, mixtures, files, internal techniques, and processes, the practical track is usually a trade secret: valuable information because it is not public and because the company takes reasonable measures to keep it under control.
And here's the key phrase, without drama: reasonable measures are not paranoia; they are order.
WHAT AN OWNER SHOULD DO (WITHOUT BECOMING A LAWYER)
- Know-how cannot live in one person's head. It has to live in the company. That means that recipes, files, techniques, and processes must be stored in a corporate location (official folder, internal system, manual with versions), not on a cell phone, not on a personal Drive, not in a notebook that "only he manages."
- Limited access is not mistrust; it's design. Not everyone needs to see everything. The team executes the method; the company controls the entire map. Access is granted by role, not by friendship.
- Disciplined documentation. Each recipe or critical process has its own file, version, and person in charge. If a step is changed, it is updated there. This way, the business continues to produce the same results even if people change... and no one keeps "the truth" in their head.
- Obligation to deliver and update. What is created for the business is delivered to the business and kept up to date as part of the job. It is not a favor, it is not "when I have time."
- Well-drafted confidentiality and non-use agreements. So that know-how is not just talk, but a corporate asset.
- In software, repository, and corporate keys. The repository must be under the company's account, with more than one internal administrator. Cloud accounts, domains, deployment, and databases must be in the company's name. The provider enters as a revocable guest, not as an owner.
- Clear prohibition of white labeling, derivatives, and functional equivalents. If your advantage lies in the logic of the system, this must be expressly and enforceably prohibited: repackaging, reuse, licensing to third parties, derivatives, forks, versions, and exploitation outside the customer's business.
Companies don't go under just because of competition. They go under when they discover too late that their prime tangible and intangible assets were in borrowed hands.
If your business depends on software, recipes, processes, or know-how, the serious work is to turn that into control: agreed upon, documented, and operable even if people change.
For more articles of interest, visit our publications.