We released Viarah today as our submission to the OpenAI developer challenge.
If you’re deciding whether to care, here’s the short version: Viarah is a self-hostable delivery workspace for teams shipping client work. It’s not “special” because it tracks tasks — it’s special because it treats client-safe visibility and deliverables (reports and Statements of Work) as first-class, not as a pile of conventions glued onto a general-purpose tracker.
The gap: your tracker isn’t the thing you publish
Most delivery teams run two systems whether they admit it or not:
- An internal tracker that reflects reality (messy, nuanced, sometimes sensitive).
- An external story that you can safely share (weekly updates, roadmaps, PDFs, emails).
The external story is where time disappears. Even with excellent tools, it often devolves into a ritual:
- screenshots of boards
- manually curated lists of “done / next / blocked”
- a “client board” that drifts out of sync
- a doc template nobody quite maintains
You can configure your existing tracker to reduce the pain. The problem is the governance cost over time: fields multiply, workflows calcify, and the “safe view” becomes something only two people know how to maintain.
Viarah’s core idea is simple: delivery work is multi-audience by default. The system should make it easy to be honest internally and confidently shareable externally.
What Viarah makes first-class (practical, not theoretical)
Viarah’s foundations are familiar — Projects → Epics → Tasks → Subtasks, plus assignments, scheduling, and time estimates — but it adds delivery-specific primitives that change the day-to-day workflow.
Client-safe visibility and a client portal
Viarah includes explicit client visibility controls and a dedicated client portal experience, so client users see only client-safe work and client-allowed detail surfaces. That reduces the need for parallel “sanitized” tracking systems.
Workflow stages as a shared language
Workflow stages are ordered, which helps keep progress tracking consistent across the board, timeline, gantt, and reports. “Progress” is less about individual interpretation and more about shared semantics.
Deliverables: reports + SoWs live in the same system as the work
Viarah supports:
- Reports rendered from versioned Liquid templates, with run history and render logs.
- Public share links for report runs (token shown once; the server stores only a hash), with expiry support and access logs.
- Statements of Work (SoWs) with versions, signers, and PDF artifacts.
This is the part most trackers don’t cover well: the things you actually send to clients are treated as real objects with history.
Integrations and automation hooks
If your delivery work lives in GitLab, Viarah supports GitLab integration so tasks can link to issues/MRs and refresh metadata (optionally via webhooks). And if you want tooling to run workflows, the companion viarah-cli exists so automation can operate ViaRah via API keys instead of scraping UI state.
A concrete workflow: a client-safe weekly update you can run every Friday
To make “deliverables-first” tangible, here’s a simple workflow Viarah is designed to support.
1) Define a small set of stages you can keep consistent
Don’t overfit. Five to seven stages is usually enough. Example:
- Planned
- In progress
- Blocked
- Review
- Shipped
The important property is consistency: board, timeline, gantt, and reporting should agree.
2) Mark what’s safe to share (deliberately)
A useful rule of thumb:
- client-safe work describes outcomes and deliverables (what changes for the client)
- internal-only work captures implementation details, spikes, sensitive dependencies, or “not ready to discuss” items
3) Render the weekly update from a template
Mini-template you can start with:
Weekly delivery update — {Project} — Week of {Date}
- Highlights (2–5 bullets)
- Shipped
- {client-safe tasks moved to Shipped}
- In progress
- {top client-safe tasks in progress}
- Risks / blockers
- {blocked items + short reason + next action}
- Asks
- {decisions needed from the client}
- Upcoming dates
- {milestones / timeline notes}
Instead of rewriting this as an email every week, treat it as a deliverable with history: render it, keep the run log, and share it.
4) Share it safely
This is where edge cases matter:
- Use expiry when you don’t want “forever links.”
- Treat share links like credentials (don’t post them in public channels).
- Remember: the token is shown once. If your process needs recoverability, plan for link rotation.
Do this tomorrow (60–90 minutes): a one-sitting evaluation
If you want a practical evaluation without a committee:
- Spin up a local instance (self-hostable).
- Create one project, define stages.
- Add one epic with 10–15 tasks.
- Mark 4–6 tasks client-safe.
- Render a weekly report and generate a share link.
- Ask: “Would I be comfortable sending this to a client with no extra editing?”
If that feels like a relief instead of a chore, you’re seeing the point.
Why not just use your current tracker differently?
It’s a fair objection — and for some teams, the right answer is “don’t switch tools.”
If you already have stable tracker governance (someone owns workflows, trains the team, audits fields, and keeps client-facing views accurate), you can get far with conventions:
- standardize statuses
- add a client-facing summary field
- maintain dashboards
- keep a separate client board
- use a weekly update doc template
The tradeoff is the cost of keeping that system coherent as projects vary, team members change, and deliverables become contractual artifacts.
Viarah is aimed at teams who want a tool where the healthier delivery path is the default:
- client-safe visibility is explicit
- reports and SoWs are objects with history and logs
- client sharing doesn’t require parallel tracking or manual redaction
If you recognize the “tracker configuration became a second job” pattern, Viarah is built to reduce it.
If you want help designing a delivery workflow that stays client-safe under pressure — and you want something you can send to stakeholders without rewriting it — book a free consultation at https://via-logos.com or email hello@vialogos.org; you’ll leave with a written project pipeline, draft SoW(s), and an official quotation you can use as a quote.
Sources
- OpenAI developer platform (Codex and tools): https://developers.openai.com/
- Via Logos (company + contact): https://via-logos.com/
