Infrastructure

Workflow orchestration and reliability for distributed systems

Keepstep · Durable workflows in TypeScript that run on your own Postgres

WatchingDraft scoreEstablished market · since 2017 · AI estimate

70PWAS score

Confidence

Based on 9 of 9 factors

Overview

AIThis description was written by a model from public signals. The facts behind it are listed under Evidence.

Problem: Organizations need to reliably orchestrate, execute, and monitor complex asynchronous workflows and microservices at scale. Failures in distributed systems require durable execution that can survive restarts and partial outages.
Solution concept: A platform that provides durable workflow orchestration with automatic retries, timeouts, and state management so developers can build reliable distributed systems without building this infrastructure themselves. Customers pay based on the scale of workflows executed.
Who has it: Engineering teams at technology companies and financial services firms building distributed systems and microservices architectures, from startups to enterprises like NVIDIA, JPMorgan Chase, and OpenAI.
How they handle it today: Not stated in the source.
Why now: Not stated in the source.
How it could charge: Usage-based pricing tied to the number of "billable actions" executed on the platform, with expansion revenue as customers scale their workflow volume.

Verdict

Computed from the factor scores below, never written by a model. It decides nothing on its own: only the gate makes an opportunity a build candidate.

Keep watching

Score breakdown

A model sorted each factor into a rubric bucket; code turned buckets into numbers. Unknown factors are left out of the score and lower confidence instead.

Market validation

Confidence 70 · 3 evidence · Proven market with 4,300 paying customers at major technology and financial companies, plus 43 million open-source installs showing widespread adoption.

Revenue evidence

Confidence 70 · 2 evidence · Multiple public signals of substantial revenue: 200%+ annualized growth rate and 200%+ net dollar retention demonstrating strong monetization and expansion.

Growth

Confidence 70 · 3 evidence · Breakout growth shown by multiple independent signals: 350% year-over-year growth in billable actions, 200%+ revenue growth, and 134% growth in open-source adoption.

Problem severity

Confidence 30 · Judged from the description · Critical problem: unreliable distributed systems block work, risk compliance violations, and directly lose revenue for companies operating at scale.

Economic proximity

Confidence 30 · Judged from the description · Direct revenue recovery and operational automation: the platform prevents costly failures and enables reliable transaction processing that directly impacts customer revenue.

Distribution

Confidence 30 · Judged from the description · Collaboration tool: workflow orchestration requires integration across engineering teams and services, creating network effects as more developers and systems adopt the platform.

Buildability

Confidence 30 · Judged from the description · Complex: requires deep distributed systems expertise, durable state management, multi-region support, and reliable execution guarantees—not commodity components.

Differentiation

Confidence 30 · Judged from the description · Clear gap: the problem is widespread and named by users, requiring specialized infrastructure that general-purpose orchestration tools do not adequately address.

Retention and timing

Confidence 30 · Judged from the description · Daily embedded workflow: orchestration is deeply embedded in core platform operations, and microservices adoption is a strong timing tailwind.

Risk penalties

Heavy regulationFinancial services firms are a core customer segment; compliance with financial data handling and audit requirements is non-trivial.−9

Score history

70 · confidence 44 · config v1First score · 8 Oct 2026

Distribution

AIWritten by a model on 9 Oct 2026 from the description and the evidence. Estimates and proposals, not verified facts.

Embedded: An SDK lives inside the customer's service code. Once teams write workflows against it, other services in the same organization tend to adopt it so they can call those workflows and share retry and timeout behaviour.
Search: Engineers search for specific failure problems such as retrying idempotent payment steps, saga compensation, or resuming long-running jobs after a crash. Concrete guides with working code for each pattern can bring them in.
Collaboration: A shared dashboard for workflow history and failures gets used by on-call engineers, other teams and support staff when they debug incidents. That pulls more people in each organization onto the tool.

Build

AIWritten by a model on 9 Oct 2026 from the description and the evidence. Estimates and proposals, not verified facts.

Suggested first version: A self-hostable durable execution engine for one language (for example TypeScript), aimed at a small backend team running background jobs and multi-step API workflows. Developers write workflows as ordinary functions. The engine records every step's result in a Postgres event log, so a crashed process resumes where it stopped, with per-step retries, timeouts and durable timers. A basic web view shows running and failed executions. It deliberately leaves out multi-language SDKs, multi-region replication, a hosted multi-tenant cloud, versioning tooling beyond simple workflow version tags, and enterprise access controls.
Core features: Workflow-as-code SDK for one language with deterministic replay of completed steps
Durable step results persisted to Postgres so execution survives restarts
Per-step retry policies with backoff and configurable timeouts
Durable timers and sleeps that persist across process restarts
Signals to send external events into a running workflow
Worker pool that polls a task queue and leases work with heartbeats
Web UI listing executions, step history, errors and a manual retry button
Per-execution action counting to support later usage-based billing
Outside services it would depend on: A relational database (Postgres) as the durable event and queue store
Architecture sketch: Application workers embed the SDK and run workflow and step code. A coordinator service hands out tasks from queues stored in Postgres, using leases and heartbeats. Each step's start, result or failure is appended to an event log. On a crash or redeploy, another worker picks up the lease, replays the log to rebuild state, and continues from the next step. A timer component scans for due timers and retries and puts them back on the queue. A read-only API and web UI query the event log for history and metrics.
Estimate: 45 working days · complexity high
Running cost: Running cost would mostly come from database write volume and storage for event histories, which grow with every executed step and retention period.

Differentiation and risks

AIWritten by a model on 9 Oct 2026 from the description and the evidence. Estimates and proposals, not verified facts.

How it could differ: Run entirely on a database the team already operates (Postgres) instead of a separate cluster, which lowers the operational barrier for small teams.
Pricing tied to predictable units such as workers or executions, not per-action counts. This is relevant because the material describes an incumbent whose revenue expands with billable action volume.
Focus on one language and one deployment model so smaller teams face a shorter learning curve, rather than covering every enterprise need.
Risks: CommercialThe source describes an incumbent with over 4,300 paying customers, more than 43 million open source installs and enterprise adopters. A new entrant would compete against a free open source option that is already widely used.
TechnicalGetting durable execution right is hard: deterministic replay, exactly-once step semantics, lease expiry races and workflow code versioning. Subtle bugs can corrupt state, and buyers of reliability infrastructure will not accept that.

Workflow orchestration and reliability for distributed systems

Overview

Verdict

Build this business

Score breakdown

Risk penalties

Score history

Validation gate

Evidence · 6 items

Market validation

Revenue evidence

Growth

Market

Existing products

Distribution

Build

Differentiation and risks

Legal reconstruction check

Community