Live · Open source · openorderproject.org
About ten form entries in, and out comes a print-ready bulletin and a worship deck of seventy to eighty-six slides — every hymn verse, the creed, the prayers, the scripture text, themed backgrounds, the lot. It has run every week since March 2026.
Several hours a week, every week
A pastor or a volunteer opens PowerPoint on Thursday and starts copying hymn verses out of a purchased hymnal disc, one slide at a time, formatting each one to match last week. Then they build the bulletin in Word from a template that has drifted. It takes hours, it happens every single week, and it is the least valuable use of that person’s time in the entire building.
OpenOrder takes the week’s hymn numbers, scripture reference, sermon title, and service details, and emits both documents. The pastor checks them and prints.
The generation itself is instantaneous — you press the button and the download is already there. That is worth stating carefully, because the honest measure of this tool is not its compute time: it is that the only remaining cost is deciding what goes in the service. Which is the part that should take a pastor’s time, and the only part that ever should have.

The entry side: hymn numbers resolve to titles with their hymnal source, and the sermon details go in once.
Copyrighted content in a format nothing can read
Licensed hymnal slides ship on disc in the legacy binary PowerPoint format. No modern Python library reads it — the format predates every tool that would help. And the lyrics themselves are copyrighted, so they cannot live in a public repository even if I could parse them.
A PowerShell script COM-automates the actual PowerPoint application to batch-convert the entire disc to the modern format. Then a 347-line extractor pulls lyrics out — and it discriminates by shape geometry rather than by content, because the content is inconsistent but the layout is not: title slides identified by shape position, offscreen shapes with negative offsets dropped, copyright lines separated out as metadata, vertical-tab characters normalized.
The extracted lyrics stay on the user’s machine and never enter the repository. The tool ships; the copyrighted content does not.
Where the 7,000 lines went
The slide generator is 931 lines of direct python-pptx work — every slide starts blank and every shape is positioned by hand, because worship slides have real typographic requirements and no template engine survives contact with them. It handles hymn and liturgy continuation slides, scripture across multiple slides, source badges, title pills, and drop shadows written as raw shape XML because the library does not expose them.
Scripture comes from an open API with a local disk cache. The whole thing is packaged as a standalone Windows executable so a church volunteer double-clicks one file — no Python, no terminal, no install instructions longer than a sentence.

The output side, straight out of the generator — themed section breaks, every hymn verse on its own slide with the hymnal number badged, the creed broken across slides at sensible stopping points. The status bar reads slide 2 of 71.
The gap I would close first
There are no tests. In seven thousand lines whose entire job is deterministic document generation, that is the wrong answer — it is the cheapest code in the world to test and the most expensive to silently regress. It is the first thing I would fix before pointing anyone at the repository.
On speed: I have not run a formal benchmark with a stopwatch, so there is no millisecond figure here. What I can report is months of weekly operation — the file is simply there when the button is released. I would rather describe what the tool does than publish a number I did not measure.