WorkforgeThe short version of what we are building: a single console where a business can run hiring, procurement, funding, payroll, and payments, without keeping a separate tool for each.
The longer version is more useful, because it explains why this is taking a while and what has to be true before each part arrives.
The seven modules
Workforge is organised around seven areas. Each corresponds to a function that businesses currently handle in a different system.
- Hiring — sourcing, screening, and placing talent
- Bids — time-bound procurement bidding with clear deadlines and document verification
- Funding — sponsor backing for large procurement deals, with milestones tracked alongside the deal
- Payroll — comparing and matching payroll costs
- Payments — escrow-backed transactions, where funds release when terms are met
- Penalties — holding payments automatically when problems are detected
- Network — direct connections between company leaders
The point is not that each of these is novel in isolation. It is that they are currently seven destinations, and the work of moving between them falls on people.
Where things actually stand
The chat interface works. Most of the modules above are not built, and there is no backend behind them yet.
We state this plainly because the gap between a roadmap and a product is where most software companies lose their audience's trust. It is easy to write about seven modules in the present tense. It is also misleading, and the correction always arrives eventually, usually from a customer who expected something that did not exist.
So: the modules above describe direction, not current capability.
Why it takes time
Three reasons, in rough order of how much they matter.
Regulation gates the money
Payments and Penalties cannot ship on engineering readiness alone. Moving, holding, or releasing funds requires banking relationships and regulatory approval. Those processes are run by other parties on timelines we do not control.
This is the single largest constraint on the platform, and it is not one we can engineer around. We could build the software faster than we can be permitted to operate it, which means the correct posture is patience rather than speed.
Building a fast approximation and sorting out compliance afterwards is a recognised strategy in this space. It is not one we are willing to use when the failure mode involves someone else's money.
The modules are genuinely interdependent
Handled well, these functions share more than a login. A vendor approved in Bids should be the same vendor Payments knows about. A hire made in Hiring should be visible to Payroll without anyone retyping it. A milestone in Funding should be able to trigger a release in Payments.
Those connections are the reason to build a single console rather than seven products. They are also why the order of construction matters and why shared foundations have to come before visible features. Building each module in isolation would be faster and would produce exactly the fragmentation we set out to remove.
We are small
A small team can only build one thing properly at a time. We would rather ship modules sequentially, each actually usable, than run seven partial efforts in parallel.
What we are not going to do
Announce dates. We do not have reliable ones, particularly for anything gated on regulatory approval, and inventing them would only convert honest uncertainty into a broken promise.
Describe planned modules as available. If it is not built, we will say it is not built, including in places where that costs us.
Ship money handling before we are permitted to. No exceptions to this one.
What would tell you we are making progress
Reasonable things to watch for, rather than taking our word for it:
- Modules moving from described to usable, one at a time
- The chat interface handling real tasks rather than demonstrations
- Specific, verifiable statements replacing general ones as capabilities land
- Regulatory position stated clearly when it changes, rather than implied
The honest summary
We are building toward a console that consolidates work currently spread across many tools. The interaction layer exists. Most of the functionality does not yet. The parts involving money depend on approvals we do not control, and will take the longest.
That is a less exciting story than a finished platform. It is the accurate one, and for a product that will eventually handle payroll and payments, accuracy seems like the right thing to establish early.