In his the Business4s – Bridging the Gap Between Devs and The Business By Any Means Necessary by Wojciech Pituła tackled one of the most persistent and expensive problems in software development: developers and business stakeholders often work toward the same goal, but speak different languages.
His opening summary was brutally simple:
- Carl is a developer.
- Christine is a stakeholder.
- Carl and Christine don’t talk to each other.
- Carl and Christine build a bad product.
That, in essence, was the whole problem statement.
But instead of stopping at diagnosis, Wojciech presented Business4s: a set of Scala libraries, ideas, and community efforts designed to make business logic more visible, discussable, and aligned between technical and non-technical people.
A comprehensive overview: Business4s -Bridging the Gap Between Devs and The Business By Any Means Necessary
The Real Cost of the Gap
Wojciech grounded the talk in real examples from fintech.
Example 1: Fees and thresholds
A treasury team had to maintain thousands of financial configuration parameters across crypto assets. Developers had built the system so values were managed in each asset’s native currency. But the business never thought in native currencies — they thought in fiat equivalents.
That mismatch meant the treasury team had to maintain a spreadsheet-based workaround to calculate values before entering them into the system.
The result:
- wasted manual effort
- duplicated tooling outside the platform
- avoidable friction
A small change in how the system modeled the problem could have saved significant business effort.
Example 2: Accounting terminology
In another system, developers had invented their own terminology for accounting movements — using “from” and “to” instead of the actual accounting terms “credit” and “debit.”
That meant finance stakeholders had to mentally translate during every design discussion. The software technically worked, but the language itself created friction.
The lesson from both examples was clear:
Developers need to understand the business deeply enough to model the problem in the business’s own terms.
Why This Keeps Happening
Wojciech argued that developers naturally focus on technical concerns:
- compilers
- effect systems
- error handling
- testing
- architecture
- scalability
- performance
- syntax
- tooling
These things matter, but mostly indirectly to the business.
Business stakeholders rarely ask for “better error handling” or “nicer type-level abstractions.” They ask for:
- faster delivery
- lower cost
- fewer mistakes
- systems that solve the right problem
And when developers don’t understand how technical choices map to business value, they risk building beautiful systems that solve the wrong thing.
The Business4s Idea
Business4s is Wojciech’s answer to that mismatch.
It is:
- an ecosystem of business-oriented Scala tools
- a community
- a kind of counterweight to the technical obsession often found in language communities
Its goal is not to make software less technical.
It is to make business meaning more visible in the software development process.
His larger ambition is even more interesting:
He wants Scala to be seen as a functional language for boring software.
Not boring in the sense of unimportant — but boring in the sense of real-world, practical, operational, business-critical systems.
The Core Problem: Different Languages, Different Views
Wojciech broke the dev/business gap into three causes:
Different language
Developers speak in terms like:
- commits
- pull requests
- high availability
Business people speak in terms from:
- finance
- support
- operations
- compliance
- product
The same system is described through entirely different vocabularies.
Different visibility
A support agent sees user pain.
An accountant sees regulators.
A developer sees code and infrastructure.
Everyone sees only part of the picture.
Different concerns
Developers care about correctness, maintainability, and reliability.
The business cares about compliance, customers, operations, and growth.
The challenge is not that one side is wrong.
It is that both sides need shared artifacts to reason together.
The Business4s Toolset
Wojciech presented several projects under the Business4s umbrella, each aimed at making business logic easier to discuss and understand.
Workflows4s
A Scala library for building long-running, persistent workflows.
Think:
- multi-step processes
- approvals
- time-spanning business actions
- replacements for tools like Temporal, Step Functions, or Camunda
What makes it special is that it can generate:
- Mermaid diagrams
- BPMN diagrams
- runtime introspection views
- web UIs for inspecting workflow execution
This means business stakeholders can see and discuss the same workflow structure that developers implement — without maintaining a separate visual model that drifts from the code.
It also supports drafting, allowing teams to sketch workflow logic before it is fully implemented.
Decisions4s
A library for expressing business rules and conditional logic declaratively.
Instead of burying decision-making inside nested if statements, it lets you model rules so they can be rendered as decision tables (in DMN-like style).
That makes rules:
- visible
- diagnosable
- easier to discuss with non-technical stakeholders
Wojciech highlighted this as the best starting point because it gives a lot of value with a relatively small footprint in a codebase.
Forms4s
A tool for rapidly generating back-office forms from Scala code.
The motivation is simple: many businesses rely on internal tools, and developers often underestimate how much value simple admin UIs can provide.
ChatOps4s
A library for bringing business operations directly into Slack-style workflows.
Instead of forcing people to go to a separate system for routine operational tasks — approvals, checks, quick actions — bring those interactions into the communication tool they already use.
This is especially useful for:
- maker-checker flows
- approval chains
- operational notifications
Domains4s
An experimental project inspired by parts of Domain-Driven Design.
Wojciech was clear that he has a mixed view of DDD. He values:
- ubiquitous language
- bounded contexts
But is skeptical of much of the rest.
Domains4s aims to generate high-level documentation — such as glossaries — directly from code, helping align software with the domain language used by the business.
Beyond Code: A Style of Thinking
Wojciech also shared a few principles behind Business4s.
Put business meaning at the front
In code, what appears at the beginning of a line gets read first. That means developers should try to put domain-relevant logic front and center, instead of leading with wrappers or technical plumbing.
Organize by domain, not by technical category
A codebase should be structured around business concepts first, not around technical layers alone.
That makes systems easier to reason about in the same way the business reasons about them.
Why Not Just Let the Business Build It?
An obvious question is: if the problem is understanding the business, why not use no-code or low-code tools and let the business model things directly?
Wojciech’s answer was nuanced.
Business people usually lack:
- the right tooling
- the engineering expertise
- the time
- often even the desire
They want systems that support their work, not a second career as software engineers.
So the answer is not to eliminate developers.
It is to give developers better tools for expressing business meaning.
What About AI?
Wojciech also addressed the current AI wave.
Couldn’t AI just generate these things on demand?
His answer was: yes, AI can help — but it performs best in constrained, structured environments. Typed models, explicit workflows, and clear decision abstractions actually make AI more effective, not less relevant.
So Business4s-style tools may become even more useful in an AI-assisted future.
“Boring” Software Is Valuable
One of the strongest takeaways from the talk was the defense of boring software.
Functional programming communities often gravitate toward:
- novelty
- cleverness
- academic elegance
But most of the world runs on:
- operational systems
- financial processes
- approvals
- forms
- ledgers
- back offices
These things are not glamorous.
But they are where the business value is.
And Scala, in Wojciech’s view, is well positioned to become the language for building that kind of software well.
Final Takeaway
The core message of the talk was simple and important:
Step back and remember why you are building what you are building.
Technical excellence matters — but only in service of solving real problems.
If developers and business people cannot understand each other, even excellent engineering can produce the wrong result.
Business4s is one attempt to close that gap by turning business logic into artifacts that both sides can see, discuss, and refine together.
That is not less technical.
It is more useful.
If you want, I can also turn this into a shorter summary, a LinkedIn post, or a more Ada Beat–style strategic blog recap.