Most self-hosted setups start with existing apps and stay there for years. Then one day a process shows up that no App Store app covers: a form your team fills in by hand, files that need to be sorted by rules only your organization knows, or a step that has to talk to the ERP, the mail server or an identity provider. That is the point where custom Nextcloud app development becomes a realistic option rather than a luxury.
This guide is written from the perspective of someone who runs servers, for people who run servers. It explains what a custom app can hook into, how to describe a request so it can be estimated, how the 10-hour starting package is scoped, and how ownership works. The service itself is described on the Custom Nextcloud app product page.
What a custom Nextcloud app can hook into
A Nextcloud app is not a separate system bolted onto your instance. It is code that runs inside Nextcloud (PHP plus Vue/TypeScript for the interface, targeting Nextcloud 30 and newer) and therefore sits directly next to your files, users and settings. In practice, a small app can touch four areas.
Files. Apps can act on uploaded files: automatic sorting, tagging or processing. If your workflow is "when a document lands in this folder, do something with it," that is app territory. It is also where you should be precise in your request: which folders, which file types, what should happen, and what should happen when a rule does not match.
Flows and workflows. A custom app can provide a form, register or workflow for your organization: sign-ups, document collection, approvals. This is often the most valuable category for teams, because the alternative is a spreadsheet plus email, and both leak.
Integrations. Apps can integrate with an external system: ERP, e-mail, SMS or identity. The OCS API is the usual way an app exposes its own endpoints or talks to other services, and it is also how you can script against the app later. If the external system has an API, say so in your request; if it does not, say that too, because it changes the estimate.
Admin and UI. Apps can add admin tools: security checks, reports, quotas, file rules. They can also add their own settings page and interface texts, which is why the package includes English and Romanian by default, with other languages on request.
Examples of small custom apps
The product documentation lists four example categories that map well onto a 10-hour start:
- automatic sorting, tagging or processing of uploaded files
- a form, register or workflow for your organization (sign-ups, documents, approvals)
- an integration with an external system (ERP, e-mail, SMS, identity)
- admin tools: security checks, reports, quotas, file rules
Notice that these are all narrow. A good first app does one thing well and has a clear trigger and a clear result. "A register for incoming supplier documents with a status field and an approval step" is estimable. "Improve our document management" is not.
Prerequisites
Before you write the request, collect a few facts. They are the same facts we would ask for anyway, and having them ready shortens the estimate:
- The Nextcloud version you run (the service targets Nextcloud 30 and newer).
- What already exists around the workflow: the apps in use, the external systems involved, and whether they expose an API.
- Who uses the result: a group, a department, the whole instance, or admins only.
- What "done" looks like: the trigger, the action, and the output (a file, a record, a notification, a report).
You do not need a specification document. You need a clear description.
Step by step
- Describe the idea. Use the contact form or Telegram. Say what should happen, on which Nextcloud version, and what you already use around it. Keep it concrete: inputs, trigger, result.
- Get the written estimate. Within 2 business days you receive a short specification, the number of hours and a delivery date. Nothing is charged until you agree. The initial discussion and the estimate are free, so this is the right moment to ask the awkward questions.
- Buy the package. The starting package is 10 hours of development. Larger projects add hours at the same rate. The hours appear in your account.
- Development in stages. For each stage you receive a test build and a short report. Hours are consumed in 15-minute steps, and you can see what is left in your account. This is the part that makes a fixed package workable: you are not guessing where the time went.
- Delivery. You get the final build, an installation guide and, if you want, installation on your server via a remote session.
How the 10-hour package is scoped
Ten hours is enough for a focused app, not for a platform. The estimate tells you which side of that line you are on before you pay anything. If the estimate comes back at more than 10 hours, you buy the estimated number of hours at the same rate; the package is a starting point, not a ceiling.
Two details matter for planning. First, unused hours stay in your account for 12 months and can be used for support or later changes, so a project that finishes early does not waste the remainder. Second, the work is done at source level by the author of the MediaLab Works plugins, with the same quality checks: tests, logging and a settings page. That is also why the estimate is written rather than verbal: the specification, the hours and the date are the contract.
Testing, delivery and updates
Test builds are part of every stage, so plan to test on the Nextcloud version you actually run, not on a different one. Check the trigger cases and, just as important, the cases where nothing should happen. If something is wrong, the 30 days of fixes after delivery cover defects found after delivery at no extra cost. Keep the installation guide you receive; it is the document your successor will need.
Shared app vs exclusive development
By default the app is delivered as a licensed build for your servers only, and general-purpose parts may be reused in other products. That is usually the right trade-off for an internal workflow: you get a working app without paying for rights you do not need. If you need exclusive rights or the source code, say so before the estimate, because it is priced separately. Deciding this later is more expensive than deciding it up front.
Tips and troubleshooting
- Write the request as a sequence. "When X happens, the app should do Y, and if Z, then W." Sequences estimate well; wishes do not.
- Name your Nextcloud version. The target is Nextcloud 30 and newer, and the test build should run on your version.
- Mention the surrounding systems early. An integration with an ERP, e-mail, SMS or identity provider is only estimable if we know what it exposes.
- Do not bundle unrelated wishes. A second workflow is a second estimate, and possibly a second package.
- Keep the reports. The short report per stage plus the installation guide is your handover documentation.
- Use the leftover hours deliberately. They last 12 months and can go toward support or later changes.
If you are unsure whether your idea fits an app at all, check the knowledge base and the FAQ, or just ask. The initial discussion and the estimate are free, and a written estimate that says "this is bigger than you think" is still cheaper than building the wrong thing.
Conclusion
Custom Nextcloud app development makes sense when your workflow is real, narrow and repeated, and when no App Store app covers it. A custom app can hook into files, workflows, the OCS API, external systems and the admin UI, all inside the instance you already run. Describe the trigger and the result, ask for the free written estimate, and let the 10-hour package cover the first stage. Start from the product page and send your description through the contact form.