If you run your own servers, you have probably installed more plugins and apps than you can count. Most of them are licensed: you get the right to use the software under certain conditions, but the code stays with its author. That is fine for a media server plugin you install and forget about. It becomes a problem when a piece of software sits at the center of how your setup works — a Jellyfin or Emby plugin that matches your library structure, a Nextcloud app that talks to your internal tools, or an integration your business depends on.
This article explains the model behind custom development with exclusive rights: what you receive, what copyright transfer actually means in practice, why there is no license key, how confidentiality is handled, and when paying for exclusivity makes sense. It is written from the perspective of someone who has maintained self-hosted stacks for years, and it is general information, not legal advice.
Licensed product vs exclusive development
A licensed product is something you are allowed to use. The author keeps the copyright, may sell the same product to others, and can change or discontinue it later. You usually get updates, but you do not get to decide where the product goes.
Exclusive development is different. You describe what you need, we build it, and after full payment the economic rights to the code are transferred to you. The project is never resold or reused for anyone else. In practice that means the software is yours alone — not a copy of a product that others also run.
This distinction matters most when the software encodes something specific to you: your data model, your workflows, your naming conventions. If the code is shared with other customers, those specifics tend to get generalized away. If it is yours, they can stay.
Prerequisites
Before you order, have the following ready:
- A clear description of what the software should do, and on which platform (Emby, Jellyfin, Nextcloud, or an integration between your own systems).
- Access to the people who can approve a specification and an estimate.
- A rough idea of your budget in hours, since the service is billed by the hour with a minimum of 20 hours.
- If confidentiality matters to you, a note that you want an NDA — it is signed on request.
You do not need to prepare a technical design. The written specification is part of the process.
Step 1: Describe what you need
Start through the contact form, a ticket, or Telegram. Explain the problem rather than the solution: what your server setup looks like today, what is missing, and what a good result would look like. The more concrete you are about platforms and constraints, the more accurate the estimate will be.
Step 2: Get a written specification and estimate
You receive a written specification with the number of hours, free of charge. Nothing is charged until you agree to it. Read it carefully — this document is the basis for everything that follows, including the scope of the copyright transfer. If something in your setup is not reflected in the specification, say so now, before any hours are purchased.
Step 3: Buy the hours
Once you accept the estimate, you buy the hours on the product page. The minimum is 20 hours; larger projects add hours as agreed in the estimate. Invoices are issued by Stripe and are available in your account.
Step 4: Development with staged reports
During development you receive test builds and a short report at every stage. Hours are consumed in 15-minute steps, so you can see where the time goes. This is the practical advantage of an hourly model for custom work: you are not guessing what happened between kickoff and delivery.
Step 5: Handover
At the end you receive:
- The full source code — the complete project, with build instructions. You can change it yourself or hand it to other developers.
- The rights transfer document — after full payment, the economic rights to the code are transferred to you.
- No license key and no server limit — the app runs on as many of your servers as you like, without contacting a licensing service.
That last point deserves emphasis for self-hosters. There is no activation server to keep alive, no key to rotate when you rebuild a host, and no phone-home check that breaks when your network changes. You deploy it the same way you deploy anything else on your infrastructure.
What copyright transfer means in practice
Copyright has two sides: moral rights and economic rights. In EU and Romanian law, moral rights (for example authorship attribution) generally stay with the author and are not transferable, while economic rights — the right to use, reproduce, modify and distribute the work — can be transferred. The handover document covers that economic side: after full payment, the code is yours to use and change, and we do not sell, publish or reuse it for anyone else.
A few practical consequences:
- You can fork it. If you later want a different developer to extend the app, you can hand over the source and the build instructions. Nothing in the arrangement requires you to come back to us.
- You can keep it private. There is no obligation to publish the code, and no portfolio entry showing it off.
- Open-source components stay under their own licenses. If the project uses third-party libraries, those keep their original terms; the transfer applies to the code written for you. Ask about this during the specification phase if your project relies on specific libraries.
- The transfer follows full payment, which is why the handover step is tied to it.
This is a general description, not legal advice. For your specific situation, especially if you are transferring rights onward to a client or employer, consult a lawyer.
Confidentiality and naming
The project does not appear in our portfolio, and an NDA is signed on request. If the software is part of a commercial service or contains details you would rather not publicize, say so at the start so the NDA is in place before the specification is written.
When exclusivity is worth the price
Exclusivity is not the right choice for every plugin. It is worth considering when:
- The software encodes business logic you do not want shared with competitors.
- You expect to maintain or extend the code for years and want the freedom to choose who does that work.
- You need it on many servers without a licensing dependency.
- You want the option to keep the project entirely private.
It is probably not worth it for a small convenience plugin with no sensitive logic, where a licensed product or ordinary custom development would do the job. The hourly model is the same; what changes is what you receive at the end.
Tips and troubleshooting
- Scope creep is the main risk. Stick to the written specification. If requirements change, agree on additional hours first — larger projects add hours as agreed in the estimate.
- Unused hours do not disappear immediately. They stay in your account for 12 months, which gives you room for follow-up work after the handover.
- After handover, changes are ordinary development hours — either with us or with anyone you choose. That is the point of owning the code.
- Keep the build instructions with the source. Store them together in your own repository so a future maintainer is not left guessing.
- Ask about third-party components early if your compliance rules require knowing which licenses are involved.
- Do not treat the estimate as a fixed price. It is an estimate in hours; the 15-minute accounting is there so you can track consumption.
Conclusion
Licensed software gives you the right to use something. Exclusive development gives you the thing itself: the full source code, the economic rights after full payment, no license key and no server limit, and confidentiality if you need it. For self-hosters, the practical difference shows up years later — when you want to change a behavior, move to a new host, or hand the project to someone else.
If you have a project that needs to be yours alone, start with a description through the contact page and ask for the written specification. You can also browse the knowledge base for related guides or check the FAQ for common questions about how the process works.