Build Service

OJS Development Services

OJS development covers custom work on Open Journal Systems core behavior, themes, and plugins — building features that OJS does not include out of the box, adapting editorial workflows to a journal's actual process, and integrating third-party tools through the plugin system, without breaking compatibility with future OJS updates.

OJS 3.5.0-5 LTS OJS 3.4.0-10 OJS 3.3.0-22 LTS Verified 2026-07-23

Who This Is For

  • Journals whose editorial workflow doesn't match OJS's default submission or review steps
  • Publishers who need a feature OJS doesn't provide out of the box
  • Teams migrating custom functionality from a legacy platform into OJS
  • Journals that outgrew a previous theme or plugin and need it rebuilt properly

Common Problems This Solves

  • Editorial steps that have to be worked around manually because OJS doesn't support them natively
  • A theme or plugin that breaks every time OJS is updated
  • Missing functionality that currently requires an external spreadsheet or email process
  • A previous developer's customization that was never documented and is now hard to maintain

What's Included

Written technical scope before any code is written
Development on a staging copy of the journal, never directly on production
Custom plugin or core-hook-based implementation (not editing OJS core files directly, where avoidable)
Cross-browser and mobile responsiveness testing for any front-end work
Basic documentation of what was built and how to maintain it
A defined handover point with source files delivered

How the Process Works

Discovery call

We discuss the editorial problem or feature request in plain terms — not just the technical symptom.

Written scope & estimate

You receive a document listing deliverables, assumptions, exclusions, and an estimate before any billable work starts.

Staging build

Development happens on a staging copy of your OJS installation, isolated from live editorial activity.

Review & revisions

You test the build against real editorial scenarios before it goes anywhere near production.

Deployment & handover

We deploy to production during a low-activity window and hand over documentation and source files.

Access & Requirements

  • Admin access to the OJS installation (or a staging copy)
  • FTP/SSH or hosting-panel access for the environment being modified
  • A recent full backup before any development branch is deployed to production
  • Read access to any existing custom plugin source code, if applicable

Realistic Benefits

  • Features built to match how your editorial team actually works
  • Code structured to survive OJS core updates rather than being overwritten by them
  • A documented, maintainable outcome instead of an undocumented one-off hack

Limitations & Exclusions

  • Complex custom workflows may require phased delivery rather than a single release
  • Some requests are better solved by reconfiguring existing OJS settings than by custom code — we'll say so if that's the case
  • Deep core modifications (where unavoidable) may need re-review after a major OJS version upgrade

Related Integrations

Documented, Not Improvised

Every engagement follows a written scope, a staging environment before production changes, and a validation checklist before anything is marked complete. Project write-ups are published as case studies once a client approves sharing them.

View case studies

Pricing for this service

Development work is scoped and quoted per feature or project, based on complexity and the current state of your installation — not a flat rate.

View Pricing Guidance

Frequently Asked Questions

We avoid it wherever possible. Custom functionality is built as plugins or through documented hook points so it survives OJS core updates. Direct core edits are only used as a last resort, and we'll tell you plainly if that's the only option for a specific request.

No — every quote follows a look at your actual installation and OJS version. Development scoped without that context tends to be inaccurate.

Plugin-based development generally survives minor and patch upgrades. Major version upgrades (e.g. 3.3 to 3.5) can still require compatibility review, which we scope separately as part of our OJS Upgrade service.

Yes, provided we can review the existing source code first. We'll tell you honestly if it needs to be rebuilt rather than extended.

It depends entirely on scope — a small workflow tweak may take days, while a custom plugin integrating a third-party system can take several weeks. You'll get a timeline as part of the written scope.

Yes. You receive the source files and basic documentation describing what was built and how to maintain it.

Written by the CyberDairy OJS Engineering Team

Technically reviewed by: Senior OJS Developer

Last updated 2026-07-23

Build Service

Ready to talk about OJS Development?

Tell us about your journal and current setup — we'll respond with a scoped recommendation.

Contact Us Request a Quote