What does RootStack do?

RootStack is an agentic Postgres operations platform. It autonomously detects, diagnoses, and (with human approval for write actions) remediates database incidents — connection pool exhaustion, slow queries, replication lag, index bloat, the routine Postgres pain that wakes up infrastructure engineers. Customers report 50-70% reduction in database-related on-call pages within ninety days.

How is RootStack different from existing observability tools like Datadog?

Observability tools tell you that a problem exists. RootStack tells you what the problem is and what to do about it, and (with permission) does the diagnostic and remediation work autonomously. The two layers are complementary — most customers keep Datadog and add RootStack on top.

How do you keep an autonomous agent safe in production databases?

Three layers: aggressive scoping (the agent has tightly defined tool access, never broader than needed), explicit confidence thresholds (low-confidence cases escalate to a human), and human-in-the-loop for any write action (the agent produces a plan with evidence; a human approves before execution). The agent never silently mutates production.

Why did you leave Stripe to build RootStack?

I'd handled the same eleven incident shapes hundreds of times across six years at Stripe. I realized that 96% of the diagnostic-and-remediation work was mechanical and could plausibly be automated by an LLM with the right tool access. The pattern was too clear to ignore, and nobody at scale was building it. I gave my notice six weeks after the 3 AM page that crystallized the realization.

How did the MCP protocol affect your distribution strategy?

Massively. We ship first-class MCP integrations for Cursor, Claude Code, and Zed. Roughly 40% of new sign-ups come through the Cursor MCP listing, with conversion to paid at 18% and six-month retention at 94%. The protocol gave us distribution at near-zero acquisition cost across every editor that supports it.

Tomas Okafor's RootStack: The Postgres Agent Story

IChapter 1 of 5

The Problem

## The Page at 3:14 AM

It was March 4, 2024 when my pager went off at 3:14 AM. I was on call for Stripe's database platform team. The alert was familiar: a primary Postgres instance in our payments cluster had hit 94% CPU and replication lag was climbing. The runbook was one I'd written eighteen months earlier and personally executed sixteen times since.

I SSH'd into the primary. Ran the same five queries. Identified the same long-running query (a poorly-indexed analytics scan against a table the analytics team wasn't supposed to be querying directly). Killed it. Paged the analytics team. Went back to bed at 4:02 AM.

Lying there I had a clear thought. There were maybe eleven incident shapes I'd handled more than a dozen times each over six years at Stripe. Each followed a well-defined diagnostic sequence. The work, when I was doing it at 3 AM with a half-functional brain, was almost entirely mechanical. The interesting part, the part requiring senior judgment, happened in maybe 4% of cases. An LLM, in 2024, with the right tools and guardrails, could probably do the other 96%. Not perfectly. But well enough that I wouldn't have to be woken up for routine cases anymore.

I started sketching on my iPad at 5:30 AM.

## The Stripe Job I Loved and Was Leaving

Stripe had been the best six years of my career. The infrastructure team did extraordinary work. I'd been promoted twice. What changed wasn't the job. What changed was that I'd seen something specific I couldn't unsee. The 3 AM page was a symptom of a category of work I was confident could be automated, that nobody at my scale was building (I'd looked throughout 2023), and that I was uniquely positioned to build.

The math wasn't subtle. If RootStack could autonomously handle 60% of the most common Postgres incidents, every infrastructure team using it would save $400K-$2M per year in engineering time and reduced downtime.

The Journey

## Building Solo, Then Not Solo

The first six months were just me, in a $1,800/month office in DUMBO. I built the v0 prototype on a weekend: a CLI that took a Postgres connection string and ran a fixed diagnostic playbook. Then I made it agentic: Claude Opus 4 calling read-only Postgres tools, with human approval before any write. The first time I saw the agent correctly diagnose a connection-pool exhaustion on my test cluster, I screenshotted it and texted my partner. (She replied "what am I looking at" and I realized I'd spent so long heads-down that I'd forgotten how to explain the thing I was building.)

September through December 2024 was customer discovery. Forty-three infrastructure leaders at companies from twenty-person Series A startups to thousand-person scaleups. The pattern was consistent: they had observability, they had occasional Postgres pain, they were skeptical of agents touching production but curious about read-only diagnostics. Every one asked how the agent handled being wrong.

The answer I converged on: aggressive scoping, explicit confidence thresholds, human-in-the-loop for any write action. The agent never silently mutated production. It produced a remediation plan with evidence; a human approved or modified it. The human kept the consequential decisions. The agent ate the toil.

I hired my first engineer, Aisha, a former Datadog database-performance engineer, in February 2025. She took 30% less than her Datadog comp. She told me later she'd accepted because the prototype I'd shown her actually worked.

## The First Customer Was the Wrong One

The first paying customer was a Series C fintech in Manhattan. $24K annual pilot, March 2025. The deployment was a political disaster. Their head of infrastructure was excited. Their head of security was deeply skeptical. The first read-only deployment took eleven weeks to clear procurement and security review.

I learned painfully that selling agentic infrastructure to enterprise security teams was a different motion than selling SaaS. The SOC 2 audit we'd planned for Q3 had to move up to Q1. The deployment guide was rewritten three times.

The second customer, a Series A SaaS company with an autonomous infra team, was the inverse. They self-served onto the read-only tier in seven minutes, were running diagnostics by lunch, and upgraded to full ten days later. The wedge clarified: start with smaller engineering-led teams who could deploy autonomously, build depth and case studies, then move upmarket once the security story was airtight.

## The Cursor Integration Changed Everything

In June 2025 the Cursor team shipped first-class MCP support. We shipped a RootStack MCP integration in three weeks. Suddenly any engineer who used Cursor could ask their editor "why is the staging Postgres slow?" and get a real diagnostic answer pulled from their database, in context.

By end of Q3 2025, roughly 40% of new sign-ups came through the Cursor MCP listing. Acquisition cost was effectively zero. Conversion to paid: 18%. Six-month retention: 94%. We also shipped MCP for Claude Code and Zed. Every editor supporting MCP became a distribution channel without any per-channel work.

The Struggles

## The Imposter Months

The first nine months solo were emotionally harder than I expected. I'd spent six years inside Stripe where my technical judgment was trusted. The day I left, all that context evaporated. I was a guy with an idea in a small Brooklyn office with no one to share decisions with.

I underestimated how much of my professional identity at Stripe had been built on peer calibration. When you spend years being told you're good, you stop having to actively believe it. When that feedback loop disappears, the believing becomes active work. It took me until October 2024 to stop second-guessing every architectural decision against an imagined Stripe principal engineer in my head.

The other struggle was loneliness. I'd left a team I genuinely liked. There were stretches in fall 2024 when I'd realize I'd gone three days without a sustained in-person conversation. I started attending in-person developer events in early 2025 partly as a sales motion and partly as sanity preservation.

## The Race Component

I'm a Black founder building developer infrastructure. Most partner meetings were respectful and ended in declines that were probably about deal sizing rather than identity. A few, three of the thirty-some I took, had a different texture. The questions were less about the product and more about whether I "had the founder profile." I knew what that meant.

More than the bias in any single interaction, I noticed the absence of pattern-matching the other direction. White founders pitching similar devtools businesses had automatic credibility I had to manufacture per meeting. The past population of devtools founders was not, on the whole, Black. I learned to over-prepare. Every meeting: three case studies, two architecture diagrams, a clear narrative on why I specifically was the right person to build this. I shouldn't have had to. I did anyway. The deals closed.

## The Security Incident That Almost Ended Us

In September 2025 we caught a deployment-template misconfiguration that had granted our agent broader Postgres privileges than it needed on three customer deployments. The agent had drop-table capability. It had never used it. No incident, no data loss. But least-privilege had been violated.

I called all three affected customers within twenty-four hours. Sent each a full timeline, remediation, and audit log proving no improper action. Two thanked me. The third, the original Series C fintech that had been hard to sell into in the first place, pulled us out of production within ninety-six hours and didn't renew.

The non-renewal stung. We rebuilt our IAM templating, added a security audit step to onboarding, and published a public post-mortem with the technical root cause. The post-mortem was uncomfortable to write. It was the highest-converting piece of content we'd ever published. Three new customers cited it as the reason they trusted us enough to deploy. The customer trust built by unflinching transparency in your worst moments is worth more than every win in your good ones.

The Lessons

## What I'd Tell Someone Considering Leaving a Senior Job to Start Something

I left Stripe in 2024 to build RootStack. Two years in, here's what I wish I'd known.

§1. The specificity of your pain is your competitive advantage

I built RootStack because of a 3 AM page. The specific shape of that page became the spec for the product. Founders who build from generalized pain build generic products. Founders who build from specific personal pain build wedges. If you can't draw a clean line from a specific personal experience to a specific product capability, you're building too early.

§2. Customer discovery is not a checkbox

I did forty-three customer discovery calls before hiring my first engineer. The useful ones were the calls where I let the customer talk for forty minutes without showing the deck. If you've done thirty calls and haven't been actively surprised by something, you weren't listening hard enough. Do thirty more.

§3. Solo is harder than you think; co-founders are riskier than they look

I built solo. I made it work. I would not necessarily recommend it. The loneliness and erosion of professional identity were real costs. A good co-founder would have mitigated those costs. A bad co-founder would have created worse ones. There's no clean answer. Build a personal board of advisors if you're solo. Write the separation agreement up front if you're cofounding.

§4. The marketplace is the channel; the editor is the surface

Cursor and Claude Code MCP integrations were our biggest channel investment and cost almost nothing. In 2026, agentic infrastructure tools should ship MCP first, dashboard second. The dashboard is for the buyer. The MCP integration is for the user. The user converts the buyer.

§5. Transparency in your worst moments is the strongest marketing you have

The September 2025 post-mortem was the most uncomfortable document I've published and the most effective. Trust isn't built by claiming you'll never fail. Trust is built by demonstrating how you behave when you do. Write the post-mortem. Publish it. Don't sanitize it.

§6. Identity and category interact in ways you have to plan for

Being a Black founder pitching developer infrastructure in 2024-2025 was not the same experience as a non-Black founder pitching the same category. I closed the rounds I needed to close. But the work to manufacture credibility was higher. If you're an underrepresented founder in a deep technical category, over-prepare. Find investors who'll evaluate you on the work rather than on pattern-matching.

§7. The model curve is doing work for you; don't fight it

I bet that underlying LLMs would keep improving and architected RootStack to ride the curve. Every six months we get a better model. Each makes our product smarter without us doing anything. Architect for model swap-in. Use the best available model today. Plan to use a better one in six months.

Tomas Okafor Quit Stripe to Build the Postgres Agent He Wanted at 3 AM

The Problem

The Journey

The Struggles

The Breakthrough

The Lessons

§1. The specificity of your pain is your competitive advantage

§2. Customer discovery is not a checkbox

§3. Solo is harder than you think; co-founders are riskier than they look

§4. The marketplace is the channel; the editor is the surface

§5. Transparency in your worst moments is the strongest marketing you have

§6. Identity and category interact in ways you have to plan for

§7. The model curve is doing work for you; don't fight it

Frequently asked

Tomas Okafor

Responses

Join the conversation