WorkforgeWorkforge is organised around seven modules: Hiring, Bids, Funding, Payroll, Payments, Penalties, and Network. Presented as a list, that reads like a roadmap with seven parallel workstreams.
It is not. We are a small team, and we can meaningfully build one thing at a time. The interesting decision is not what to build but in what order, and that decision has consequences we would rather understand deliberately than discover later.
Sequencing is the main lever we have
With limited capacity, most strategy reduces to ordering. Build the wrong thing first and you spend months on something that has to be reworked once you understand the adjacent problem. Build the right thing first and later work gets easier because the foundation fits.
Two questions have driven our order so far:
What does everything else depend on? Shared foundations should come before the features that sit on them, even though foundations demo poorly and generate no visible progress.
What can we learn from cheaply? Some work teaches you a lot per unit of effort. Some only teaches you whether you built it correctly. Early on, the first kind is worth more.
Why the chat interface came first
The conversational surface is the part every module will eventually sit behind. If the interaction model is wrong, that error propagates into all seven modules, and by then it is expensive to change.
It is also the cheapest place to be wrong. A conversational interface with limited functionality still teaches you how people phrase what they want, where the model misunderstands, and which tasks resist being expressed as a sentence. That knowledge shapes every module afterwards.
So the chat interface works today, and the modules behind it largely do not. That ordering looks strange from outside — an interface without much to interface with. It made sense to us because the alternative was building modules against an interaction model we had not tested.
Why anything involving money comes last
Payments and Penalties are the two modules we are furthest from shipping, and this is deliberate rather than incidental.
Handling other people's money is not primarily an engineering problem. It requires banking relationships and regulatory approval, and those are gated by parties outside our control on timelines we do not set. No amount of internal velocity moves that forward.
There is a version of this company that builds a payments feature quickly, describes it in optimistic language, and works out the compliance position afterwards. We are not interested in that version. When funds are involved, being early is worth much less than being correct, and the failure mode is not a bug report but somebody's money.
So Payments and Penalties wait. In the meantime we are careful about how we describe them, including on this site.
What being small actually changes
Some of it is straightforwardly harder. There is no parallel capacity, so everything is a trade. A week spent on one module is a week not spent on another, and there is no way to buy your way out of the choice.
Some of it helps. Decisions are cheap to make and cheap to reverse. There is no coordination overhead between teams, because there are no teams to coordinate. When we learn that an assumption was wrong, we can change direction in a conversation rather than a planning cycle.
The main risk is not moving slowly. It is spreading thin — starting several modules because each individually seems achievable, and ending up with seven things that are each seventy percent finished. Seventy percent of a payroll feature is not useful to anyone.
How we are trying to avoid that
Three working rules:
- One module at a time reaches usable, before the next one starts. Not feature-complete, but genuinely usable for a real task.
- Foundations before surface. If two pieces of work compete and one is depended on by future modules, it goes first even when it is less visible.
- No describing planned work as shipped. Internally this keeps our own picture honest. Externally it is the difference between a customer trusting us and not.
What this means if you are watching
Progress will look uneven. There will be periods where the visible surface barely changes because the work is underneath it, and the modules will arrive one at a time rather than as a platform launch.
We think that is the honest shape of building this with a small team. The alternative — announcing seven modules and delivering partial versions of all of them — would look faster and be worth less.