Announced today · beta opens in a few months
Fluidora is a management platform sold by the module. You turn on Project to know who is working on what next week. You add Capacity when part-time enters the picture, Time tracking when someone asks for the hours. Each module works on its own. All of them share one account, one directory and one history.
Not available yet. The Project module is built, the foundation is specified; the beta will open to a limited number of teams.
Classic management suites are sold in one block: you deploy everything, use a part of it, pay for the rest, and every team ends up keeping its own spreadsheet on the side. Fluidora takes the opposite road. A module is what you buy, what one team owns, and what can be switched on in an afternoon without touching anything else.
A module works with none of the optional modules present. When it lacks information only another module holds, it degrades gracefully instead of failing. Project without Capacity considers everyone at 100%; with Capacity, it reads the real figures. Nothing else changes.
What it replacesThe suite where you install twelve bricks to use three.
Fluidora's glossary is normative. A term defined there is the term used in the documentation, in the code, in the API and in the interface. An allocation is called an allocation, from the contract to the screen. That is what stops two teams from building two different things while agreeing in every meeting.
What it replacesThe "project" that means three things depending on the department.
An overload is reported, never blocked. No action is refused because it puts someone past 100%: a plan has to be able to express tension, and a person makes the call. Fluidora holds what is planned, which is a decision someone made, never a prediction.
What it replacesThe tool that refuses to save until the schedule is "valid".
If a screen needs explaining, it is wrong. One primary action per view, defaults that work, no modes. Colour, motion and words are spent on the moment that matters, and the rest stays quiet. Fluidora should feel like good paper and a well-made tool.
What it replacesThe two-day training before the first entry.
They are not hard. They are just spread across three spreadsheets, two calendars and someone's memory.
"A client wants to start on Monday. Can Marie take it?"
One projection: Marie is at 80% on W44 and W45. She can from W46, or someone gives up 20% before that. You answer within the minute, with the number in front of you.
"Two projects, one developer, and both leads were sure they had him."
A person's load on a project is declared once, on the project or on its macro tasks, never both. One number per person per project. Nothing to reconcile on Monday.
"What did we actually do, against what we said we would?"
Project holds the plan. Time tracking, when you turn it on, holds what happened. They sit side by side and neither rewrites the other.
That is the question the Project module answers, the first of Fluidora. Its model fits in four notions, linked in this order. Everything else follows.
A person, a rate and a period. It hangs off a project or a macro task.
Marie · 40% · 1 to 30 Sept.The sum of a person's rates, per ISO week. What they are planned to be doing.
W44 · 40 + 40 = 80%How available a person is in a given week, as a percentage. 100% by default, the real figure with the Capacity module.
Aïcha · 80% every weekA load above capacity over a period. Reported, never blocked.
Tom · W43 · 120% of 100The Project module does not try to do everything. It handles no to-do tasks, no dependencies, no milestones, no time spent. It holds a team's load plan and compares it with its capacity. That choice is what makes it readable in a minute and compatible with the modules to come.
The few rules opposite are the ones that hold the model together. They are written in the glossary before they are written in code.
The module computes and returns results. It does not hand out raw rows to aggregate in a spreadsheet.
One person's load, week by week, with the detail per holder.
The whole team on a grid of weeks, capacity alongside, overloads in evidence.
A project's macro tasks and who is allocated to them, over time.
Macro tasks by canonical category: to do, in progress, done. Comparable from one project to another.
Everyone past their capacity over the period, with the holders involved.
Any projection with draft projects included: "if we green-light this one, who breaks?"
subscription = people · traceability+ project+ capacity+ time tracking
4 people, 1 team. No plan yet: turn on Project to place allocations.
1 person over capacity. Everyone is at 100% until the Capacity module says otherwise.
2 people over capacity. Aïcha works 4 days a week: her 90% on W44 is now an overload.
Planned above, spent below, for the weeks that have passed. The plan has not moved.
Everything in Fluidora is a rate over an ISO week. Marie at 40% from 1 to 30 September, never 12 days of work to spread across a calendar. Nothing is expressed per day, nothing per month. The week is the unit people actually plan in.
A plan is a decision someone made, not a prediction. Fluidora holds what is planned and never what happened, so the two do not blur. And an overload is reported, never blocked: a plan has to be able to hold tension, and a human decides what to do about it.
Because every module speaks the same language and lives in the same account, Fluidora can cross-reference what the modules know and put it within reach of a question. Three capabilities, announced for after the beta, shared by every tool on the platform.
Fluidora will expose its modules through the Model Context Protocol. Your assistant, Claude, ChatGPT or the agent you already have, asks the platform and gets the projection back, not an export to read through. "Who can take 40% in W46?" becomes a question you ask, not a spreadsheet you open.
The assistant goes through the same gateway as you, in your account, with your rights. It sees nothing you would not see.
Every tool will be able to cross what the others know, reading across boundaries, never copying. Project with Capacity: the macro tasks given to someone whose availability drops. Project with Time tracking: the projects where what happened drifts from what was planned. Project with Skills: the identified work nobody has the skill for yet.
Each module stays the owner of its data. Cross-referencing is a read, not a replication.
Wherever you have a choice to make, a person for an allocation, a rate, a starting week, Fluidora will propose a short ranked list: remaining capacity, skills, track record of plans that held. Every proposal comes with its reasons, readable, and is accepted in one gesture.
It is a proposal, never a decision. The plan remains a decision someone made, and the history keeps who made it.
Who can take the Migration macro task, 40% from W46 to W49?
reading: project · capacity · skills · traceability
No allocation is created until you click. The history will record that you decided.
A module gets a vocabulary before it gets a screen. The glossary says what is defined; this map says what is built. The tiles are the logo's: blocks that fit together, and arcs that let something flow from one to the next.
People: your users, your teams, your groups, your account. Every module refers to a person by an identifier People issued, and stores nothing else about them. No name, no e-mail, no profile.
Traceability: every change made by any module, in the same place. Modules keep no local history, no audit column, no previous value. There is one history to read, and one to trust.
That is what lets a module be switched on in an afternoon: it finds its people and its history already there.
Users, groups, teams, accounts. The only place a name lives.
What, when, on which object. From every module.
Modules stay independent because the platform enforces a few contracts everywhere, not because each team promises to behave.
Every piece of business data belongs to exactly one account. No data moves from one account to another, in any module.
What one module exposes is what another may assume. Copying another module's data locally to save a call is a violation, not an optimisation.
A module emits change events and keeps no audit column, no previous value, no versioned row. Traceability holds the record.
Authentication and authorization happen upstream, at a gateway. A module trusts what reaches it, so every module gets the same protection and none reinvents it.
If a screen needs explaining, it is wrong. One primary action per view, defaults that work, no modes.
A button names the outcome: "Plan week", "Archive". Never "Submit", never "OK".
Solve the irritant in front of the user, with the fewest moving parts. Configuration is a last resort.
No Capacity? Everyone is at 100%. The module copes instead of demanding a setting.
Colour, motion and words are spent on the moment that matters. The rest stays quiet. Flat, with a few textures for warmth: good paper, a well-made tool.
One touch of amber per screen: the current week, or the most important action.
Fluidora is not available yet. This page announces what is built, what is specified and what comes next. The beta will open to a limited number of teams, with the Project module and the foundation; people on the waitlist will hear first.
The Project module is built: projects, macro tasks, allocations, the six projections. The foundation contracts are specified: People and Traceability in every subscription, access checked upstream by a gateway, one account and nothing crossing it.
built, not yet openA limited number of teams, the Project module and the foundation, direct support. The goal of the beta is to check that Thursday's question gets its answer faster, not to sell a subscription.
Join the waitlistCapacity, Time tracking, Skills, HR. Then accounting, sales, purchasing, inventory, CRM and manufacturing. Alongside, the cross-module capabilities: MCP server, cross-referencing, AI-assisted selection. Each one gets a vocabulary before it gets a screen.
roadmapNot yet. Fluidora is announced, not open. The beta will open in a few months to a limited number of teams, with the Project module and the foundation. Join the waitlist: we will write to you when it opens, and not before.
No. You start with one team, its projects and its weeks. The Project module only needs people, which the foundation provides, and allocations, which you enter. Nothing else is required.
Everyone is considered at 100% every week. Overloads are computed on that basis. The day you turn on Capacity, real availability (part-time, absences, public holidays) is taken into account and the projections recompute. Nothing else changes.
No, and that is a choice. Load is a rate over a period ("40% from 1 to 30 September"), never a stock to spread. A stock would force a decision on how to spread it across a calendar, and nothing on the platform does that spreading. A rate sums per week and compares with a capacity, directly.
Never. The overload is reported: it shows in the team projection and in the overloads list, with the holders involved. No action is refused because it puts someone past their capacity. A plan has to be able to express tension, and you decide whether to resolve it, or not.
The Project module, no. It holds what is planned and never what happened: no time spent, no progress percentage, no remaining effort. Those notions belong to the Time tracking module, which will be able to show next to the plan without changing it.
In the Traceability module, and only there. Every module emits an event on every change (what, when, on which object) and keeps no local history. You have one record to consult, whatever module it came from.
Every piece of data belongs to exactly one account, and nothing crosses from one account to another. Authentication and authorization are done upstream of the modules, by a gateway: a module is reachable only through what controls access. Fields naming a creator or an administrator are descriptive; they grant nothing.
No. Assisted selection proposes a ranked list with its reasons, and you allocate. A plan remains a decision someone made, and Traceability keeps who made it. Same logic for the MCP server: your assistant reads projections with your rights, in your account, and creates nothing without you. These capabilities come after the beta.
In writing, before code. Any decision touching more than one module gets an RFC: context, alternatives and why they lost, downsides owned. A module gets a glossary page when a specification exists behind it, not before.
Waitlist · beta in a few months
Fluidora is not available yet. Leave us an address: we will write to you when the beta opens, with the Project module and the foundation, to put a first team on it. Nothing else in between.
Composable productivity. Value where it counts.