In short
Pharen Hub grew out of a contradiction in our consulting work: clients paid us to solve a problem, and then paid again as soon as their work changed and “just one more thing” had to be adjusted. Every change began with a new explanation, touched roles, data, workflows and notifications, and left ever more system knowledge with us instead of the client. We saw the same mess on our screens: the CRM knew the customer, a drive held the proposal, a chat held the decision. AI sped up individual steps but became just another tab, because a person still had to gather the context.
The idea for Pharen began in 2025; the first working version of Pharen Hub followed in early 2026, sharpened at the HHL Digital Space Traction Lab. Pharen Hub brings tasks, knowledge, operational data, conversations and workflows into one shared workspace so people and AI use the same context and the keys stay with the team.
Across different projects, the scene kept repeating itself. The process worked. The new system was live. The team had started using it.
Then a message arrived.
“Could we change just one more thing?”
It looked harmless. Usually, the request was harmless too. A manager wanted one more approval. A team needed a different view of the data. One customer had an exception that the normal process could not handle.
The client had already paid us to solve the problem. Now they were about to pay us again.
That was good business for a consulting company. It was also the reason we started to question the way we worked.
What one more thing actually meant
Imagine adding one approval to a working process. First, we had to find the exact moment when the approval should appear. Then we had to decide who could give it, what that person was allowed to see, and what should happen if they said no.
The new role needed access to the right data. The workflow needed another route. Notifications had to reach the right people. The normal case still had to work, and so did the strange exception that only happened for one customer.
On a call, the request took one sentence. Inside the system, it could touch almost everything around it.
None of this meant that the client was being difficult. Their work had changed, so the software had to change with it. We traced the process, adjusted the logic, tested the usual path, tested the exception, and made sure the new answer did not create a new problem somewhere else.
The hours on the invoice were real. So was the time the client lost while waiting for us.
What the client really paid for
Every change began with another explanation. Someone from the client team had to show us what had changed, answer our questions, wait for the new version, and check whether it still matched the way people actually worked.
Meanwhile, we carried more and more of the system in our heads.
We knew why a permission existed. We remembered why one integration used a field that looked wrong. We knew that an odd exception could not be removed because it protected an important customer case. Six months later, some of that knowledge might live only in our notes or in the memory of the person who built it.
The software belonged to the client, but too much of its story remained with us.
That was the part we could not ignore. A useful customization had solved a real problem, but it had also made the client more dependent on the people who created it. We did not want the best reason for a client to call us again to be that only we understood their system.
The same mess was on our screens
Our own work was not much better.
Some mornings started with a simple question: where is the current version?
The answer might be in a document, but the decision behind it was in a chat. The task was in another tool. The latest customer message sat in an inbox. Before doing the actual work, we searched, copied, and explained things that somebody had already explained before.
During client calls, we saw the same pattern through screen sharing. The CRM knew who the customer was. A drive held the proposal. An inbox held the latest conversation. A task tool knew what was due next. The one decision that connected all of it might be buried in a chat channel.
The information was all there, yet we still had to rebuild the connection between the pieces.
As consultants, we became good at rebuilding that connection. We asked questions, drew the process, and joined the tools. Yet every new project brought us back to the same basic questions. Where is the reliable information? Who is responsible now? What was decided? What happens when the normal case fails?
The company and the software changed from project to project, but the questions stayed the same.
AI became another tab
AI could read a document, summarize a meeting, or prepare an email much faster than before. We used it, and so did our clients.
But before it could give a useful answer, somebody still had to prepare the full story. We found the correct document, added the customer context, copied the previous decision, and explained what the AI was allowed to do. When the answer came back, a person moved it into the right tool and told the next person what had happened.
AI was fast once it had the context. Gathering that context was still our job.
So AI did not remove the problem of too many tabs. It became one more tab.
That changed the question for us. We no longer wanted a smarter chat window beside the work. We wanted the work itself to carry its context. A task should keep the decision behind it. A workflow should show who owns the next step. An AI agent should know which sources it can use and where a person must remain responsible.
The part we wanted to build once
The idea for Pharen began in 2025. It did not arrive in one brilliant meeting. It grew from a less exciting habit: after projects, we wrote down what had repeated.
Different clients needed different results, but the missing foundation was often the same. Their tasks, knowledge, operational data, conversations, and workflows lived apart. Every custom solution began by pulling those pieces together again.
We started asking what would happen if we built that shared foundation once.
The first working version of Pharen Hub followed in early 2026. At the Traction Lab run by HHL Digital Space, we had to make the idea more precise. A broad vision was not enough. We had to decide which problem should come first and what a team would need before trusting the product in daily work.
Those questions brought us back to the message from our consulting projects. The real problem was not the request for another change. The problem was a system whose context, logic, and history were difficult for the team itself to see.
What Pharen should change
Pharen Hub brings tasks, knowledge, operational data, conversations, and workflows into one shared workspace. The aim is not to place AI on top of another collection of disconnected tools. The aim is to give people and AI the same useful context around the work.
An AI agent can begin with the information already connected to a task. When a step affects money, customer communication, or sensitive data, a person can still own the decision. A team can shape a workflow or an internal tool without beginning with an empty system. Depending on what the company needs, Pharen can run as a managed service, on the company’s own infrastructure, or in a private setup.
This will not make every company identical. It should not. Businesses have different rules, customers, and responsibilities. Some problems will always need specialist work.
What should change is the foundation beneath that work. A useful customization should extend something the team can see and understand. It should not create another private system that only its builders can maintain.
What that message should mean now
Clients will still ask, “Could we change just one more thing?” They should. A system that cannot change with the people using it will not stay useful for long.
We want the next part of the story to be different.
The team should be able to open the workflow and see what the change affects. They should know where the data comes from, who needs to approve the result, and why the exception exists. If they ask for outside help, that work should add to something they can continue to understand and operate.
That is why we built Pharen. Our consulting work taught us how to solve custom problems. It also showed us the cost of making a solution understandable only to the people who built it.
A client may still need our help. We simply want that help to leave them with more understanding and more control than before.
The keys should stay with the team.
