v1 shipped · Board, forecasting, flow metrics & document storage all live · Onboarding first customers

Forecast from what your team delivers,
not what they predict.

PtahCast is a flow-based project management tool with Monte Carlo probabilistic forecasting built into the data model from day one — not added as a reporting plug-in. No story points. No velocity. No pretending.

PtahCast forecast dashboard showing a Monte Carlo simulation with P50, P70, P85, and P95 completion dates over a 90-day throughput sample

"Every other tool asks you to estimate before you start.
We ask you to measure while you work."

The PtahCast principle

The problem

Your burndown chart is guessing.

Sprint velocity, story points, planning poker — these are rituals that make uncertainty feel managed without actually reducing it. The estimate your team committed to in sprint planning is going to slip. Everyone in the room knows it.

The old model

Estimate → commit → miss → explain

Attach a story point count to every ticket before work starts. Accumulate velocity. Produce a sprint commitment. Watch it slip. Run a retrospective about why it slipped. Repeat. Teams spend 20–30% of their time in ceremonies built around this cycle, and the forecasts are no more accurate than a gut feeling would have been.

The PtahCast model

Measure → forecast → decide with confidence

Track how many tickets your team actually completes per week. Run 10,000 simulations over that distribution. Get an honest probability range: 50% done by this date, 85% by that one. No estimates on tickets. No velocity. No pretending the uncertainty isn't there.

What we're building

Three systems. One source of truth.

The board, backlog, and Monte Carlo forecasting engine are all live. PtahCast builds the forecast into the board's data model — every ticket movement is a data point. No extra setup. No CSV exports. No second tool.

I — The Board

Flow, not sprints

Kanban-style columns with WIP limits. Work moves when it's ready, not when a sprint boundary arrives. Every column transition is timestamped — this is the raw data the forecast engine runs on.

WIP limits Classes of service Transition log Sprint mode optional
II — The Backlog

Inbox and Ready. Nothing in between.

Tickets live in Inbox until the team agrees they're workable — acceptance criteria defined, nothing missing. Only Ready tickets reach the board. The board stays a picture of active work, not a wish list.

Definition of Ready Acceptance criteria PM-controlled gate Needs Clarification
III — The Forecast

Probability, not promises

Monte Carlo simulation over your team's actual throughput history. Run at the epic level or the full board level. A probability distribution over completion dates — not a date that will slip, a range that is honest about what can and cannot be known.

Monte Carlo Epic forecast Board forecast Stored runs Cold-start bootstrap

Pricing

Sized by team, not by guesswork.

Three tiers, flat USD worldwide — no regional pricing to game, no per-seat charges to punish you for including people in the work. The line between tiers is team size, because that's what actually predicts whether a plan fits — not how many boards you've created. Every tier gets the full Monte Carlo engine, unlimited simulations, and free export. Always.

Lite

$15/month

Solo developers, freelancers, tiny teams

  • Up to 3 users
  • 1 project
  • Full Monte Carlo forecasting
  • Unlimited simulations
  • Flow metrics dashboard
Start 30-day trial
Most teams

Standard

$49/month

A single team, shipping together

  • Up to 25 users
  • Up to 5 projects
  • Full Monte Carlo forecasting
  • Unlimited simulations
  • Flow metrics dashboard
  • Document attachments
Start 30-day trial

Business

$89/month

Multiple squads, one engineering org

  • Up to 75 users
  • Generous project allowance
  • 20GB document storage
  • Full Monte Carlo forecasting
  • Unlimited simulations
  • Flow metrics dashboard
Start 30-day trial

More than 75 people? Talk to us — we'd rather size a plan around what a large org actually needs than guess at a number nobody's confirmed yet.

Building in public

We're building this in the open.

No stealth mode. No locked beta. Phases 1 through 4 are done and running — the board, the Monte Carlo forecasting engine, the flow metrics dashboard, and cold-start throughput for brand-new projects are all live. We're now in Phase 5: document storage, with launch itself still ahead in Phase 6. The decisions, the wrong turns, and the methodology are all going up as we build. If you've been maintaining a Monte Carlo spreadsheet alongside Jira, this is being built for you.

Phase 1 — Foundation ✓ Done

Board, backlog (Inbox / Ready), epics, WIP limits, classes of service, transition logging.

Phase 2 — Forecasting ✓ Done

Monte Carlo engine. Epic forecast view. Board forecast view. Stored forecast history.

Phase 3 — Flow Metrics ✓ Done

Throughput run chart. Cycle time scatter plot. WIP over time. Cumulative flow diagram.

Phase 4 — Cold-Start Throughput ✓ Done

Synthetic bootstrap estimate for brand-new projects with no delivery history yet, resolving automatically to real data week by week. Per-person cross-project throughput report, so the starting estimate is evidence-based rather than a guess.

Phase 5 — Storage ✓ Done

Document attachments on tickets, backed by a dedicated volume on each client's own droplet — not a third-party object store.

Phase 6 — Launch ← Now

v1 is live. Lite, Standard, and Business plans — sized by team, not project count. Onboarding the first external customer now.

Build status · July 2026

Current phase v1 — Live
Foundation ✓ Board · Backlog · Epics · Users
Forecasting ✓ Monte Carlo · Epic & board level
Cold-start forecasting ✓ Bootstrap estimate for new projects
Per-person throughput ✓ Cross-project delivery evidence
Flow metrics ✓ Throughput · Cycle time · WIP · CFD
Document storage ✓ Ticket attachments, droplet-backed
Stack Flask · SQLite · Python
Deployment model Hosted · Per-client Docker
Story points Zero. None. Never.
Trial 30 days · full features, every tier

The name

Why Ptah?

Ptah was the Egyptian god of craftsmen, architects, and builders — the patron deity of those who shape raw material into something precise and useful. Sculptors, metalworkers, engineers: Ptah was their god.

What set him apart from every other deity in the Egyptian pantheon was how he created. He did not forge the world through physical effort. He created by speaking truth. He declared what was real, and it became real. In a mythology full of gods who acted, Ptah was the one who told the truth about what was.

That is not an accidental connection to what this tool does. PtahCast is built on a single premise: that an honest declaration of uncertainty is more useful than a false promise of precision. Telling your stakeholders "there is an 85% chance this is done by 29 October" is not a hedge. It is the truth, spoken clearly. The sprint commitment that slips to the next sprint and the one after that — that was never the truth.

Ptah was also said to give craftsmen the ability to see the finished form inside unworked stone — to know what a thing would become before it fully existed. We like that too.

Questions

Before you ask

What happens after my 30-day trial?

Nothing automatic. We'll reach out before it ends to talk through which tier fits your team — there's no auto-charge, and nothing gets paused or deleted without you knowing first. If it's not for you, you just walk away.

We're on Jira, or just spreadsheets — how do we actually move over?

Right now this is a hands-on conversation, not a self-serve importer — tell us what your backlog and history look like and we'll work through getting you set up directly. You don't need months of clean historical data to start, either: cold-start bootstrap forecasting gives you a working estimate from day one, and it gets more accurate as real throughput comes in.

Who owns our data, and can we get it out?

You do, fully. Every tier includes free CSV/JSON export of your forecast history, any time. And because each customer runs on their own isolated instance rather than a shared database, there's nothing tangled up with anyone else's data if you ever decide to leave.

Why per-client Docker instead of a shared multi-tenant setup?

Isolation. Your data lives in its own instance, not a shared table filtered by customer ID — so there's no risk of a bug or a noisy neighbour affecting your account, and backups and exports are simply "your instance," not a query across everyone's data. The trade-off is that spinning up a new customer isn't instant — it's a short manual step on our end, which is also why trial requests go through a real conversation rather than an automated signup.

Get started

Ask a question, or start your 30-day trial.

Both go straight to the team — no ticketing system, no auto-responder maze.

Request info

Questions before you commit to anything.

Start a 30-day trial

Full features, every tier, no card required.