Fully Managed Wekan
as a Service

Engineering teams arrive at Wekan when their Trello or Jira sprint history becomes a privacy concern or a per-seat tax. The operational anchor is internal change-management policy — every card move is an event, every comment is an audit-trail entry, and the customer's SDLC controls dictate retention.

• DANIAN config: OIDC SSO bound to the customer's identity provider, with an outgoing webhook firing to the engineering chat on every card column change.
• Workflow example: a sprint board with columns Backlog → In Progress → Code Review → QA → Done, swimlanes per epic, labels for bug / feature / tech-debt, and custom fields for ticket-number and reviewer.
• Quantifiable detail: a typical 8–12 person squad maintains 4–6 active boards and processes 80–120 cards per sprint; about 25 GB of attachments per year end up on object storage.

Donor-funded organisations need a kanban tool that doesn't punish growth — a 25-volunteer working group can't justify $1,500 a year in per-seat fees, and grant donors increasingly want their reporting infrastructure under the organisation's own control. The operational anchors are grant-reporting timelines and jurisdiction-specific data-handling rules where EU donors or beneficiaries are involved.

• DANIAN config: region picked to match the donor jurisdiction, Google OAuth enabled so volunteers log in with personal accounts, public read-only board flag available where transparency matters.
• Workflow example: a grant pipeline board running Prospecting → Application drafted → Submitted → Awarded → Reporting, with monthly review swimlanes and a custom field for funder name.
• Quantifiable detail: a 10-seat plan handles three boards (grants, programs, comms), about 30 cards per week, and seven-year backup retention to match common grant-audit requirements.

Production floors need a visual board that survives shift changes, integrates with the MES, and authenticates against the same Active Directory that issues badge access. The operational anchor is ISO 9001 quality-management documentation — defect tracking, root-cause analysis, and containment actions all need to live somewhere auditable.

• DANIAN config: LDAP bound to Active Directory so shop-floor users authenticate with existing badge identities, custom fields exposing batch ID and defect code, an outgoing webhook firing to the internal MES.
• Workflow example: one board per production line, swimlanes per shift, defect cards moving Reported → Triage → Containment → Root Cause → Closed with attached photos.
• Quantifiable detail: 25–50 seats, 5–8 boards (one per line plus a shared quality-review board), about 200 cards per week at peak, attachments dominated by 2–8 MB defect photos.

Records-request intake at a city agency and editorial pipelines at a small newsroom share the same need: every item has a clock against it, every state change is accountable, and the finished package needs to be archivable in its final form. The operational anchors are jurisdiction-specific records-request response timelines and editorial style-guide compliance.

• DANIAN config: in-country region, SAML or OIDC against the institutional identity provider, board export feature enabled so completed records-request packages can be archived in their final form.
• Workflow example: an FOI intake board moving Received → Acknowledged → In Search → Redaction Review → Released, or an editorial pipeline moving Pitched → Assigned → Drafting → Edit → Fact-check → Published.
• Quantifiable detail: 15–40 seats, retention of completed cards for 5–10 years per records-management policy, about 50 cards per week intake at a small newsroom or city agency.