Business4s H1 2026 Highlights

Another six months behind us, and the Business4s ecosystem keeps growing — quietly, but steadily, as usual. Two releases of Workflows4s, a brand-new library going from zero to production-shaped in three months, two really interesting experiments and some smaller gems that deserve a closer look. Here’s what happened.

Workflows4s

Workflows4s remains the flagship, and this half brought two significant releases.

v0.5.0 — community-powered polish (March)

v0.5.0 was very much a community release, with six first-time contributors landing changes:

• Stateful retries — retry mechanics that survive restarts.
• Idempotent signals — safe redelivery of signals to workflow instances.
• A static linter — first steps towards catching workflow definition problems before running it.
• Web UI improvements — instance filtering and pagination, routing, auto-refresh after sending a signal, better JSON state display, and Selenium-based end-to-end tests.
• Scaladoc integration — API docs are now built and published alongside the website.

v0.6.0 — effect polymorphism lands (May)

The big one. After months of work, v0.6.0 made Workflows4s effect-polymorphic: workflows are no longer tied to cats-effect IO and can run on ZIO, Future, or even Try. This removes the single biggest adoption blocker for teams outside the Typelevel ecosystem. The full story is in a dedicated post: Workflows4s Goes Effect-Polymorphic.

The release also reworked PostgresWorkflowRegistry into an all-in-one component, exposed instance IDs inside workflow definitions, and allowed attaching descriptions to signals and pure computations for richer diagrams.

Runtimes you wouldn’t expect

Two intriguing ideas landed in the issue tracker: an AWS Step Functions backend and a Temporal backend. Workflows4s was always meant to separate workflow definition from execution, and these would push that idea to its limit — write your workflow once, in plain Scala, and run it on infrastructure you might already use. Both are open questions more than commitments and if you have experience with either platform, chime in on the issues.

ChatOps4s — from idea to real library

ChatOps4s — prototyped during GSoC 2025 — became a real thing this half. The initial release landed in March, together with an introduction post: ChatOps4s — You Might Actually Build That Slack Integration Now.

The pitch: typed Slack integrations for Scala with minimal ceremony — forms generated from case classes, buttons with typed payloads, and automatic tracking of the bot scopes your integration actually needs. Since the first release it has already grown through the 0.2.x line: better tables, customizable outgoing messages, scope tracking in idempotency checks, and stricter validation of registered interactions. All those come from dogfooding in production use.

Decisions4s — decisions you can actually show people

Decisions4s shipped v0.2.0 and v0.2.1 this half, and two of the new features deserve more than a changelog line.

The DMN viewer

The whole point of rendering decision logic as DMN is that you can show it to a non-programmer. Except, until now, “ showing it” meant asking them to install a desktop modeler or uploading the file to some third-party site. That gap is now closed: decisions4s has its own hosted DMN viewer. Drag and drop a .dmn file and see the table. Better yet, decisions4s can generate a share URL that encodes the entire decision table into a link — so "here's the exact rule set this service runs on" becomes a one-liner you can paste into a Slack thread, a PR description, or an message to a business stakeholder. Zero tooling on their end.

The quoted macro

Expressions in decisions4s always had to carry a human-readable rendering, and writing those by hand was pure boilerplate. The new Expr.quoted, contributed by a first-time contributor, uses Scala 3 macros to capture the actual source code of an expression as its rendered form:

import decisions4s.Expr

val expr: Expr[Int] = Expr.quoted(1 + 1) // renders as "1 + 1"val expr: Expr[Int] = quoted(1 + 1) // renders as "1 + 1"

You write plain Scala and the decision table displays it. While this go slightly against the mindset of “higher level visualization” it’s perfectly suited for simple expressions.

v0.2.0 also brought persistence support for evaluation results, a self-contained HTML renderer, and performance improvements.

Experiments

Two projects got real energy this half but didn’t cross the finish line — I simply ran out of time and energy. Both are alive and waiting for me (or someone else!) to give them attention they deserve.

Stack Cost Benchmark

The Stack Cost Benchmark (not public yet) aims to measure the impact of language-level performance on total infrastructure cost for a typical horizontallably-scalable microservice system. The goal is a reproducible, end-to-end benchmark that turns per-pod measurements into a dollar figure, with benchmark subjects like http4s, Tapir+Netty, Spring Boot and many more. The methodology went through a couple of overhauls and early results exist, but it needs another push to become publishable. Spoiler: the difference exists, but some stacks are really surprising (e.g. rust is opposite of fast in this context).

Architecture docs from compiled code

The second experiment tackles a problem every distributed system has: architecture documentation that’s wrong the week after it’s written. The idea is to stop writing it and start extracting it from compiled code. By analyzing TASTy (the same trick domainDocs4s uses for domain vocabulary), the prototype builds a call graph and combines it with integration scanners — doobie, Slick, fs2-grpc, fs2-kafka, Pekko actors/persistence, S3, even Flyway migrations — to trace data lineage: from an API entry point, through the service layers, down to the exact tables, topics, and buckets it reads and writes. The output is rendered as Mermaid diagrams, with an interactive Cytoscape.js viewer in the works, and the longer-term design covers per-service specs aggregated into a cross-service system view.

The lineage prototype works — a dozen scanners and 100+ tests — but the higher layers are design-only, so for now it all sits in a draft PR. No clue yet where it leads, but if “architecture diagrams that can’t lie” sounds appealing, this is probably the most interesting unfinished thing in the ecosystem right now.

Other bits

• Forms4s got v0.2.0, expanding from forms into datatables with a server-side data mode and URL-synced table state, plus an introduction post: Forms4s: Rapid Internal UI Development.
• The Scala Adoption Tracker gained eight new entries — including Trimble SketchUp, Devsisters, Snowflake, Nussknacker, DHL, Magnite, Scala Teams, and Rudder.io — most contributed directly by people from those companies.
• The mentorship program ran another round, and there’s now a testimonials page if you’re wondering whether it’s worth your time.
• All Business4s repos now get CodeRabbit reviews on every PR. With the volume of first-time contributions this half, having an automated first-pass reviewer helped tremendously — both for catching issues early and for giving contributors instant feedback.
• Business4s now openly offers Fintech & Scala consulting, and on a more personal note, I recently published Fintech Engineering Handbook which is not directly linked to Business4s but quite close.

Looking ahead

For the next six months, the rough priorities are:

• Stabilizing the effect-polymorphic core of Workflows4s and continuing Web UI development.
• Getting the Stack Cost Benchmark to publishable results.
• Figuring out whether the architecture-docs experiment deserves to become a real thing.

If any of these projects resonate with you, come talk to us on Discord or open an issue. Contributions of every size are welcome — this half proved again that they really add up.