Creation process

A project management tool should be run like a project

Here is how FluidOps goes from a real problem to a feature that is live: six steps, a written trace each time, no surprises.

  1. 1

    Listen to the problem

    What we do

    Every feature starts from a lived situation: a deadline that slips, a wrong estimate, a team that no longer knows who does what.

    What you gain

    No features added just for the sake of adding features.

  2. 2

    Frame it

    What we do

    The need becomes a numbered requirement, tied to a goal, with a clear criterion for when it is done.

    What you gain

    A clear scope, so fewer detours.

  3. 3

    Design it

    What we do

    We draw the simplest screen that solves the problem, with the brand’s visual system and accessibility in mind.

    What you gain

    Screens you understand in a few seconds.

  4. 4

    Build in iterations

    What we do

    Short cycles: a prioritized backlog, one goal per cycle, a definition of “done” and an honest retrospective, in the spirit of the agile guidelines of ISO/IEC 29110-5-4.

    What you gain

    Steady improvements rather than one big bang.

  5. 5

    Verify

    What we do

    Every requirement is linked to test cases. Security, accessibility and data protection audits, then a re-audit to confirm the fixes.

    What you gain

    What is announced works, and what is fixed stays fixed.

  6. 6

    Ship and improve

    What we do

    Every change is logged with its reason. User feedback feeds the next cycle.

    What you gain

    A product that evolves while staying readable.

The proof

Written down, not just promised

Traced requirements

From need to test: each requirement has an identifier and its test cases.

50+ test cases

Described step by step, replayable before every release.

Audits and re-audits

Security, accessibility, data protection: findings, fixes, checks.

Dependencies inventoried

The list of libraries used and their licenses (SBOM) is kept up to date.

Data protection

Built in from the start

  • No audience measurement before you consent.
  • Self-hosted font: no calls to Google Fonts.
  • Data access controlled row by row, on every table.
  • A strict content security policy against script injection.

What this process is not

Our documentation follows the structure of ISO/IEC 29110 (basic profile for very small entities). It is not a certification: we will only speak of compliance after an assessment by an accredited body. It is our way of working, and it is written down.

A question about our method?

Write to us, we are happy to answer. Or try the result for yourself.