Event sourcing without the infrastructure

Your database is lying to you.

Tuesday, 4:47pm: Customer says they were charged twice. $847.

With Postgres

4:48pm Check Stripe dashboard.

5:15pm Cross-reference your database.

6:30pm Spouse texts: "dinner?"

8:45pm Still not sure who's right.

With j17

4:48pm Query payment events.

4:49pm See exactly what happened.

4:51pm Retry bug. One-click refund.

4:52pm Home for dinner.

How? Every change is stored as an immutable event. Nothing is overwritten. Nothing is lost.

Professionals write in pen, not pencil. With event sourcing, your software can too.

Start today, ship today Read the docs

Free tier forever, or paid plans from $0.25/day.

★

Founder's Circle: 2 of 25 claimed. Permanent profile badge and we'll build what you ask for.

You've seen the Greg Young talks. You've read the Fowler post.

You've always known this was the right architecture. Now it's finally practical.
Define your events. POST JSON. Query current state.

Need custom logic? Escape to WASM or bring your own runtime.

spec.json — define once

{
  "user": {
    "events": {
      "wasCreated": {
        "handler": [
          { "op": "set", "path": "/", "value": "$.data" }
        ]
      },
      "hadNameUpdated": {
        "handler": [
          { "op": "merge", "path": "/", "value": "$.data" }
        ]
      }
    }
  }
}

POST /events — that's it

curl -X POST https://you.j17.dev/user/abc123/wasCreated \
  -H "Authorization: Bearer $J17_API_KEY" \
  -d '{ "data": { "name": "Alice", "animal": "alpaca" } }'

curl https://you.j17.dev/user/abc123
# → { "state": { "name": "Alice", "animal": "alpaca" } }

curl -X POST https://you.j17.dev/user/abc123/hadNameUpdated \
  -H "Authorization: Bearer $J17_API_KEY" \
  -d '{ "data": { "name": "Alicia" } }'

curl https://you.j17.dev/user/abc123
# → { "state": { "name": "Alicia", "animal": "alpaca" } }

Cheaper than one hour debugging lost data

Win every dispute

"Show me what happened." One query. Every state change, timestamped, immutable. Compliance audits become a formality.

No Kafka. No PhD.

Six declarative operations cover 80% of everything. Define your schema, POST JSON, GET JSON back.

Cheaper than parking

$0.25/day. The architecture banks use, for less than a parking meter.

Your entire backend fits in a context window

Write the domain knowledge once. It informs everything after.
Rules, events, state are all structured data. No tribal knowledge, no buried logic.
Your team, your tools, and whatever comes next all learn from the same source.

See how this enables AI development →

What people are saying

Nothing yet. We're new.

"Contrived testimonials would normally go here, but you're too smart for that."

Tess T. Monial

CEO, Placeholder Industries

"Waiting for social proof is itself a form of social proof, of the power of conformity over discernment."

Earl E. Adopter

Founder, Definitely Real Co.

"If we'd made this up, you'd have stopped reading two boxes ago."

Rory D. Bird

CMO, We Can't Afford Inc.

The most valuable question is the one you haven't thought of yet.

On March 7th, a customer named Sarah adds a pair of running shoes to her cart. Size 8. Navy. She removes them four minutes later.

Your database dutifully records the current state of her cart: empty. The shoes were never there. In the only record that matters, Sarah never wanted them.

Eleven months later, your client calls. She's been reading about win-back campaigns. "Can we find out what people almost bought?"

If you built on Postgres, the answer is a long pause and a short apology. The data was destroyed before anyone knew it was data. "I can track that from now on for you."

If you built on an event store, you wrote the query before she finished explaining. It turns out almost-purchases convert at 40% with a well-timed nudge. That insight was sitting in the event stream for eleven months, waiting for someone to think of the question.

Events are trivially cheap to store and impossible to value. That's not a limitation, it's the entire point.