DEV Community: APIBuilderHQ

The Real Breakthrough in AI Coding Isn't Better Prompts — It's Better Context Files

APIBuilderHQ — Wed, 15 Apr 2026 21:06:23 +0000

The AI changed the wrong file again.

I asked it to update a documentation file. It updated the documentation file and silently modified a component in a completely different directory. I only caught it because something looked different in the browser. By the time I traced it back, I'd already accepted the changes.

This wasn't a prompting problem. I'd written a clear, specific prompt. The AI followed the instruction — it just also did something I didn't ask for. And the reason it did that was because it didn't have enough context about which files it should and shouldn't touch.

That incident is what made me build a persistent context system: three files that give the AI a complete, accurate picture of the project before I write a single prompt.

The Three Files

1. `.cursorrules` — Global Rules for Every Session

This file lives in the project root and loads automatically in every Cursor session. It contains constraints the AI must follow regardless of what I ask it to do.

Here's what mine actually looks like (trimmed):

## Tech Stack — LOCKED. Do not change or upgrade.
- Next.js 16.1.6 (App Router only — never Pages Router)
- React 19.2.3 with React Compiler enabled
- TypeScript strict mode — NO any types, ever
- Tailwind CSS v4 only — NO tailwind.config.js

## TypeScript Rules — CRITICAL
- Strict mode is ON — every variable, parameter, and return type must be explicitly typed
- No any types — use unknown, proper interfaces, or type narrowing instead
- catch (error) blocks must type-check error as unknown

## React Rules — CRITICAL
- React Compiler is enabled — NEVER use useMemo or useCallback

## File Structure Rules
- Four backend routes exist: generate, checkout, verify, portal
  — do not add more without explicit approval
- No new files or components unless explicitly requested

## What Must Never Be Changed
- Core request execution logic (handleSendRequest)
- JWT verification logic in generate/route.ts
- localStorage keys: apibuilder_pro_token, apiBuilderSavedRequests

The key insight: these aren't preferences. They're constraints that prevent the AI from making decisions I've already made. Without this file, every session starts from scratch. The AI might decide to add useMemo because that's what it learned from training data. It might create a tailwind.config.js because that's how Tailwind v3 worked. It might add a new API route when I only asked it to modify an existing one.

The .cursorrules file turns "don't do that" conversations into rules the AI follows before I say anything.

2. `CONTEXT.md` — Architectural Context per Session

This is the file I paste at the start of every Cursor session. It gives the AI a snapshot of the project's current state — what's built, what the architecture looks like, and how the pieces connect.

The structure:

## What This Project Is
[One paragraph: what it does, who it's for, how it makes money]

## Tech Stack
[Specific versions, specific patterns, specific constraints]

## File Structure
app/
├── api/generate/route.ts  ← AI generation endpoint
├── api/checkout/route.ts  ← Stripe Checkout
├── builder/page.tsx       ← Main app UI
├── page.tsx               ← Landing page
└── layout.tsx

## Current State
[What's been built, what each major component does,
 what state variables exist, what the data flow looks like]

## Key Constraints
[What not to do, what not to change, what's off limits]

This prevents the most expensive category of AI mistakes: wrong assumptions. Without this file, the AI guesses at your architecture. It might assume you're using the Pages Router when you're on App Router. It might assume you have a database when everything is in localStorage. It might assume page.tsx is the landing page when it's actually at /builder.

Every one of those wrong assumptions produces code that compiles, looks correct, and breaks something subtle.

3. Master Document — Full Project History

This is the longest file and the least frequently referenced. It contains the complete project history: every major decision, every week's progress, every architectural choice and why it was made. I don't paste it into Cursor — it's too long. I paste it into Claude.ai when I need strategic advice or when I'm planning a major feature.

Its purpose is continuity across sessions. AI has no memory between conversations. The master document is the memory. When I start a new Claude.ai session and say "here's where we left off," this document is what I paste.

Why This Works Better Than Better Prompts

The standard advice for AI coding is "write better prompts." Be more specific. Add more detail. Include edge cases. That advice is correct but incomplete.

The problem with relying only on prompts is that you have to remember every constraint, every architectural decision, and every "don't touch this" rule every single time you write a prompt. You will forget. The AI will do something you didn't want. You'll spend 20 minutes figuring out what changed.

Context files move those constraints out of your memory and into the environment. The AI reads them before it reads your prompt. The rules are applied before you have a chance to forget them.

Since setting up this system, the AI has not modified a file I didn't ask it to modify. The TypeScript strict mode errors that plagued my first week disappeared because "no any types" is in the rules file, not in my head. The architecture stays consistent because the AI knows the architecture before I ask it to build anything.

The breakthrough wasn't learning to write better prompts. It was learning to design a better environment for the AI to work in.

This system was developed while building APIBuilderHQ, a browser-based API client shipped in 5 weekends using AI coding tools. The .cursorrules and CONTEXT.md excerpts above are from the real project.

Vercel Silently Blocked Every Deployment — How I Fixed It with a Deploy Hook

APIBuilderHQ — Fri, 10 Apr 2026 21:55:23 +0000

I pushed to GitHub. The build passed. Nothing deployed.

No error in the terminal. No failed build notification in Vercel. No red banner, no warning email, nothing. I checked the Vercel dashboard and my latest commit just wasn't there. The previous deployment was still live, serving old code.

So I pushed again. Same result. Clean build locally, successful push to GitHub, and the live site sitting there unchanged like I hadn't done anything.

This went on for longer than I'd like to admit.

What I Tried That Didn't Work

My first assumption was a caching issue. Vercel's CDN can serve stale content, so I went to Vercel → CDN → Caches → Purge All. Cleared the CDN cache, the ISR cache, the image cache. Forced a new commit:

git commit --allow-empty -m "force: fresh deploy" && git push

Nothing. The deployment simply didn't appear. I tried redeploying from the Vercel dashboard manually — clicked "Redeploy" with "Use existing Build Cache" unchecked. That worked. But the next time I pushed from my terminal, same silence. The push would succeed on GitHub's end. Vercel just wouldn't pick it up.

I spent a full evening convinced the problem was in my Next.js config, then in my branch settings, then in some Vercel webhook I must have broken. None of these were the issue.

The Actual Cause

The problem was a git identity mismatch.

When you connect a GitHub repo to Vercel, Vercel tracks which git identities are authorized to trigger deployments. My Vercel project was originally created under one GitHub identity. But over the course of the project, I'd changed my git username and email — first for privacy reasons, then again when I set up a dedicated dev account. The commits were now coming from an identity Vercel didn't recognize.

Vercel's response to this was completely silent. No "committer does not have contributing access" error surfaced in my terminal. The git push succeeded because GitHub accepted the commit just fine — it's Vercel's deployment trigger that rejected it, and that rejection happened on Vercel's side with no feedback to me.

This is the part that cost me hours: the push worked. The build would have passed. The deployment just never started. There was no signal that anything was wrong unless you went to the Vercel dashboard and noticed the latest deployment was from three pushes ago.

The Fix

The solution is a Vercel Deploy Hook — a URL that triggers a deployment directly, bypassing the git identity check entirely.

To create one: Vercel → your project → Settings → Git → Deploy Hooks. Name it something like main-deploy, point it at your main branch, and save. Vercel gives you a unique URL.

Now instead of relying on Vercel's automatic git-triggered deployments, you trigger it manually:

curl -X POST "https://api.vercel.com/v1/integrations/deploy/your-unique-hook-id"

That's it. The deployment starts immediately, using the latest code on your main branch. It doesn't care what git identity made the commit.

Important: Treat this URL like a secret. Anyone with it can trigger a deployment of your project. Save it somewhere secure — not in your codebase, not in a public doc.

What I Do Now

Every single deployment follows this exact sequence:

# 1. Build locally — must pass with zero errors
npm run build

# 2. Test locally
npm run dev

# 3. Add specific files — never assume they're tracked
git add [specific files]

# 4. Verify files are actually in git
git ls-tree -r HEAD --name-only

# 5. Commit and push
git commit -m "description" && git push

# 6. Trigger Vercel deployment manually
curl -X POST "your-deploy-hook-url"

# 7. Wait 90 seconds, then test on production

Step 4 exists because I also learned — separately and painfully — that files can exist on your local disk but never be committed to git. The build passes locally because the file is there. Vercel 404s because the file isn't in the repo. git ls-tree -r HEAD --name-only shows you exactly what's tracked. If your new file isn't in that list, it's not going to production.

I've run this exact sequence for every deployment since. The deploy hook has never failed. The silence has never returned.

This happened while building APIBuilderHQ, a browser-based API client I shipped in 5 weekends. If you've hit the same Vercel issue, I hope this saves you the evening I lost.

I Built a Zero-Login Postman Alternative in 5 Weeks. My Cofounder Is an AI and I Work Long Shifts.

APIBuilderHQ — Sun, 05 Apr 2026 02:40:42 +0000

I started this because I wanted to know if the hype was real.

Not the AI hype specifically. The whole thing — the idea that someone without a CS degree, without a team, without anyone around them who even knows what Claude.ai is, could build something real on weekends. I work long demanding shifts at a job that has nothing to do with software. My coworkers don't know what an API is. I barely knew what one was when I started.

Five weeks later I have a live product with Stripe payments, a Pro tier, and an AI that generates production-ready API requests from plain English. I'm still not entirely sure what I'd use it for in my day job. But I know the journey was worth it. If you can't learn, you're done.

Why This Exists

One night I needed to test an API endpoint. I opened Postman. It asked me to create an account. Then download a desktop app. Then set up a workspace. Then pick a team plan.

I just wanted to send one POST request.

I thought: somebody should build the version of this that just works when you open it. No download. No login. No workspace wizard. Open a browser tab, describe what you need in plain English, and get a production-ready API call in seconds. Hit send. That's it.

I built it. You can try it right now with zero login at apibuilderhq.com.

I didn't know how to build it. That turned out to matter less than I expected.

Five Weekends

My tools: Claude running inside Cursor, and whatever hours I could carve out between Friday and Sunday. During the week I work. On weekends I build. The AI writes the implementation. I write detailed specifications, review every line, test the output, and own what ships.

The stack is Next.js 16, React 19, TypeScript in strict mode, and Tailwind CSS v4. I chose these because Claude recommended them and the reasoning was sound. I didn't fully understand TypeScript strict mode when I started. I understand it now because the compiler rejected nearly everything I shipped in the first week and I had to learn why.

Week 1 — core request builder. URL input, HTTP method selector, headers, body, send button, formatted JSON response. The first time I sent a real GET request to a test API and watched structured data come back in something I built, the project became real. Everything after that was momentum.

Week 2 — save and collections, persisted to localStorage. This is where the product's identity took shape. No database. No accounts. No server-side storage. Your data lives in your browser and never touches my servers. I made this decision because I didn't know how to build a database layer. It turned out to be the best architectural choice in the entire project. Privacy by default, not by policy.

Week 3 — environments and variable substitution. Define {{API_KEY}} or {{BASE_URL}} once, switch between Dev and Prod instantly, and every URL, header, and body updates automatically. The regex was simple. The state management to sync multiple environments with an editor panel while persisting everything to localStorage was not. The AI generated something that looked correct and had a subtle bug — closing and reopening the panel was the only way to see updated variables after switching environments. I spent an entire Saturday finding it. The fix was three lines. That same week, I asked the AI to update a documentation file and it silently modified a completely different component at the same time. I only caught it because something looked different in the browser. The lesson: AI follows your instructions precisely and sometimes does exactly what you didn't ask for at the same time.

Week 4 — Stripe payments, JWT authentication, and the free tier. The hardest week by far.

The Pro tier at $12/month was straightforward. The free tier was not. I wanted to give 3 AI generations per month without requiring any login at all. The solution uses Upstash Redis to track a SHA-256 hash of a composite fingerprint — IP address, User-Agent, and Accept-Language headers combined. No PII stored. No cookies. No accounts. Just a hash that tells the server this browser has one generation remaining this month.

For Pro users, I built a magic link authentication system so they can restore access on any device — single-use tokens with 15-minute expiry stored in Redis, Stripe subscription verification on every link click, rate limiting to prevent abuse. No passwords. No traditional accounts. Just an email and a secure link.

The AI generation itself knows 50+ real APIs — GitHub, Stripe, OpenAI, Twilio, Slack, Discord, Notion, and dozens more. You type "Create a POST request to Stripe to create a customer" and it builds the full request with the real endpoint, correct headers, proper auth pattern, and {{STRIPE_SECRET_KEY}} placeholder ready for your environment variables. You can try it at apibuilderhq.com — three free generations, no signup.

Week 5 — deployment, custom domain, landing page. Live at apibuilderhq.com. Monthly infrastructure cost: about $23.

What Actually Went Wrong

The sections above make this sound smooth. It was not.

The most instructive failure had nothing to do with code. I'd make changes, run npm run build, get a clean pass, push to GitHub, and nothing would happen. No error. No deployment. Just silence. It took me an embarrassingly long time to realize that Vercel was silently blocking every push because the git commit identity didn't match what it expected. The build was passing. The push was succeeding. The deployment simply wasn't triggering. The fix was creating a deploy hook — a curl command I now run manually after every single push. I still run it today, every time, without exception.

A separate discovery: a typo in an environment variable — apibuildhq.com instead of apibuilderhq.com — was silently redirecting paying customers to a 404 page after checkout. Two missing letters. Hours of debugging.

AI can write code that compiles, type-checks, and passes every lint rule. It cannot tell you that your deployment pipeline is silently broken or that you misspelled your own domain name. The gap between code that works and a product that ships is entirely human.

What I Learned About Building With AI

People want to know if vibe coding is real. Here's what I can say after five weeks.

The AI is excellent at boilerplate, type definitions, consistent patterns, and generating validation logic that would take me hours to write by hand. It catches things I don't know enough to think about — accessibility attributes, error handling patterns TypeScript strict mode requires, edge cases in data parsing.

It is not a replacement for understanding what you're building. Every week had a moment where the AI produced something that looked right and wasn't. Every fix required me to read the code, trace the logic, and figure out why it was wrong. The AI made me faster. It did not make me less responsible.

If you're thinking about building something and you're not sure you're qualified — I wasn't either. The qualification is willingness to sit with confusion until it breaks. It always breaks eventually.

Where It Stands

The product is live. Users: early.

The builder is free. Send requests, save collections, manage environments with variable substitution — no limits, no login, no catch. The Pro tier adds unlimited AI generation for $12/month. If the free version is enough, use it forever. That's by design.

I'm not asking you to support a founder. I'm asking you to try a tool and tell me if it's useful enough to keep open in a tab. The answer might be no. That's useful too.

One Last Thing

I want to test something.

What's the most undocumented, frustrating API you've had to integrate lately? Drop the name below — I want to see if APIBuilderHQ can write the request in one shot.

Built with Next.js 16, React 19, TypeScript strict mode, Tailwind CSS v4, Upstash Redis, Stripe, and Claude in Cursor.

@APIBuilderHQ on X · apibuilderhq.com