No. BL-CUS · Custom development
The plugin your operation actually needs.
Redmine does 80% of the job out of the box. The remaining 20% is your process — and no off-the-shelf plugin knows it. I write that part. Not as an agency that learns your shop from a briefing document: I am a manufacturing engineer with more than 18 years in the metalworking industry, and every plugin I sell started as a problem I had to solve on the floor first.
Scope
What I build
Everything below lives inside Redmine as a plugin. No Redmine core files are edited, so your instance still upgrades like a stock Redmine, and nothing you already run has to be thrown away.
A plugin from scratch
Your process turned into screens, permissions, workflows and reports — built on the issues, projects and users you already have, not on a parallel database nobody maintains.
Adapting an existing plugin
A plugin that is 70% right is worth fixing, not replacing. I extend the one you already use so it matches how your team actually works, and hand back a fork you own.
Integration with your other systems
ERP, CAD file servers, in-house databases, shop-floor terminals. Data flows into the issue instead of being retyped, and the plugin degrades quietly when the other side is down.
Reports and indicators Redmine lacks
On-time delivery, lead time, load plan, cost per branch of the task tree, department deadlines. Numbers that come from the real issues, refreshed without anyone exporting anything by hand.
Workflow automation
Approvals, automatic task trees, scored queues, notifications that fire on the event instead of a daily digest nobody reads. Fewer meetings about who is supposed to do what next.
Migration and plugin recovery
Moving to a new Redmine version, rescuing an abandoned plugin, or merging two instances. Includes a written compatibility matrix so you know exactly what runs where.
Dated offer
Redmine 7.0 Plugin Rescue
Redmine 7.0.0 shipped on 30 June 2026 on Rails 8 and Ruby 4.0. It broke plugins in bulk. Right now a lot of companies are frozen on an old Redmine for one reason: a plugin they depend on will not boot on 7.0, and the person who wrote it is gone.
That is a solvable problem, and it is the same work I am doing on my own seven plugins this quarter — the port is in progress here too, and I will not pretend otherwise. If you send me the plugin, I will tell you honestly whether it is worth porting or worth replacing — before any work starts.
1 · Assessment
I read the plugin and report what breaks on Rails 8 and Ruby 4.0: removed APIs, dead gems, edited core files, database migrations that no longer apply. You get the verdict in writing, with an estimate.
2 · Port to 7.0
The plugin is brought up on Redmine 7.0 with its behaviour preserved. Where the old code edited Redmine core files, it is rewritten to use the supported hooks instead — that is what makes the next upgrade cheap.
3 · Source code delivered
You receive the full Ruby source, readable, in your repository. Redmine plugins are derivative works, so GPL v2 is not a favour I am doing you — it is the law, and I write code that assumes you will read it.
4 · Compatibility matrix
A short table stating which Redmine versions the plugin is tested on, what is in production and what is still in progress. No vague badges, no "should work".
Honest about my own shelf. My plugins get the same treatment I sell: compatibility being validated. First target matrix: Redmine 6.1.3 and 7.0.0. Nothing here is advertised as already certified on 7.0 — the port is under way, and the matrix is published when it is measured, not before.
No hostages. The deliverable is source code under GPL v2 in your hands. If you later want to maintain it yourself, or hand it to someone else, nothing in the licence or in the code stops you. That is the point.
Process
How it works
Four steps, no discovery phase that bills for months. The goal is to have something running on your instance early, so the scope is corrected by what you see working, not by what a document promised.
1 · A 30-minute conversation
You describe the real process — including the spreadsheet on someone's desktop and the step everyone skips. I ask engineering questions, because I have run the same problem. Free, and it often ends with "you don't need a plugin for that".
2 · Written scope
A short document listing what is in and, just as important, what is out. Fixed deliverables, a schedule, and the acceptance criteria for each one. Nothing starts before you agree with it.
3 · Development in slices
Partial deliveries you can click through on a test instance. You see the screens while they are still cheap to change, instead of meeting the software for the first time at the end.
4 · Install and follow-up
Installation on your own instance, migration of the data you already have, and a follow-up period to fix what only real use reveals. Install steps are documented so your admin can repeat them.
Source included, always. Every line goes to you under GPL v2: readable Ruby, real names, comments in the tricky parts. No obfuscation, no encrypted blobs, no proprietary module you have to keep renting. You are hiring the work, not a padlock.
Track record
Why me
There is a difference between a developer who is told about the problem and one who has lived it. I spent more than 18 years in manufacturing engineering at metalworking companies in Brazil: engineering requests that stall in a queue nobody scores, drawings that cannot be opened by the people who need to approve them, hours that never get logged, production status that exists only in someone's head. Every plugin I wrote came from one of those days.
Seven of them are built and running, not slideware. A CAD 2D/3D viewer that opens STEP, IGES, BREP, STL, OBJ, PLY, glTF and DXF — eight formats — inside the issue itself, with no CAD licence and nothing to install: OpenCascade compiled to WebAssembly and run in a Web Worker, so the page never freezes, tested with a 62 MB IGES of 1.6 million triangles across 357 parts. In a survey of the 868 plugins listed in the official directory (August 2026), I found no CAD viewer there — free or paid. A time-punch widget with a live timer and a factory calendar. A bridge that folds every event into one notification bell. An engineering-code registry with revisions and part-to-part links. A prioritisation engine and a production control plugin, both written for one company's process and sold as paid products adapted to yours. And, finished in August 2026, a health and safety (SESMT) plugin: 6 tables, 16 screens, 5 export routes, 11 fail-closed permissions, and 11 test suites with 576 green checks, verified over external HTTP on a live instance rather than only in the test runner.
Three more are in development: meeting minutes with fully local AI transcription that posts the participants' hours, plus a quality management plugin and a human resources one — both sized to replace the paid commercial software companies currently rent for ISO 9001 non-conformities, audits and deadline tracking, and for personnel administration. That is the bench your project would be built on.
Practically, that means the specification meeting is short. You do not have to explain what a revision is, why a fabrication drawing has a cutting file attached, or why the shop cares about the load plan eight weeks out. We spend the time on your specifics instead — and the plugins that came out of it have been in production at an industrial plant for over a year, serving thousands of issues and attachments, without a single Redmine core file edited.
Contact
Describe the problem, not the solution.
Tell me what breaks in your process today, which Redmine version you are on, and how many people it hurts. I answer with an honest read — sometimes that it is a configuration, not a plugin — and, when there is work to do, a scope and a quote. First conversation costs nothing.