Most AI projects don't stall because the model is hard. They stall because the boring parts were skipped, and then nothing can run anywhere except the author's laptop.

Three files fix most of it.

1. .env.example

Every key, URL and model name your app reads, with placeholder values and a one-line comment each. Commit this. Never commit .env.

Why it matters: it's the difference between "clone and run" and a 40-message support thread about which key goes where.

OPENAI_API_KEY=sk-...          # from platform.openai.com
VECTOR_DB_URL=http://localhost:6333
EMBED_MODEL=text-embedding-3-small

2. docker-compose.yml

Even if you only have one service, pin it. A compose file means a new machine gets the same versions you tested on, instead of whatever pip install resolves today.

services:
  app:
    build: .
    env_file: .env
    ports: ["8000:8000"]
  qdrant:
    image: qdrant/qdrant:v1.12.0   # pinned, not :latest

3. README.md with a "Run it" section

Not a feature list. The literal commands:

cp .env.example .env
docker compose up -d
curl localhost:8000/health   # expect {"ok": true}

If that sequence doesn't work on a clean machine, the project isn't finished — it's just working for you.

---

The pattern behind all three: make the environment reproducible and the entry point obvious. Everything else — evals, monitoring, scaling — builds on that.

What's the one setup step you always forget? For me it's the embedding model name.

If your retrieval-augmented answers feel like they're almost right but never quite land, the model is rarely the problem. The chunks are.

Here's the failure mode, in order of how often I see it:

1. Fixed-size chunking cuts sentences in half.

text[0:500], text[500:1000] — the standard first attempt. It splits mid-thought, so a chunk can end with "the API key should be" and the next chunk starts with "stored in an environment variable." The embedding for chunk 1 is now about the wrong idea.

2. Chunking ignores document structure.

Markdown has headers for a reason — they're the author's own outline. Splitting on ## boundaries keeps each chunk semantically whole, and it's the cheapest quality win available.

3. Chunks are too big to be specific.

A 2,000-token chunk embeds a lot of ideas into one vector. The average of five topics matches nothing well. Smaller, focused chunks retrieve better.

What actually fixes it

• Split on structural boundaries first (headers, then paragraphs), not character counts.

• Keep a small overlap so context survives the boundary.

• Store the header path as metadata so you can filter later ("only from the Deployment section").

• Measure: pull 20 questions you know the answer to, and check whether the right chunk is in the top 3. That number moves fast when chunking improves.

The tool I use for this is md-vector-chunker (Go) — it parses markdown with an AST and splits by header hierarchy, so chunks stay whole. It's in the Developer Toolkit.

What's your current chunk size? If it's a fixed number, that's the first thing I'd change.

I built 5 CLI tools for AI/backend work — here's what each one solves 🔧

I kept rebuilding the same utilities across projects, so I packaged them

properly. Small, focused, each does one job. All Go, Rust and TypeScript,

most with test suites.

1️⃣ md-vector-chunker (Go)

The problem: your RAG answers are vague because chunks cut mid-sentence.

This uses an AST parser to split markdown by header hierarchy instead of

a fixed character count, so each chunk stays semantically whole.

2️⃣ bundle-phobia-cli (Go)

The problem: your JS bundle ballooned and you don't know which dependency

did it.

Checks npm package sizes concurrently, straight from the terminal.

3️⃣ iam-policy-visualizer (Rust)

The problem: nobody on the team can tell who can actually delete the

production database.

Parses AWS IAM JSON and renders the effective blast radius as a Mermaid

diagram. Output diffs cleanly in a PR, unlike a screenshot.

4️⃣ tz-meeting-scheduler (Go)

The problem: someone on the distributed team keeps missing standup.

Converts a meeting time across timezones into a Markdown table you can

paste straight into the invite.

5️⃣ jwt-decoder-extension (TypeScript)

The problem: you need to inspect a token, but pasting it into a random

website is a terrible idea.

Fully offline browser extension. Nothing leaves your machine. It also

refuses to pretend it can verify a signature it has no key for.

---

All five are small enough to read end to end in an evening. The source

is mine, written for my own workflow — not tutorial code.

Requires Go 1.21+, Rust stable, Node 18+.

If you're building anything RAG-related, #1 is the one I'd start with —

it fixed a retrieval quality problem I'd been chasing for weeks.

ShipAI — link in profile if useful 🙏

https://whop.com/shipai-4c05

New site is live — and here's what changed 🚀

Quick update on what's new.

Dedicated website

Everything now lives at shipai-kit.whop.site — every tool documented, all three bundles compared side by side, and a FAQ covering prerequisites, licensing, and refunds.

Every product now has real media

I've added proper coverage images so you can see exactly what's in each tier before buying, instead of guessing from a text list.

The starter kit description was rewritten

The $79 tier now describes only what actually ships. If you read it earlier and thought it promised auth, billing and vector DB integrations — that text was inaccurate and has been corrected. It is six real projects across Go, Rust, TypeScript and Next.js.

Licensing made explicit

All tiers are licensed, not sold. You can use, modify and ship the code in your own commercial projects, including client work. You cannot redistribute the source as a template or competing product. Full wording in the EULA.

---

The bundles

→ Starter Kit — $79

→ Developer Toolkit — $99

→ Complete Bundle — $299

Bought something and have a question? Ask here — priority support is included with the Complete Bundle.