Who builds DeliverySheet, and why
DeliverySheet is built and supported by one person: Tan Gravam, in Amsterdam. When you email tan.gravam@gravam.com, the person who wrote the code answers.
Background
Tan has spent about eighteen years in SAP, treasury and enterprise systems, as a solution architect and as a manager, much of it inside large delivery programmes.
Programmes like that are where the problem this product addresses is hardest to miss. Requests arrive from every direction, each one reasonable on its own, and a small number of people have to decide which of them become promises — usually before anyone knows what the work really involves. The essays on this site are written from that seat.
Why it exists
The same failure repeats in delivery organisations of every size: teams commit to work before anyone has established that it is understood, owned, sized and unblocked. The missed date arrives months later, but the miss was decided at the commitment — in a meeting, a deck and a Slack thread that kept no record.
Organisations rarely fail because they cannot track tasks. They fail because they commit to the wrong work, with incomplete information, before delivery reality is understood. The tools most teams already have are good at the work after the promise — tickets, boards, schedules. The step before it, deciding what to promise, is the one that usually has no tool at all.
DeliverySheet holds that one layer: from a vague request to a clear delivery decision, with the shape, owner, capacity, dependencies and open questions visible before anyone commits people, budget or a date. Committing early is still possible — real deadlines exist — but it is recorded as an exception naming why it is early, what is missing, who accepts the risk and what would change the decision. The glossary defines the vocabulary the product uses.
What it deliberately does not do
The product is opinionated, and its refusals are design decisions rather than gaps waiting on a roadmap:
- No time tracking, timesheets or billable hours.
- No per-person performance metrics — no completion rates, velocity or delivery scores.
- No story points, sprints or burndown charts.
- No salary or actual-cost tracking.
- No custom fields or configurable stages — every workspace follows the same lifecycle.
It also does not replace Jira or Linear for day-to-day execution today: it owns the decision, not the ticket queue. The reasoning is in the comparisons and in Allocation, not consumption.
How it's built
DeliverySheet is a Nuxt application. Supabase provides the database and authentication (AWS us-east-1, Northern Virginia), the Anthropic API drafts structure from a pasted request — server-side only — and the service is hosted on Hetzner in Germany. AI drafts; people decide: suggestions are labelled as suggestions, and what gets committed, who owns it and what was actually delivered are recorded by a person. The full list of the six providers that process data, and what each one does, is in the privacy policy.
How it's run
Deliberately small and independent: one builder, no growth team, opinionated scope. That has consequences worth stating plainly — the product does fewer things than the large tools around it, and support is one person's inbox. It also means the person who reads your email can change the product. Pricing is one number on the pricing page, and the trial requires a card because honest constraints beat growth theatre.
Get in touch
Questions about the product, a disagreement with an essay, or a request that does not fit: write to tan.gravam@gravam.com. To see the thinking applied before signing up for anything, paste a work request into the free request check — no account, and nothing is stored.