Is your dev setup dying?

12 questions, 3 minutes. Scores your current build across the four things that actually predict whether a dev engagement survives: code ownership, shipping velocity, quality floor, and communication. No email gate. Nothing to download.

4 categories12 questionsInstant score + fix list

0 / 12

// OWNERSHIP

Do you have admin access to the GitHub/GitLab repo your dev is working in?

Can you log into the hosting account (Vercel / Netlify / AWS / whatever runs the site) yourself?

Where is the domain registered and who owns the registrar account?

Do you have a copy of the production environment variables (API keys, DB connection strings)?

// VELOCITY

When was the last time your dev shipped code you could see or use?

Do you have a written milestone schedule with specific ship dates?

Have quoted timelines slipped more than 50% past original estimates?

// QUALITY

Does the codebase have any automated tests (unit, integration, e2e)?

Is there a README or handoff doc that explains how to run the project locally?

Is there error monitoring on production (Sentry, Vercel logs, Datadog, etc.)?

// COMMUNICATION

How long does it typically take to get a response from your dev during a business day?

Do you get a written weekly (or at least bi-weekly) progress update?

// WHY THESE 12

Every rescue call starts at the same four gaps.

Ownership gaps (repo, hosting, domain, secrets) are why you feel held hostage. If any one of those is locked to your current dev, exit is expensive. Fix these first every time.

Velocity gaps (no ships, no milestones, ETA drift) are why budgets balloon. A real build has a written scope and a merge every week or two. Anything slower is either the wrong scope or the wrong dev.

Quality gaps (no tests, no docs, no error monitoring) are why bugs find your customers before they find you. None of these are optional for a production system. All three cost less than one refund.

Communication gaps (slow response, no updates) are the earliest signal the relationship is already over. The dev knows something is wrong and they're avoiding the conversation. Act early.