WorkforgeMost business software is built to solve one problem well. That is usually the right instinct, and it produces good products. The difficulty appears later, once an organisation has adopted a dozen of them.
Hiring lives in one system. Procurement lives in another. Payroll is somewhere else, often with an external provider. Payments happen in a banking portal that nobody else has access to. Each tool is defensible on its own. Together they form something no one designed.
That accumulated shape is what we started Workforge to address.
The problem is between the tools, not inside them
Ask someone what slows their work down and they rarely name a feature. They describe a seam: the vendor approved in procurement whose payment details have to be re-entered elsewhere, the headcount signed off in one place that payroll finds out about weeks later, the contract milestone tracked in a spreadsheet because it spans two systems that do not speak.
Nobody owns the seams. Each tool owner is responsible for their own product working correctly, and it does. The work of carrying information across the gaps falls to people, informally, and it is largely invisible in any measure of how the business runs.
We think that work is substantial, and that it is a design problem rather than a discipline problem.
Why a chat-first console
The obvious answer is integration: connect the tools so the seams disappear. That approach is well served already, and it has a structural limit. Integrating a dozen systems produces a dozen contracts, a dozen update cycles, and a coupling problem that grows faster than the value it delivers.
We are trying something different. Rather than connecting separate destinations, put the functions behind one conversational surface, so the interface is what you are trying to do rather than which system owns it.
The reason chat rather than another dashboard is that most of these tasks begin as a sentence, not as a screen. Someone wants to know whether a vendor is approved, or to start a bid, or to check a payroll figure against a budget. Expressing that directly is closer to the actual intent than navigating to the module that holds the answer.
This is a bet, and it may prove wrong in places. Some work genuinely wants a table and a set of filters. We expect to learn where the conversational model helps and where it gets in the way.
Where we actually are
We should be precise about this, because there is a strong temptation in early-stage writing to describe intentions as though they were achievements.
The chat interface works. The modules the platform is organised around — Hiring, Bids, Funding, Payroll, Payments, Penalties, and Network — are largely not built yet. There is no backend behind most of them. Anything involving money is further out still, because Payments and Penalties require banking relationships and regulatory approval before they can responsibly handle real funds.
We are a small, early-stage team. Sequencing is the main thing we get to decide, and we would rather build fewer things properly than announce a complete platform that does not exist.
What we are not doing
We are not trying to replace every specialist tool. Some functions are deep enough to deserve dedicated software, and pretending otherwise would produce a worse version of things that already work well.
We are also not going to describe planned capabilities as though they were shipped. If a module is not built, we intend to say so, including in our own marketing. That is a slower story to tell, but it is the only one that survives contact with a customer.
Why now
Two things make this worth attempting. Conversational interfaces have become reliable enough to carry real work rather than serving as a novelty layer. And the cost of tool fragmentation has grown as the number of available point solutions has grown, which means the seams are wider than they were.
Whether the specific approach is right is an open question. The problem is not.