The Base44 developer vetting guide.

2. The five-gate framework

Five gates. Each is independent — a candidate must pass all five. Failing any single gate is sufficient cause to reject.

1. Gate 01

   Reps

   Minimum ten base44 apps shipped to production. Not "tutorials completed" or "test apps in the editor." Production apps with live URLs, real users, and at least one platform update survived. Ask for named portfolio links and verify they load.

2. Gate 02

   Pattern coverage

   A documented playbook for each common failure class on the platform. A real specialist names function routing, credit burn, entity access rules, Stripe webhook breakage and AI-agent regression loops in under a minute when prompted. A generalist hedges or asks for the documentation.

3. Gate 03

   Code review

   Every fix is peer-reviewed by a second senior engineer before ship. Sprint output is never single-authored on critical paths (auth, payments, data). Single-engineer freelancers cannot pass this gate; insist on a peer review process or a second pair of eyes.

4. Gate 04

   Written communication

   Every engagement closes with a written summary: what changed, why, what to monitor. Engineers who cannot write a clean three-paragraph technical summary do not pass. Verbal-only handoff is an immediate disqualification on production work.

5. Gate 05

   Bylined accountability

   Named engineer on every engagement letter, with a professional profile you can verify. The engineer who scopes the work is the engineer who ships the work. Bench-and-rotate (engineer-A scopes, undisclosed engineer-B ships) fails this gate.

3. Portfolio review checklist

Spend thirty minutes on every shortlisted candidate's portfolio. Look for these eight signals.

• · Live URLs. The portfolio should include URLs you can load. Screenshots are insufficient — anyone can ship a screenshot.
• · Production traffic indicators. Apps with real users (visible reviews, app-store presence, social proof). A portfolio of internal tools no one else uses is harder to verify.
• · Diversity of use case. Look for at least three different verticals: SaaS, marketplace, internal tool, e-commerce. A portfolio of ten near-identical CRUD apps is a junior tell.
• · Auth and payments. Apps with non-trivial auth flows (SSO, OAuth, multi-tenant) and live payments (Stripe, PayPal). Both are where base44 expertise actually pays off.
• · Date stamps. Recent shipped work (in the last six months). Base44 changes fast; portfolio work from 2024 may not reflect current platform behaviour.
• · Named clients (where consent exists). A few named clients with permission to share. All-anonymised portfolios are not a red flag in themselves but reduce your verification options.
• · Public case studies or write-ups. A senior engineer typically has at least one public technical write-up — a blog post, a Stack Overflow answer, a GitHub repo. Zero public footprint is a junior tell.
• · Migration or rescue work. Bonus: candidates who have rescued a broken base44 app or migrated one off the platform have seen the platform's edges.

For a line-by-line version with pass/fail steps across portfolio, platform knowledge, code samples, references and contract readiness, work through the 32-point Base44 hiring checklist.

4. The twelve technical screening questions

Run these in a thirty-minute screening call. A real specialist answers in under a minute per question with specific platform terminology. A generalist hedges, asks for documentation, or talks about no-code platforms in general.

1. How would you diagnose a base44 backend function returning 404 in production but working in preview?
2. What is the most common cause of credit-burn loops on trivial edits, and how do you stop them?
3. How do you confirm that an entity's access rules stop one signed-in user from reading another user's records on a live app?
4. Describe how Stripe webhook handlers can break after a base44 platform update and how you restore them.
5. Base44 serves search engines and AI crawlers a prerendered version of each page. If a Base44 app still does not show in Google, what do you check first?
6. What causes data-loss when users return to an app, and what is your usual remediation?
7. What rate-limit thresholds have you seen base44 enforce in production, and how do you handle 429 backoff?
8. When would you advise a client to migrate off base44 rather than fix in place?
9. What is your peer-review process on critical-path code (auth, payments, data)?
10. Walk through how you would scope a $1,500 single-bug fix-sprint engagement end-to-end.
11. How do you document a fix so it survives the next platform update?
12. What does your written hand-off deliverable look like? Can you share a redacted example?

Score each question 0-2: 0 = no specific answer, 1 = generic answer, 2 = specific platform-aware answer with concrete example. A passing score is 18+ out of 24. Below 12, reject. 12-17, run a paid trial task before committing.

Question 5 has a checkable answer key. Base44 apps render client-side for visitors, but Base44 serves search engines and AI crawlers a prerendered version of each page — real headings, content, meta tags and structured data — refreshed when you publish (docs.base44.com, read 23 Sep 2026). When a Base44 app still does not show in Google, the cause is usually configuration: the SEO toggle switched off (which disables prerendering), missing per-page meta descriptions, pages behind login or set to noindex, or simply a new domain Google has not crawled yet. A candidate who still calls Base44 apps invisible to search engines is working from an old version of the platform.

For the actual interview question set — a tighter seven-question screening call with green-flag and red-flag answer patterns for each — see How to vet a base44 developer: 7 questions that actually work. That post is the working script we use on first-round screening calls; this page is the full framework around it.

5. The paid trial task

For any engagement over $2,000, run a paid two-hour trial task before committing to the full scope. The trial separates pattern-matchers from generalists more reliably than any conversation.

The brief. Pick a documented base44 issue — a backend function returning 404, credit burn on trivial edits, entity access rules that expose other users' records — and ask the candidate to: (a) describe the root cause in one paragraph, (b) outline a remediation plan in three to five steps, (c) write a regression test plan. Do not ask them to ship code; the trial is about diagnostic and communication quality.

What to score. Specificity (do they name platform behaviours, or talk in generalities?). Causal clarity (do they trace the bug from symptom to root cause, or list possibilities?). Written quality (would you hand this to a board member?). Time discipline (did they deliver inside two hours?). Pay the candidate's normal rate for the two hours.

Never ask for free work. Free-trial requests are an industry red flag and the best engineers will refuse. A paid trial signals that you are a serious buyer and respects their time.

6. The six red flags

• Unwilling to share named portfolio. If they cannot show shipped work in their own name, they probably did not ship it. Walk away.
• Hourly billing with no scope cap. Open-ended hourly is a license to drift. Insist on a fixed scope or a hard cap. "Hourly with weekly check-ins" is not a cap.
• No written deliverable. Verbal-only handoff is unmaintainable. The engagement letter must specify a written summary deliverable.
• Bench-and-rotate. Engineer-A scopes the work, engineer-B (often offshore, often undisclosed) ships it. Common at large generalist agencies. Insist on the named engineer end-to-end.
• Subcontracting offshore without disclosure. Ask explicitly: "Will any other engineer touch this work? If yes, who, and what is their professional profile?" Get the answer in writing.
• Reviews that all sound the same. Marketplace reviews are often coordinated. Look for specific project detail (not generic five-star copy-paste). Three reviews with detail beat thirty without.

These six end a conversation on their own. For contract, pricing and communication tells beyond them, see the twelve walk-away red flags in our hiring series.

7. Rate benchmarks

Use these as a sanity check, not a quote. Every figure carries its source and the date we read it. A rate far below its band can mean a junior profile, undisclosed subcontracting or a cosmetic-only scope; a rate far above it often prices in an open-ended retainer. Neither decides the hire on its own: run the gates.

Base44 developer rates, sourced 23 Sep 2026

The project bands come from Base44's own How much does it cost to make an app. The directory figure is an aggregate of posted rates; we do not name individual partners. Base44Devs terms: Fixed-price by default; hourly only for due-diligence/legal advisory at $300/h (4-hour minimum).

The Base44 developer cost breakdown carries the same sourced bands plus the hidden costs of each route.

8. Reference checks

Spend thirty minutes on references. Two questions matter more than the rest:

1. What did the engineer do when something went wrong? Every engagement has a wobble. The honest reference describes how the candidate handled it. The dishonest reference says "nothing ever went wrong" — which is a tell.
2. Would you hire them again, today, at the same rate? Not "were you happy." The willingness-to-rehire test eliminates polite recommendations.

A candidate who cannot produce two references with verifiable professional profiles is not a candidate. Walk away.

9. Engagement letter checklist

Before any payment, the engagement letter must specify all of the following. If any are missing, the engagement is structurally weak even if the engineer is strong.

• · Named engineer (or named engineers, if peer-reviewed).
• · Fixed scope or capped hourly with a written cap.
• · Written deliverables: code, summary, regression plan.
• · Timeline with milestones.
• · Mutual NDA terms.
• · Money-back or rework clause if the work fails.
• · Subcontracting clause: explicitly named, or explicitly forbidden.
• · Post-ship warranty or support window, stated in days.
• · IP ownership clause.
• · Termination terms.

10. Apply this framework, even to us

We publish this framework because we want it applied to our own engineers. If you are evaluating Base44Devs, run us through every gate, every red flag and both reference questions, and put any of the twelve technical questions to the engineer on the free 15-minute call. Then use the $497 audit as the paid trial task and decide from the written result whether to commit to a sprint, build or migration.

The trial carries two terms. The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. If you ordered the audit for a specific bug and we cannot reproduce it, we refund the fee; otherwise it is non-refundable.