“Could we change just one more thing?”
The question kept returning in our consulting projects. The system was finished, the team was using it, and a manager now needed another approval. Or one customer had an exception the original process did not cover.
The request was reasonable. The work had changed. We went through the process again, adjusted the logic and tested the change.
The client had already paid us for the solution. Now they paid us again. The hours were real. Something still bothered us: too often, our help was necessary because too much knowledge about the system had stayed with us.
A small change carried a long history
An additional approval required more than another button. We needed to establish where the decision belonged, who could make it and what information that person should see.
Then came the route after a rejection. Should the task go back? Who received a message? Which existing exception still needed to work?
We understood the reasons behind the rules. We remembered why an integration used a strangely named field or why a particular detour could not be removed. For us, that knowledge was part of the solution. For the client team, it was sometimes knowledge they had to request from us again.
The software belonged to the client. Too much of its history belonged to the people who built it.
Our own work was scattered too
Our screens told a similar story. The current version lived in a document and the decision behind it in chat. A task was in the project tool; the latest customer message was in an inbox.
Before doing the work, we reconstructed the relationship. We searched, copied and explained things somebody had already explained. We saw the same effort when clients shared their screens.
We became good at it as consultants. We connected the tools and asked questions until the process made sense. Yet each project brought back familiar uncertainties. Which information was current? Who took over now? What had been decided? Why did the exception exist?
Different companies had different processes. The effort of recovering their context looked familiar.
AI needed the same explanation
We used AI to read, summarise and prepare text. Our clients did too. Once the right material was available, an answer could be produced more quickly.
Preparing that material remained our job. We found the document, added the customer context and explained the earlier decision. Afterwards, someone transferred the result back into the appropriate tool.
We had gained a capable assistant and retained the same handoff. AI could work with the material supplied to it. It did not automatically turn a scattered history into an authoritative account of the work.
That made us more interested in how a task could retain its sources and decisions. A colleague taking over should be able to see the relationship. AI preparation should land where a person can review and use it.
The foundation we wanted to build together
The idea for Pharen took shape in 2025 through those recurring questions after projects. Tasks, knowledge, data, conversations and workflows lived apart. Each custom solution began by bringing some of them together.
The first working version of Pharen Hub followed in early 2026. At HHL Digital Space’s Traction Lab, we had to decide more precisely which problem came first. A shared workspace was too broad an idea on its own. It needed to help a team with a particular job.
The extra approval from our consulting work remains a useful test. Can the team see where it belongs? Can they understand the affected information and roles? Will someone later be able to tell why the rule changed?
Pharen Hub is our attempt to provide that shared foundation. It will not make every adjustment simple. Companies have different rules, and some changes will continue to require specialist help.
What should happen with the next request
A client should still be able to ask for one more change. A system needs to adapt to the work.
Our aim is for that change to build on something the team understands. Its reason should not disappear between a conversation with us and the technical implementation. It belongs with the workflow.
If the next approval needs our help, that is fine. Afterwards, the team should know more about its process than before. That was what we found missing in a model where every reasonable change began with the same explanation.
