Startups and Scale-ups

Ship the smallest thing that proves the thesis

AI product work sized to runway: the narrowest build that tests the thesis, embedded engineers, and honest build-versus-buy advice.

  • Embedded in your repo
  • Venture building for equity
  • Technical due diligence

Sequencing

The smallest thing that proves the thesis

One workflow, one segment, on a frontier API, with a human in the loop where reliability is not yet earned — shipped in weeks. If the thesis survives, the next build is justified by evidence rather than an architecture diagram.

  • Hosted APIs first; own infrastructure only when forced
  • A written kill criterion agreed before the build
  • We will say when the product needs no model at all

Buy first

What to refuse to build at seed

Buy the model, the vector store, observability and auth, and spend the rest on your product. Fine-tuning is nearly always premature: better prompts and retrieval beat it.

  • hosted models
  • managed vectors
  • prompt first

First build

4–8 weeks

typical time from scope to an AI feature real users are testing

Venture studio

12

AI-native brands GridStudio has built and operated itself

Embedded

Engineers in your team, not beside it

We work in your repository, your standups and your review process, and the code is yours from the first commit. Pairing and a planned exit are part of the engagement.

  • your repo
  • pairing
  • planned exit

Moat

The question asked at Series A

What could a funded competitor not replicate in six weeks? Correction and outcome data has to be instrumented early: it cannot be backfilled once the traffic has passed.

  • eval sets
  • provenance
  • consent
  1. Thesis and kill criteria What must be true, agreed in writing
  2. Narrowest build One workflow, one segment, hosted APIs
  3. Real users Evidence that changes what you do next
  4. Instrumentation Corrections and outcomes captured with consent
  5. Owned infrastructure Only when volume or economics force it
Each step is justified only by what the previous one proved. Most teams build step five first.

Models

  • OpenAI
  • Anthropic Claude
  • Google Gemini
  • Llama
  • Open-weight fine-tunes

Application

  • TypeScript
  • Python
  • Next.js
  • FastAPI
  • Postgres
  • pgvector

Retrieval

  • pgvector
  • Qdrant
  • Hybrid search
  • Rerankers
  • Chunking strategy

Evaluation

  • Langfuse
  • promptfoo
  • Golden sets
  • Regression suites
  • Cost per resolution

Infrastructure

  • Vercel
  • AWS
  • Cloudflare
  • Serverless GPU
  • Managed inference

Three ways in. Stop after any of them.

1–2 weeks

Product and technical review

A hard look at the thesis, the architecture and the unit economics, with a recommendation on what to stop building.

Build-versus-buy recommendation, defensibility analysis, cost-per-resolution model

4–10 weeks

Build sprint

The narrowest version that tests the thesis, shipped to real users in your repository and owned outright by you.

Shipped increment, evaluation set, cost model, data capture instrumentation

Ongoing

Embedded team or venture partnership

Engineers scaled against runway, or a co-founding arrangement where we contribute product and engineering capacity for equity.

Engineering capacity, pairing and documentation, or deal-by-deal equity terms

Questions

Most of the time, at first. If a frontier API meets your latency and quality bar, your volume does not break the economics and your data is not legally trapped, use it and spend the engineering on the product. Fine-tuning and owned GPUs answer specific problems; if you cannot name yours, you do not have one.

You own everything from the first commit — repository, prompts, evaluation sets and weights, with no runtime dependency on us. We also co-found for equity where the fit is right, structured deal by deal with founders keeping control. It is a real commitment, so we decline more often than we accept, and quickly.

If you have strong in-house engineers and a clear thesis, hire another engineer — cheaper, and it compounds. If you are pre-product and changing segment weekly, the constraint is customer conversations, not code. Sometimes the honest answer is a landing page and ten interviews before anything is built.

Bring us the constraint, not the brief

Regulator, budget, deadline, legacy core, a board that has been burned once already. Tell us what you are working around.