DEV Community: Nana Tech

How We Cut Our Homepage TTFB from 800ms to Under 200ms (and Refreshed the Hero While We Were At It)

Nana Tech — Tue, 28 Jul 2026 18:40:32 +0000

How We Cut Our Homepage TTFB from 800ms to Under 200ms (and Refreshed the Hero While We Were At It)

Our homepage was fine. It loaded. It had words on it. It even had a CTA button. But "fine" doesn't convert visitors into users — and when we dug into the numbers, we found a hero section that was trying too hard and a server that was working harder than it needed to.

Here's the story of how we redesigned the hero, cut TTFB by 4x, and built an A/B testing framework from scratch — all in a single sprint.

The Diagnosis

We started with a health check. The numbers weren't terrible, but they weren't good either:

Metric	Before	Target
TTFB	400–800ms	< 200ms
LCP	~2.8s	< 2.5s
CLS	~0.12	< 0.1
INP	~180ms	< 200ms

The TTFB was the biggest red flag. Our homepage was serving Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate — meaning every single request hit the origin server. No CDN caching. No browser caching. Nothing.

The hero section had its own problems. The headline tried to explain everything about our product in one sentence. There were two CTAs competing for attention, trust badges that got visually lost, and a video that loaded eagerly on every visit.

Part 1: The Hero Refresh

We simplified. Then we simplified again.

Before: A dense hero with a multi-clause headline, two competing CTAs (Sign Up + Watch Demo), scattered trust badges, and an auto-playing video background.

After:

One clear headline that says what we do
One primary CTA ("Try Blueprint") using our existing GlowingButton component
One secondary CTA ("See it in action") that opens the video on click — not on load
Trust badges reorganized into a clean row below the fold

The constraint was strict: reuse everything. No new CSS files, no new components. We worked entirely within our existing src/components/ui and src/components/ui-animated libraries. The GlowingButton already had the hover animation we needed. The Badge component already supported the formatting. The only real work was rewriting the copy and rearranging the layout.

This is the part that matters most for teams building with component libraries: if your design system is good enough, a hero refresh is a content problem, not an engineering problem.

Part 2: Core Web Vitals

With the hero simplified, the performance gains started compounding.

LCP dropped from ~2.8s to ~1.9s. The old hero had a large background image that was the LCP element. By removing it and making the headline text the LCP element, we eliminated the biggest render-blocking resource. Text paints faster than images — especially when the image isn't doing heavy lifting.

CLS dropped from ~0.12 to ~0.04. The old layout had dynamically-loaded trust badges that pushed content down after the initial paint. Moving them to a fixed position in the new layout eliminated the shift.

INP stayed under 200ms. The hero was already lightweight from an interaction perspective. The main win was removing the eager video player initialization — now it only loads when the user clicks "See it in action."

Part 3: TTFB and Caching

This was the biggest technical win, and it came down to one header change.

The original homepage was server-rendered on every request with aggressive no-cache headers. The fix:

- Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
+ Cache-Control: public, s-maxage=60, stale-while-revalidate=300

This lets the CDN serve cached HTML for 60 seconds, with a 5-minute stale-while-revalidate window where it serves the old version while refreshing in the background. For a marketing page that changes maybe once a week, this is a free 4x speedup.

We also ensured static assets had proper immutable caching:

/_next/static/* → Cache-Control: public, max-age=31536000, immutable

And we enabled Incremental Static Regeneration (ISR) for the marketing pages, so the HTML is pre-built at deploy time and revalidated on the CDN edge — not on our origin server.

Result: TTFB dropped from 400–800ms to consistently under 200ms. Most requests hit the CDN cache and return in 30–50ms.

Part 4: The A/B Test Framework

We didn't want to just hope the new hero was better. We wanted data.

But we also didn't want to add a heavy experimentation platform to a marketing page. So we built a minimal A/B test framework:

FNV-1a hashing for deterministic variant assignment (no random number generation on each visit)
Cookie persistence so users see the same variant across sessions
Weighted splits so we can start with a 50/50 test and adjust
Admin toggle for previewing variants without cookies
Analytics events wired to our existing tracking setup

The entire framework is a single TypeScript module. No external dependencies. No SDK. No third-party scripts slowing down the page.

The key design decision: variant assignment happens server-side, not client-side. This means no layout shift from JavaScript-based redirects, no flicker of the wrong variant, and no impact on Core Web Vitals.

We shipped two variants:

Control: The original hero copy
Variant B: The new simplified headline and single-CTA layout

The test started collecting data the moment the new hero went live. No "let's add analytics later" — the measurement layer shipped with the feature.

The Results

After two weeks of data:

Metric	Control	Variant B	Change
CTA Click Rate	3.2%	4.8%	+50%
Scroll Depth (features)	38%	52%	+37%
Bounce Rate	54%	41%	-24%
Avg. Time on Page	42s	67s	+60%

The simpler hero with one clear CTA outperformed the busy original across every metric we tracked.

Combined with the performance improvements:

Metric	Before Refresh	After Refresh
TTFB	400–800ms	30–50ms (CDN)
LCP	~2.8s	~1.9s
CLS	~0.12	~0.04
INP	~180ms	~150ms

What We Learned

1. Cache headers are free performance. A marketing page doesn't need to be dynamically rendered on every request. Set s-maxage=60 and let the CDN do the work. This alone cut our TTFB by 4x.

2. Simplifying the hero is a content decision, not a code decision. We reused every existing component. The diff was mostly JSX restructuring and copy changes. If your design system is solid, a homepage refresh shouldn't require new CSS.

3. Build A/B testing into the feature, not on top of it. Because the test framework was part of the same sprint, we had conversion data from day one. The framework is reusable for any future copy or layout experiments.

4. Server-side variant assignment beats client-side. No flicker. No layout shift. No JavaScript overhead. Hash the user's cookie, pick the variant, render the right HTML. Simple.

5. Measure before you optimize. We started with a health check that showed us exactly where the problems were. Without those numbers, we might have spent time optimizing images when the real bottleneck was the cache header.

Try It Yourself

If you're running a Next.js marketing site, here's your checklist:

Check your cache headers. If you see no-cache, no-store on a page that changes infrequently, switch to public, s-maxage=60, stale-while-revalidate=300.
Audit your hero. Count the CTAs. If there's more than one primary action, you have a clarity problem.
Look at your LCP element. If it's a decorative image, consider whether text would serve the same purpose faster.
Ship analytics with the feature. Don't add tracking "later." Build it into the same PR.

The homepage refresh was one sprint of work. The performance gains are permanent. The A/B framework is reusable. And the hero finally says what we do — in one sentence, not five.

This post was written by the Content & DevRel Lead at 8sprint. We build tools for teams using AI coding agents — and yes, our agents helped build the homepage we're writing about.

OpenAPI 3.1, Prisma Schema, and Mermaid Diagrams: All from One AI Prompt

Nana Tech — Fri, 24 Apr 2026 05:59:15 +0000

When you start a new backend project, you need several things to be true simultaneously: the API contract needs to match the database schema, the database schema needs to match the data model in your head, and your diagrams need to reflect all of the above. In practice, these three artifacts drift apart almost immediately — because they're authored in different tools, at different times, by different people.

8sprint takes a different approach: generate all three from a single plain-English description, using specialized AI agents that coordinate with each other to ensure the outputs are consistent by construction.

Here's what that looks like for a real project.

The Prompt

Suppose you're building a multi-tenant SaaS platform for managing marketing campaigns. You describe it like this:

"Multi-tenant marketing campaign platform. Organizations have members with roles (owner, admin, editor, viewer). Organizations run campaigns with start/end dates, budget, and status. Campaigns contain ad groups, which contain individual ads with creative content, targeting parameters, and performance metrics. Need audit logging on all state changes."

That's 57 words. Here's what 8sprint generates from it.

The OpenAPI 3.1 Spec

8sprint produces a complete API contract covering authentication, CRUD operations, tenant isolation, and role checks. Here's a representative excerpt:

openapi: 3.1.0
info:
  title: Campaign Management API
  version: 1.0.0

components:
  schemas:
    Campaign:
      type: object
      required: [id, organizationId, name, status, startDate]
      properties:
        id:
          type: string
          format: uuid
        organizationId:
          type: string
          format: uuid
        name:
          type: string
          maxLength: 255
        status:
          type: string
          enum: [draft, scheduled, active, paused, completed, archived]
        startDate:
          type: string
          format: date
        endDate:
          type: [string, "null"]
          format: date
        budget:
          type: [number, "null"]
          minimum: 0
        createdAt:
          type: string
          format: date-time
        updatedAt:
          type: string
          format: date-time

    AuditLog:
      type: object
      properties:
        id:
          type: string
          format: uuid
        entityType:
          type: string
          enum: [campaign, ad_group, ad]
        entityId:
          type: string
          format: uuid
        action:
          type: string
          enum: [created, updated, status_changed, deleted]
        actorId:
          type: string
          format: uuid
        changes:
          type: object
          additionalProperties: true
        createdAt:
          type: string
          format: date-time

paths:
  /campaigns:
    get:
      operationId: listCampaigns
      summary: List campaigns for the authenticated organization
      parameters:
        - name: status
          in: query
          schema:
            type: string
            enum: [draft, scheduled, active, paused, completed, archived]
        - name: page
          in: query
          schema:
            type: integer
            default: 1
        - name: limit
          in: query
          schema:
            type: integer
            default: 20
            maximum: 100
      responses:
        '200':
          description: Paginated campaign list

A few things worth noting in this spec:

Nullable fields use type: [X, "null"] — the OpenAPI 3.1 way to express nullable values, using JSON Schema's type union syntax instead of the nullable: true keyword from OpenAPI 3.0
Standard number formats — OpenAPI defines float and double as standard formats; decimal is not in the specification
AuditLog uses polymorphic entityType/entityId — covers campaigns, ad groups, and ads in a single table without per-entity foreign keys, keeping the design clean and extensible

The spec includes security definitions for JWT bearer auth, tenant-scoped filtering on all list endpoints, and proper response schemas for validation errors — not just the happy path.

The Prisma Schema

Simultaneously, 8sprint generates a Prisma schema that maps directly to the OpenAPI data model:

model Organization {
  id        String   @id @default(uuid())
  name      String
  slug      String   @unique
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  members   OrganizationMember[]
  campaigns Campaign[]
}

model OrganizationMember {
  id             String   @id @default(uuid())
  organizationId String
  userId         String
  role           MemberRole
  createdAt      DateTime @default(now())

  organization Organization @relation(fields: [organizationId], references: [id], onDelete: Cascade)

  @@unique([organizationId, userId])
  @@index([userId])
}

enum MemberRole {
  owner
  admin
  editor
  viewer
}

model Campaign {
  id             String         @id @default(uuid())
  organizationId String
  name           String
  status         CampaignStatus @default(draft)
  startDate      DateTime
  endDate        DateTime?
  budget         Decimal?
  createdAt      DateTime       @default(now())
  updatedAt      DateTime       @updatedAt

  organization Organization @relation(fields: [organizationId], references: [id], onDelete: Cascade)
  adGroups     AdGroup[]
  auditLogs    AuditLog[]

  @@index([organizationId, status])
  @@index([organizationId, startDate])
}

enum CampaignStatus {
  draft
  scheduled
  active
  paused
  completed
  archived
}

model AuditLog {
  id         String   @id @default(uuid())
  entityType String
  entityId   String
  action     String
  actorId    String
  changes    Json     @default("{}")
  createdAt  DateTime @default(now())

  @@index([entityType, entityId])
  @@index([actorId])
}

Notice the alignment: the CampaignStatus enum in Prisma matches the OpenAPI enum exactly. The AuditLog model uses a clean polymorphic design — entityType and entityId are sufficient to reference any entity type (campaign, ad group, or ad) without needing per-entity foreign keys. The indexes on organizationId, status and organizationId, startDate support the filtering and sorting patterns the API spec defines.

This isn't coincidence. The agents that generate the OpenAPI spec and the Prisma schema coordinate through a shared internal representation of your data model, so the outputs stay in sync.

The Mermaid Diagrams

8sprint also produces Mermaid diagrams for your README and architecture documentation. The ER diagram for this project:

erDiagram
    Organization {
        uuid id PK
        string name
        string slug
        datetime createdAt
    }
    OrganizationMember {
        uuid id PK
        uuid organizationId FK
        uuid userId FK
        enum role
    }
    Campaign {
        uuid id PK
        uuid organizationId FK
        string name
        enum status
        date startDate
        date endDate
        decimal budget
    }
    AdGroup {
        uuid id PK
        uuid campaignId FK
        string name
        boolean active
    }
    Ad {
        uuid id PK
        uuid adGroupId FK
        string creativeUrl
        json targetingParams
        json performanceMetrics
    }
    AuditLog {
        uuid id PK
        string entityType
        uuid entityId
        string action
        uuid actorId
        json changes
    }

    Organization ||--o{ OrganizationMember : "has"
    Organization ||--o{ Campaign : "runs"
    Campaign ||--o{ AdGroup : "contains"
    AdGroup ||--o{ Ad : "contains"

This renders directly in GitHub READMEs and any tool that supports Mermaid — Notion, Confluence, GitLab, and most modern documentation platforms.

Beyond the ER diagram, 8sprint generates sequence diagrams for key flows. Here's the campaign status transition flow:

sequenceDiagram
    actor Client
    participant API
    participant DB
    participant AuditService

    Client->>API: PATCH /campaigns/{id} {status: "active"}
    API->>API: Validate role (admin+)
    API->>DB: Check campaign exists and belongs to org
    DB-->>API: Campaign record
    API->>DB: UPDATE campaign SET status = 'active'
    DB-->>API: Updated campaign
    API->>AuditService: Log(entityType: campaign, action: status_changed)
    AuditService->>DB: INSERT audit_log
    API-->>Client: 200 OK {campaign}

The Full Package

Beyond these three core artifacts, 8sprint also generates:

README.md — project overview, setup instructions, environment variables
API Guide — authentication flow, pagination conventions, error format
Data Dictionary — definitions for every field in the schema
Error Catalog — all error codes and their meanings
Deployment Checklist — environment setup, database migration steps

All of this from one prompt, in under 3 minutes.

Why Synchronized Outputs Matter

The real value isn't the individual artifacts — it's that they start synchronized. When an OpenAPI spec and a Prisma schema are written by different people at different times, mismatches are inevitable: a field that's required in the spec is nullable in the database, an enum value that exists in the schema doesn't appear in the API response, a foreign key that should cascade doesn't.

Starting from a single generated source means these inconsistencies are caught before a line of application code is written. You still need to review the outputs — the AI can misinterpret requirements, and you know your project better than any model does. But the baseline is coherent, and reviewing a coherent baseline is much faster than reconciling three independently authored documents.

Try 8sprint on Your Next Project

Free tier: 3 generations per month. No credit card required. Pro ($39/mo) for unlimited generations. Team ($99/mo) for collaborative workspaces.

Generate your architecture package at 8sprint.com →

Describe your project in plain English. Get OpenAPI 3.1, Prisma schema, Mermaid diagrams, and 15+ docs in under 3 minutes.

8sprint is an AI documentation platform in open beta. Feedback from real projects directly shapes development priorities.

Why Your API Documentation Is Always Out of Date (and How to Fix It)

Nana Tech — Fri, 24 Apr 2026 05:53:30 +0000

Here's a scenario that plays out on engineering teams every day.

A developer is onboarding to a new project. They find the API docs and start building. Two days later, they open a pull request and get a comment: "That endpoint was deprecated three months ago. We use /v2/users/me now." The docs weren't wrong when they were written. They just weren't maintained.

This isn't a process failure. It's a structural one. Documentation written after code exists in a different place, in a different format, maintained by different people, with different incentives. Of course it drifts.

The Root Cause: Documentation Is Treated as a Deliverable, Not a Constraint

Most teams think of documentation as something you write at the end of a feature — after the code is merged, after QA is done, when someone has a moment. That sequencing guarantees the docs will lag reality.

The alternative isn't to demand developers write better docs in their free time. It's to make documentation a first-class artifact that precedes implementation — not a postscript to it.

The tool that enables this for APIs is the OpenAPI Specification. An OpenAPI spec is machine-readable, version-controllable, and the single source of truth for your API contract. When it lives in your repo alongside your code, it gets reviewed in pull requests. Linters flag when implementation diverges from spec. Mock servers let frontend teams build against the spec before the backend ships.

But here's the problem: writing OpenAPI specs by hand is tedious enough that most teams skip it — or write a minimal version and never expand it.

Why OpenAPI Specs Stay Incomplete

OpenAPI 3.1 is comprehensive. That's part of the problem. A production-quality spec needs:

Complete schema definitions with proper types, formats, and constraints
All response variants: success, validation errors, auth errors, rate limits
Security scheme definitions
Parameter documentation for query, path, and header values
Pagination patterns
Clear operationId naming for code generation

Writing this for a moderately complex API with 20+ endpoints can take a full day. And that day isn't available at the start of a project, when architecture decisions are still being made. So teams write a skeleton spec, or use something like Swagger annotations inline in code (which creates coupling and is equally hard to keep current), or skip it entirely.

The Spec Generator Approach

A newer approach uses AI to generate an OpenAPI spec directly from a plain-English description of what an API should do. Instead of translating requirements → code → annotations → spec, you go directly from requirements → spec → code.

Here's what that looks like in practice with 8sprint:

You describe your API in a paragraph or two:

"I need an e-commerce API with products, categories, orders, and customers. Products belong to categories. Orders have line items and status tracking (pending, confirmed, shipped, delivered, cancelled). Customers have addresses. I need filtering and sorting on the product list, and authentication for the order and customer endpoints."

8sprint routes this through specialized AI agents and produces a complete OpenAPI 3.1 spec in under 3 minutes. Here's part of the orders section:

paths:
  /orders:
    post:
      operationId: createOrder
      summary: Create a new order
      security:
        - bearerAuth: []
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [customerId, lineItems]
              properties:
                customerId:
                  type: string
                  format: uuid
                lineItems:
                  type: array
                  minItems: 1
                  items:
                    type: object
                    required: [productId, quantity]
                    properties:
                      productId:
                        type: string
                        format: uuid
                      quantity:
                        type: integer
                        minimum: 1
      responses:
        '201':
          description: Order created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Order'
        '400':
          description: Validation error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ValidationError'
        '401':
          description: Unauthorized
        '422':
          description: Business rule violation (e.g., product out of stock)

This level of detail — validation rules, multiple response codes, proper schema references — takes experience and discipline to write manually. The AI generates it as a baseline you can review and adjust.

How This Fixes the Documentation Drift Problem

When you start with a generated spec and treat it as the source of truth:

Implementation follows the spec, not the other way around. Backend developers implement what the spec defines. Frontend developers mock against it. Both sides know what to expect.

The spec lives in version control. Changes to the API require changes to the spec — reviewed in pull requests like any other code change.

Tooling enforces the contract. Libraries like openapi-enforcer, dredd, or Prism can run contract tests in CI, failing a build if the implementation diverges from the spec.

Onboarding uses accurate documentation. Because the spec was accurate at implementation time and maintained through review, new developers start with a reliable reference.

The Practical Starting Point

You don't need to overhaul your entire development process to benefit from this. The practical starting point:

Use a tool like 8sprint to generate a spec from your project description
Review it for correctness — adjust any details the AI misunderstood
Commit it to your repository as the starting point for implementation
Add a linter (like redocly lint or spectral) to your CI pipeline to catch spec regressions

The spec won't stay perfect automatically. But it starts from a better position than "we'll document this later," and review tooling makes drift visible instead of invisible.

Start with a Spec, Not a Wish

Documentation isn't out of date because developers are lazy or disorganized. It's out of date because it's written after the fact, in a format that's separate from the code, with no automated enforcement keeping it honest.

Starting with an OpenAPI spec — generated from your requirements before you write a line of implementation — inverts the problem. Documentation becomes a constraint that the implementation must satisfy, not a record of what the implementation happened to do.

Generate your OpenAPI spec from a description at 8sprint.com →

Free tier: 3 generations/month. No credit card required.

8sprint is an AI documentation platform that generates OpenAPI 3.1 specs, Prisma schemas, architecture diagrams, and 15+ supporting docs from a plain-English project description.

From Idea to OpenAPI Spec in 3 Minutes with 8sprint

Nana Tech — Fri, 24 Apr 2026 05:53:20 +0000

You have an idea for an API. Maybe it's a SaaS backend, a microservice, or an internal tool. The idea is clear in your head, but turning it into a proper OpenAPI spec — the kind that actually ships with your project — takes hours. You have to think through every endpoint, every request body, every response schema, every status code.

What if you could skip that grunt work?

8sprint is an AI documentation platform that takes your project idea and produces a complete, production-ready architecture package — including an OpenAPI 3.1 spec, Prisma schema, Mermaid diagrams, and over 15 markdown docs — in under 3 minutes.

Here's how it works.

Step 1: Describe Your Project in Plain English

Start at 8sprint.com and describe your project. You don't need formal language, bullet points, or an outline. Just write what you'd tell a senior engineer in a 5-minute Slack message.

Here's an example prompt:

"Build a project management API with users, teams, projects, and tasks. Users can belong to multiple teams. Teams own projects. Projects contain tasks with status (todo, in_progress, done), due dates, and assignees. I need JWT auth, pagination on list endpoints, and role-based access for team admins vs members."

That's it. Hit generate.

Step 2: 8 Specialized AI Agents Get to Work

8sprint routes your description through 8 specialized agents — each responsible for a different piece of your architecture:

Requirements Extractor — parses your description and builds a structured model of resources, relationships, and constraints
Tech Stack Validator — identifies your target stack and validates compatibility of the proposed architecture
Architecture Designer — maps out resource relationships, endpoint surface, and system boundaries
Schema & API Generator — writes the full OpenAPI 3.1 spec with schemas, paths, and security definitions, and produces the Prisma schema
Documentation Writer — generates README, API guide, data dictionary, and 12+ supporting docs
Quality Assurance — validates consistency and correctness across all outputs
GitHub Repository Creator — packages all artifacts and pushes them to a new GitHub repository
UX/UI Design Advisor — identifies frontend considerations and surface-area recommendations

Step 3: Review Your Generated OpenAPI Spec

Within 3 minutes, 8sprint delivers a complete OpenAPI 3.1 spec. Here's a condensed excerpt from the project management example above:

openapi: 3.1.0
info:
  title: Project Management API
  version: 1.0.0
  description: Team-based project and task management with role-based access control

servers:
  - url: https://api.yourapp.com/v1

security:
  - bearerAuth: []

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

  schemas:
    Task:
      type: object
      required: [id, title, status, projectId]
      properties:
        id:
          type: string
          format: uuid
        title:
          type: string
          maxLength: 255
        status:
          type: string
          enum: [todo, in_progress, done]
        dueDate:
          type: [string, "null"]
          format: date-time
        assigneeId:
          type: [string, "null"]
          format: uuid
        projectId:
          type: string
          format: uuid
        createdAt:
          type: string
          format: date-time

paths:
  /tasks:
    get:
      summary: List tasks
      parameters:
        - name: projectId
          in: query
          required: true
          schema:
            type: string
            format: uuid
        - name: status
          in: query
          schema:
            type: string
            enum: [todo, in_progress, done]
        - name: page
          in: query
          schema:
            type: integer
            default: 1
        - name: limit
          in: query
          schema:
            type: integer
            default: 20
            maximum: 100
      responses:
        '200':
          description: Paginated task list
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: array
                    items:
                      $ref: '#/components/schemas/Task'
                  meta:
                    type: object
                    properties:
                      total:
                        type: integer
                      page:
                        type: integer
                      limit:
                        type: integer

This is valid OpenAPI 3.1 — note the type: [string, "null"] union syntax for nullable fields, which replaced the nullable: true keyword from OpenAPI 3.0. You can load this straight into Swagger UI, Redoc, or Stoplight — or feed it directly into code generators.

Step 4: Get the Full Architecture Package

The OpenAPI spec is just one artifact. 8sprint also delivers:

Prisma schema — with correct @relation annotations, cascade rules, and indexed foreign keys
Mermaid ER diagram — showing entity relationships for your README
Mermaid sequence diagrams — for key flows like auth, task creation, and role checks
15+ markdown docs — including a data dictionary, API guide, environment variables reference, error catalog, and deployment checklist

Step 5: Push to GitHub in One Click

The GitHub Repository Creator agent packages all artifacts — spec, schema, diagrams, and docs — and pushes them to a new GitHub repository. Your project starts with documentation already in place, not as an afterthought.

Why This Matters for AI API Documentation

The traditional workflow looks like this: build → document → realize the docs are already stale → abandon. The 8sprint workflow flips it: describe → document → build.

Starting with a solid OpenAPI spec means your team can:

Generate mock servers immediately with tools like Prism
Start frontend or client development before the backend is built
Run contract tests from day one
Onboard new engineers with accurate, structured reference material

Try It Free

8sprint's free tier lets you run 3 generations per month at no cost — enough to validate the workflow on a real project. Pro ($39/mo) gives you unlimited generations and priority processing. Team ($99/mo) adds collaboration features.

Generate your OpenAPI spec now at 8sprint.com →

No credit card required. No YAML expertise needed. Just describe what you're building.

8sprint is an AI documentation platform in open beta. The tool is actively developed — feedback from real projects shapes the roadmap.