CEO Quickstart Guide and DeFi Sentinel Exploration

Posted on Dec 3, 2025

Two very different writing tasks today. One document optimized for a specific person. Six documents exploring a product that might not exist in a month. Four commits total, but the line count tells the real story: 4,798 lines of DeFi exploration and 203 lines of the most carefully edited document in the repo.

CEO Quickstart: 203 Lines for Max

The Nixtla workspace has thorough documentation. Architecture docs, API references, deployment guides, compliance audits. What it didn’t have was a document that answers: “I’m Max. I have 10 minutes. What does this do and how do I show it to someone?”

The CEO Quickstart Guide is 203 lines. Not a summary of the existing docs – a completely different document written for a completely different reader. Every sentence was weighed against the question: would Max stop reading here?

Structure:

  1. What this is (3 sentences, no jargon)
  2. What it does (5 capabilities, each in one sentence)
  3. Live demo (3 commands that produce visible output)
  4. Business metrics (what the forecasting tools measure, in business terms)
  5. Architecture at a glance (one diagram, no implementation details)
  6. Next steps (3 specific actions Max can take)

The hardest part was the live demo section. The existing demo project assumed a developer environment – Python installed, dependencies resolved, data files in the right place. The CEO quickstart needed commands that work on a fresh checkout with zero setup beyond git clone. That meant a Docker-based demo path that bundles everything.

Three commands: clone, run, open browser.

If it takes more than that, the quickstart has failed.

The Audience Problem

Writing for a CEO is not “writing simply.” Max understands technology. He runs a company that builds time series forecasting libraries. The challenge isn’t vocabulary – it’s priority.

A developer reading docs wants to know how something works. A CEO reading docs wants to know what something does and whether it’s ready to show externally. Same codebase, completely different questions. The existing 35 documents answered developer questions thoroughly. None of them answered “is this demo-ready for the board meeting next Tuesday?”

The quickstart answers that question in under 203 lines. Every section was reviewed against one filter: does Max need this to show the workspace to someone? If no, it got cut.

Architecture details that a developer would consider essential – dependency trees, error handling patterns, test coverage numbers – didn’t make the cut. They answer the wrong question.

The “Next steps” section was the final addition. Three concrete actions, each with a time estimate. Not “explore the documentation” – specific actions like “run the forecast comparison demo (2 minutes)” and “review the Polymarket skill output (5 minutes).” Actionable beats comprehensive every time when the reader has 10 minutes.

DeFi Sentinel: 6 Documents, 4,798 Lines

The other half of the day was pure exploration. DeFi Sentinel is a hypothetical product that applies Nixtla’s forecasting tools to decentralized finance markets – specifically, predicting liquidity shifts, yield farming returns, and protocol risk signals.

Six documents, each covering a different angle:

Business case. Why time series forecasting matters for DeFi. The pitch: traditional finance has Bloomberg terminals and quantitative models built over decades. DeFi has dashboards showing current state with no predictive capability. There’s a gap, and Nixtla’s tools are purpose-built to fill it.

Product requirements document. Three user personas (yield farmer, protocol treasury manager, risk analyst), five core features, three integration points. Deliberately scoped to an MVP that could ship in 8 weeks with two engineers. Scope discipline matters here because DeFi products have a way of expanding until they’re building a Bloomberg terminal competitor.

Architecture. Data ingestion from on-chain sources (The Graph, Dune Analytics, direct RPC calls), forecasting pipeline using StatsForecast and TimeGPT, alert system for threshold breaches, and a dashboard for visualization. Standard three-tier with an event bus between ingestion and forecasting. The architecture deliberately mirrors patterns from the existing Baseline Lab plugin so the forecasting layer doesn’t need to be built from scratch.

User journey. Step-by-step flow for each persona from first login to daily usage. The yield farmer journey was the most interesting to write – these users are technically sophisticated but time-poor. They don’t want to configure models. They want a notification that says “the ETH/USDC pool on Uniswap v3 is likely to see a 15% liquidity drop in the next 48 hours.”

Technical specification. API contracts, data models, infrastructure requirements, cost estimates. The cost modeling was the most eye-opening section – running StatsForecast against DeFi data at 1-minute granularity for 50 pools generates roughly 72,000 data points per pool per day. The compute costs are manageable but the data ingestion from on-chain RPC calls is the bottleneck. This is the document that would become the implementation roadmap if the product gets greenlit.

Status document. Current state: exploration phase. No code written. No commitments made. No timeline established. The status doc exists specifically to prevent scope creep – it’s a written record that this is an exploration, not a project.

Why Write 4,798 Lines for Something That May Not Ship

Exploration documents serve two purposes.

First, they force clarity. You can’t write a technical specification for a vague idea. The act of writing the spec reveals which parts of the idea are solid and which are hand-waving. The DeFi Sentinel architecture doc is where the data ingestion bottleneck surfaced – before writing the spec, “pull data from on-chain sources” sounded simple. After writing the spec, it became clear that RPC call costs dominate the infrastructure budget.

Second, they’re reusable. If DeFi Sentinel doesn’t happen, the architecture patterns, the data ingestion design, and the alert system specification all transfer to other forecasting products. The 4,798 lines aren’t wasted even if the product is.

The status document is the most important of the six. Without it, exploration has a way of becoming commitment. Someone references the architecture doc in a meeting, another person starts a Jira ticket, and suddenly there’s a sprint planning session for a product nobody actually greenlit.

The status doc is a firewall: “This is an exploration. There is no project. If you want to make it a project, that’s a separate decision.”

Related Posts: