# Projects & work — Opelli

> Projects & work in Opelli: a project overview, collaborative project knowledge and a task board that stays focused — team, capacity, time, deadlines and customer context in one place.

_Markdown edition of https://opelli.dev/features/work — generated from the page itself on 2026-08-25._

---

[Home](https://opelli.dev/../index.html) › [Features](https://opelli.dev/index.html) › Projects & work

_Area 01_

## Projects & work

A project overview, collaborative knowledge and a task board that stays focused.

### Ask for it — Turn meeting notes into connected tasks.

Your assistant reads the note, creates tasks in the right project and links each one back to the decision it came from.

### Projects — The whole project on one page.

See the team, capacity, time, deadlines, tasks, customer context and project knowledge in one place.

Compare planned and tracked time before the project runs over budget.

![A project detail page: a team and capacity table, planned against tracked time, and wiki and task widgets.](https://opelli.dev/../img/project.jpg)

### The project wiki — Where the work gets written down.

Every project has a wiki for meeting notes, decisions and product briefs — written together, connected to tasks and shared only where you choose.

![A wiki page in reading view: page tree with nested subpages, breadcrumbs, an embedded interactive flow chart, and linked task pills.](https://opelli.dev/../img/wiki-page.jpg)

![The wiki editor on a meeting note: attendee chips, the Markdown text and an insert menu offering a task, a page, an image and a flow chart.](https://opelli.dev/../img/wiki-editor.jpg)

_Everyone edits the same page at once_

_Diagrams and tables directly in the page_

_A linked task, straight from the note_

- **Collaborative project knowledge** — Edit pages together and keep meeting notes, decisions and product briefs in one place.
- **Turn decisions into work** — Create linked tasks directly from meeting notes.
- **Share only what a client needs** — Give guests access to selected pages without exposing the rest of the project.
- **Discuss work in context** — Comment on exact passages and keep the conversation with the source material.
- **Use rich content without lock-in** — Add diagrams, tables and files, then import or export in Markdown.

### Tasks — A board that stays small.

Types, six statuses — "Won't do" is an answer too — one assignee and one level of subtasks. Small enough that the board stays a view of the work.

![The Tasks board: status columns with typed task cards, assignees and due dates.](https://opelli.dev/../img/tasks.jpg)

![A task opened read-first: the description up front, a P0–P3 priority control and quick status and owner selects in the sidebar, and the Weekly sync meeting note it came from linked below.](https://opelli.dev/../img/task-detail.jpg)

Compact mode fits the whole sprint on one screen.

![The same board in compact mode: one line per card with the key, the title, a due date and the owner's avatar, and every status column visible at once.](https://opelli.dev/../img/tasks-compact.jpg)

- **A focused task board** — Track status, priority, ownership and deadlines without turning the board into a second job.
- **Plan in sprints** — Keep current work together and carry unfinished items forward.
- **Connect code and work** — Link GitHub activity to the tasks it belongs to.
- **Keep the context** — Files, comments and linked wiki pages stay with the task.

### Datasets — A row a day, next to the roadmap.

Some of the numbers a team lives by are written by machines — the app's store figures every morning, a monitor checking the site every five minutes, an assistant reporting what it read overnight. Each gets a dataset under its project, appends one row at a time, and the wiki shows the history as a live table or chart.

![A dataset of the mobile app's daily store metrics: one profile card per column with a histogram or the most common values, the sortable table of rows beneath, and the ingest token with its ready-made curl snippet beside it.](https://opelli.dev/../img/datasets.jpg)

![A wiki page with the same dataset embedded as a live chart of daily actives and a filtered table of Android stability beneath a paragraph of commentary.](https://opelli.dev/../img/wiki-dataset.jpg)

```
POST /datasets/12/rows
Authorization: Bearer opds_…
Idempotency-Key: ios-2026-08-22
Content-Type: application/json

{ "timestamp": "2026-08-22T06:30:00+02:00", "platform": "ios",
  "installs": 113, "dau": 3359, "crash_free_pct": 99.8, "rating": 4.4 }

→ 201  { "inserted": 1, "duplicates": 0, "ids": [4471] }
```

- **Append, never re-upload** — Every record is one row added with one request — there is no file to fetch, edit and put back, so two writers can never overwrite each other. Send an Idempotency-Key and a retried request is stored once.
- **A token that can do one thing** — Each dataset has its own ingest token, and all it can do is append rows to that dataset. Rotate or revoke it from the dataset page, which also hands you the curl, RouterOS and Python snippets ready to run.
- **Free-form, or declared** — Rows are JSON. Declare the columns and their types and a malformed record is refused with the key named; leave them undeclared and the dataset takes what comes — an uptime monitor's status and response time, say.
- **Profiled, charted, in the wiki** — The dataset opens on a column profile — type, count, a histogram or the most common values — above a table that sorts and filters on any column and a time range, a chart of the numeric columns, and JSONL, CSV or JSON exports. Save a sort, filters and a chart as a named view, then type `/dataset` in a page to embed it: it reads the current rows every time the page opens, and stays as private as the page.
- **Written by an assistant, too** — A scheduled assistant that scans the news, social media and research papers each morning appends what it found — source, title, relevance — and the team reads the table in the wiki. The same goes for a CI job, a router or a sensor: anything that can make one request can keep a dataset.
- **Bounded on purpose** — A dataset keeps up to 100 000 rows and ages old ones out on the retention you choose. A secret download link for a dashboard outside Opelli is off until you switch it on, and says plainly what holding it means.

### Ask for it — From the day's rows to a chart on the page.

Your assistant finds the dataset, reads the month out of it, saves what it read as a named view and puts that view on the wiki page — as a live chart that keeps growing with each morning's row.

### Apps — The tool your team built, running inside Opelli.

Some tools are yours alone — a retro board, an estimator, a dashboard over the datasets above. Upload the built app, or let your assistant write it, and it opens for signed-in members right in Opelli: versions, rollback, storage and sign-in already taken care of.

![An app's detail page: the numbered version history with one version live, the app's saved state — shared keys and the viewer's own — and the ready-made CI workflow snippet beside them.](https://opelli.dev/../img/apps.jpg)

![The same app open in Opelli: a retrospective board with three shared columns and the viewer's private draft, running full width under the top bar.](https://opelli.dev/../img/app-runner.jpg)

- **Versions, never edits-in-place** — An upload is a numbered version and nothing changes for the team until you press Publish. Every earlier version keeps a Roll back button, so a bad release is one click old.
- **Project-wide or org-wide** — An app belongs to a project and opens for its members — or to the whole organization. External guest accounts never see it either way.
- **Runs as the person using it** — An app runs with each viewer's own sign-in, so what it can read and change is exactly what that person could anyway — a dashboard over a dataset shows each member their own permitted slice, with no credentials anywhere in its code. Publishing asks for one consent in return: publish only what you wrote or reviewed. Every publish is recorded in the security trail.
- **State without a backend** — Apps that need to remember things get built-in storage: per-person state for drafts and preferences, shared state for a board everyone sees — saved on the server, with concurrent updates handled safely.
- **From GitHub on every push** — The app page hands you a ready-made CI snippet: push to main, and the build lands as a new version — published only when the workflow says so, with an API key that can touch apps and nothing else.
- **Your assistant builds it end to end** — A connected assistant can create an app, read its source, make edits, stage a version and publish — the same loop it uses for microsites, now for internal tools.

### Ask for it — From a sentence to a tool the team opens.

Your assistant creates the app, writes its files and publishes the first version — a retro board whose columns live in shared state, ready on the project page before the meeting starts.

### See it on your own operations.

Opelli runs in the cloud on an `opelli.dev` address or your own domain. Leave your email and we will show you how it fits the way your team works.

Next

Planning & people →