If you run your own server long enough, you eventually hit the same wall: the plugin or app does almost everything you need, except that one thing. Maybe it's an integration with a service you already use, a small script around your media library, or a scheduled task that keeps your mailcow setup tidy. You can live with the workaround, or you can turn the request into paid work — done openly, with a written estimate before anything is charged.
This tutorial walks through that process for custom software development on our Emby and Jellyfin plugins, Nextcloud apps and mailcow tools. It is written for people who administer their own hardware and want to know exactly what they are buying, how hours are consumed, and what happens to the code afterward.
One scope note up front: this is for features, integrations, scripts and scheduled tasks around existing products. If you need a completely new plugin, that is a different package — see the custom plugin pages for Emby, Jellyfin and Nextcloud. Everything below assumes a legal, self-hosted setup with media you own or are licensed to use.
Prerequisites
Before you start, make sure you have:
- A running instance of the relevant product (an Emby or Jellyfin plugin, a Nextcloud app or a mailcow tool) and a rough idea of its current version, so we can talk about the right codebase.
- A clear description of the gap: what you do today, what you want instead, and why.
- A way to reach us — the contact form, a ticket or Telegram.
- An account on our site, because purchased hours appear there and you track what is left from the same place.
You do not need a formal specification to start. A written estimate is free of charge, and nothing is charged until you agree to it.
Step 1: Decide whether this is a feature request or custom development
Not every wish needs a paid engagement. Ask yourself whether the change is something the product should plausibly do for everyone, or something specific to your setup. A general improvement is often worth simply reporting. A request that only makes sense for your infrastructure — an integration with a service you use, a script or a scheduled task around your server — is a good fit for development hours.
If you are unsure, describe it and ask. The first discussion on Telegram or by e-mail is there to sort this out before anyone spends time on an estimate.
Step 2: Describe the need as a user story with examples
The quality of the estimate depends on the quality of the description. Write it the way you would explain it to a colleague:
- Who and when: "As an admin, I want the plugin to do X after Y, so that Z."
- Concrete examples: one or two real cases from your server, including what the input looks like and what you expect to see afterward.
- Acceptance: how you will judge that it works. "When I run it on my library, I expect the result to appear in the plugin's existing view" is far more useful than "make it better."
- Constraints: anything the change must not break, and any service it has to talk to.
Keep it short. A few paragraphs plus examples is usually enough for a written estimate. Screenshots or log excerpts help if the behavior is hard to describe in words.
Step 3: Get a written estimate — free of charge
Send your description through the contact form, a ticket or Telegram. You receive a short specification with the number of hours it should take. This estimate is free, and nothing is charged until you agree to it.
Read the estimate as a scope document, not just a number. If something in it does not match what you meant, say so now — adjusting the specification before work starts is much cheaper than adjusting it afterward. If the estimate looks larger than you expected, ask which part drives the hours; sometimes trimming one requirement brings the whole thing into range.
Step 4: Buy the hours and watch them being used
When you accept the estimate, buy the development hours on the custom development page. The minimum is 2 hours, and the hours appear in your account.
From there, the process is deliberately boring:
- Hours are consumed in 15-minute steps.
- Each task comes with a short report, so you can see what was done.
- Your account shows what is left, so you always know where you stand.
That combination is what makes this workable for a self-hoster: no open-ended retainer, no invoice surprises. If a task turns out to be smaller than expected, you keep the remainder. If it turns out to be bigger, you will see it in the reports before the balance runs out.
A practical tip: batch related requests into one engagement rather than buying two hours every few months. Related changes often share setup and testing effort, and the reports are easier to follow when they belong to one thread.
Step 5: Delivery, testing and updates
Delivery happens in one of two forms:
- as an update of the plugin or app, or
- as a build made only for you.
Which one you get depends on the nature of the change, and the estimate should make it clear. Either way, test on your own server before rolling it out widely — especially if the change touches scheduled tasks or anything that runs unattended.
This is also where the license matters. Changes built into our products are maintained with them in later versions, so you are not left maintaining a fork. A build made only for you is exactly that: specific to your instance, and worth keeping track of in your own notes when you upgrade the surrounding software.
Step 6: Know who owns what
Ownership is the question self-hosters ask most often, and it deserves a straight answer before work begins:
- Shared improvements: when a change is built into our products, it flows back into the shared product and is maintained with it in later versions. Other users benefit, and so do you, because you are not carrying a private patch.
- Exclusive builds: when the result is a build made only for you, it stays with you rather than becoming part of the standard product.
If it matters to you which path is taken, raise it while discussing the estimate. It is much easier to agree on that up front than to renegotiate after delivery.
Tips and troubleshooting
The estimate came back higher than I hoped. Ask which requirements account for the hours and whether a smaller first version would cover your main case. A narrower scope delivered now often beats a broad scope delivered later.
I do not know exactly what I want yet. Start the conversation anyway. The initial discussion exists precisely to turn a vague wish into something estimable, and the estimate itself is free.
Work paused and I have hours left. Unused hours stay in your account for 12 months, and they can also be used for support sessions. You are not forced to spend them immediately.
I need help rather than a new feature. That is a valid use of the same balance — support sessions draw on the same hours.
Where are my invoices? Invoices are issued by Stripe and are available in your account.
I am not sure this is the right product. If you need a whole new plugin rather than a feature, use the custom plugin packages linked above. For general questions, the knowledge base and the FAQ are the fastest places to look.
Conclusion
Turning a feature request into paid work should not feel like a leap of faith. With a free written estimate, hours consumed in 15-minute steps with a report per task, a visible balance, and a clear rule for whether a change flows back into the shared product or stays a build made only for you, you can decide with open eyes. Start with a description of your need on the contact page, and read the full service details on the custom development page.