
The Software Partner
Serious Brands Trust
I'm Will Kode — full-stack since 1997, 20+ years building production apps, and 15+ years in marketing. I architect, audit, secure, and ship AI-first software on whatever stack fits your business — the kind that survives real users.
Base44 App Migration
Migrations start at $199 $2,000
We rebuilt our Base44 backend and automated the migration pipeline. Apps under 100 pages and backend functions migrate for a flat $199 — quoted instantly.
Latest Videos
Watch and learn.
Live builds, tutorials, and breakdowns from the channel.
Done-for-you expert services
From building your app to migrating, securing, and maintaining it — pick the help you need.
Explore the KodeBase library
Guides, copy-paste prompts, and video walkthroughs to help you plan and ship faster.
Latest articles
Battle-tested prompts

Find Dead Code, Broken Functions & Half-Built Features
Clean up your codebase by auditing unused components, broken references, and incomplete features with this comprehensive AI diagnostic prompt.
Perform a full Dead Code, Broken Functionality & Incomplete Feature Audit of this application. Do not modify any code yet. Your job is to inspect the existing application and produce a detailed report identifying code, features, components, functions, and UI elements that appear unused, broken, incomplete, duplicated, abandoned, or incorrectly connected. 1. Dead Code Identify: Unused components Unused functions Unused hooks Unused variables Unused imports Unused API calls Unused database queries Unused routes Unused pages Unused styles Unused utilities Files that are no longer referenced anywhere Legacy code left behind after previous changes Do not assume something is dead simply because you cannot immediately find a reference. Trace dependencies before marking anything for removal. 2. Broken References Find references to: Missing components Missing functions Missing files Missing routes Missing database entities Renamed fields Deleted properties Invalid imports Invalid exports Undefined variables Outdated API endpoints Functions calling resources that no longer exist Explain exactly where each broken reference occurs and what it appears to expect. 3. Half-Built Features Look for features where the UI exists but the functionality underneath appears incomplete. Examples: Buttons with no meaningful action Forms that do not save data Settings that are displayed but not persisted Search/filter controls that do not affect results Empty event handlers Placeholder functions Hard-coded temporary data Mock data still being used Features that only partially update the database UI elements referencing functionality that was never implemented 4. TODO / FIXME / Temporary Code Search the entire codebase for: TODO FIXME TEMP HACK placeholder coming soon mock test data temporary workarounds Determine whether each one represents unfinished production work. 5. Duplicate or Conflicting Logic Identify places where multiple pieces of code appear to perform the same responsibility. Examples: Duplicate utility functions Multiple versions of the same component Repeated API wrappers Different validation rules for the same data Duplicate database operations Old and new implementations running simultaneously Explain which version appears to be actively used. Do not recommend deleting anything until dependencies are confirmed. 6. User Flow Audit Trace the application's major user flows from beginning to end. For each major flow, verify: UI → Event → Business Logic → API/Backend → Database → Response → UI Update Identify anywhere that chain appears incomplete or broken. 7. Error Handling Identify important operations that: Have no error handling Fail silently Swallow exceptions Display no feedback to the user Leave loading states active Allow duplicate submissions Do not handle failed network requests 8. Produce a Report Do not make changes. Return a report using this format: Executive Summary Overall condition of the application. Critical Issues Problems likely to break functionality or cause incorrect application behavior. Broken Features Features that appear partially or completely nonfunctional. Half-Built Features Features that appear unfinished. Broken References Missing files, functions, fields, routes, APIs, or dependencies. Dead Code Candidates Code that appears unused. For every item include: File/path Component/function Why it appears unused What references were checked Risk of removal: Low / Medium / High Duplicate Logic Potential duplicate or conflicting implementations. TODO / Temporary Code Remaining development artifacts. Missing Error Handling Operations that could fail without proper handling. Recommended Cleanup Order Provide a numbered remediation sequence based on: Production-breaking problems Data integrity risks Broken user flows Incomplete features Duplicate logic Dead code cleanup IMPORTANT RULES Do not delete anything. Do not refactor anything. Do not change application behavior. Do not assume unused means safe to remove. Trace dependencies before classifying code as dead. Clearly separate confirmed problems from suspected problems. If you cannot verify something, mark it as Needs Manual Verification. The goal of this audit is to determine: What is broken, what was never finished, what is no longer being used, and what needs attention before we keep adding more code.

Base44 Legacy API Key Audit (October 15, 2026 Deadline)
Base44 is retiring legacy api_key authentication on October 15, 2026. Run this read-only audit prompt to find every place your app still uses the old header before it breaks.
Perform a complete, read-only authentication audit of this Base44 application. ## Objective Identify every location that still uses Base44's legacy API-key authentication system: ```http api_key: YOUR_API_KEY ``` These calls must migrate to: ```http Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN ``` Do not modify any code, secrets, functions, workflows, or configuration. Generate a report only. ## Scope Scan the entire accessible application, including: * Frontend source files * Backend functions * Shared API clients and request utilities * Automations and scheduled jobs * Workflows and event handlers * Webhook handlers * Server, API, worker, and edge-function directories * Scripts and migration utilities * Environment-variable references * Secret names and configuration files * Axios instances and interceptors * `fetch()` requests * SDK client initialization * cURL commands stored in scripts * Documentation containing executable examples * Any available logs showing API-key activity Do not limit the audit to files currently imported by the frontend. Include backend-only and scheduled code. Exclude generated directories such as `node_modules`, `dist`, and build output unless the application actively references a generated file at runtime. ## Search Patterns Search case-insensitively for: * `api_key` * `api-key` * `x-api-key` * `BASE44_API_KEY` * `B44_API_KEY` * `APP_API_KEY` * `ACCOUNT_API_KEY` * `appApiKey` * `accountApiKey` * `apiKey` * `headers.api_key` * `headers["api_key"]` * `headers['api_key']` * Axios default headers containing API keys * API client constructors receiving an API key * Environment or secret values passed into request headers * Requests made to `app.base44.com` * Requests made to Base44 API endpoints * Shared request helpers that could add the old header indirectly Trace variables back to their source. For example, if a request uses `headers: authHeaders`, inspect where `authHeaders` is created. ## Accuracy Requirements Only classify something as confirmed legacy Base44 authentication when the old header or credential is connected to a Base44 request. Do not confuse Base44 authentication with API keys for: * OpenAI * Stripe * Resend * Cloudflare * Google * Twilio * Airtable * Other external services Place ambiguous results in a separate "Manual Review Required" section. Do not classify normal Base44 user authentication, session tokens, `base44.auth`, or third-party bearer tokens as legacy authentication unless they ultimately depend on an old Base44 account or app API key. ## Security Requirements * Never print or expose a complete API key, token, or secret. * Replace discovered credential values with `[REDACTED]`. * Report secret and environment-variable names only. * Do not move secrets into frontend code. * Do not create a personal access token. * Do not delete, rotate, disable, or replace any existing credential. * Do not make code changes. ## Required Report ### 1. Executive Summary Provide: * Overall status: `Legacy`, `Mixed`, `Migrated`, `No Legacy Usage Found`, or `Inconclusive` * Number of confirmed legacy authentication locations * Number of unique shared authentication helpers * Number of affected functions, workflows, or integrations * Number of locations already using bearer-token authentication * Number of ambiguous locations requiring manual review * Overall risk: Critical, High, Medium, or Low * Expected impact if nothing is changed before October 15, 2026 ### 2. Confirmed Legacy Authentication Create a table with: | Severity | File and Line | Function/Component | Base44 Endpoint | Old Authentication Evidence | Secret Reference | Trigger | Feature Affected | Confidence | | -------- | ------------- | ------------------ | --------------- | --------------------------- | ---------------- | ------- | ---------------- | ---------- | For every result: * Provide the exact file path and line number. * Identify the function, component, workflow, or script. * Show only the relevant code snippet. * Redact all credential values. * Explain when the code runs. * Explain what user-facing or business feature would stop working. * Identify whether the authentication comes from a shared helper. * Assign a confidence level of Confirmed, Likely, or Possible. ### 3. Dependency and Blast-Radius Analysis Determine whether multiple features depend on: * The same legacy secret * The same request helper * The same Axios instance * The same backend function * The same account-level API key Explain which features could fail together if that shared credential is removed or expires. ### 4. Already Migrated Locations List requests already using: ```http Authorization: Bearer ... ``` Only include them when they authenticate requests to Base44. For each location, report: * File and line * Function or integration * Token secret name * Token scope if visible * Whether the token appears to be stored server-side * Any security concerns Do not reveal token values. ### 5. Manual Review Required List anything that cannot be inspected directly, including: * Make scenarios * Zapier workflows * n8n workflows * Cloudflare Workers * Vercel or Netlify functions * External servers * GitHub Actions * Local scripts * Mobile application backends * MCP configurations * Third-party cron services * External environment variables * Integrations configured outside this Base44 application For each item, explain exactly what a human should check. ### 6. Migration Recommendations For each confirmed legacy location, recommend: * The file or external system that needs updating * The header that must be replaced * The minimum required token access * Whether read-only or full access is required * Whether the token should be restricted to one app * Which workflows must be tested afterward The expected change is: ```http # Old api_key: YOUR_API_KEY # New Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN ``` Do not implement this change. ### 7. Prioritized Action Plan Organize the findings into: 1. Critical production flows 2. Shared authentication utilities 3. Scheduled jobs and automations 4. External integrations 5. Internal or development scripts 6. Low-risk or unused code Recommend migrating shared authentication utilities first when doing so safely updates multiple confirmed callers. ### 8. Testing Checklist Create a checklist covering every affected flow, including: * Read requests * Create and update operations * Deletes * Backend function calls * Webhook processing * Scheduled jobs * Data synchronization * Admin operations * External dashboards * Error monitoring for `401` and `403` responses ## Final Verification At the end of the report, state: * Which directories and systems were inspected * Which areas could not be inspected * Whether any findings remain uncertain * Whether any code or configuration was changed Do not claim the application is fully migrated when external systems or inaccessible configuration could still be using the legacy key.

Base44 SEO Setup Prompt Using react-helmet-async
Elevate your Base44 app's SEO with a comprehensive setup using react-helmet-async.
Scan my entire Base44 app and improve the SEO setup using react-helmet-async. Do not change my app's core functionality, routes, data logic, forms, auth logic, permissions, styling system, or business workflows. Your job is to add or improve SEO metadata across the app. First, scan the full app and identify: - All public pages - All private/authenticated pages - Current routing structure - Existing title tags - Existing meta descriptions - Existing social sharing metadata - Existing Open Graph tags - Existing Twitter/X card tags - Existing canonical tags - Any pages missing SEO metadata - Any duplicated titles or descriptions - Any pages that should be marked noindex - Any dynamic pages that need dynamic SEO values Then install and configure react-helmet-async if it is not already installed. Set up the app correctly by: - Importing HelmetProvider - Wrapping the app with HelmetProvider at the correct root level - Creating a reusable SEO component - Making the SEO component easy to use on every page - Keeping the implementation clean and maintainable Create a reusable SEO component that supports: - Page title - Meta description - Canonical URL - Open Graph title - Open Graph description - Open Graph image - Open Graph type - Twitter/X card title - Twitter/X card description - Twitter/X image - Noindex option - Structured data support when needed Then update every public-facing page with unique SEO metadata. For each public page, add: - A unique page title - A clear meta description - Open Graph tags - Twitter/X card tags - Canonical URL - Relevant noindex settings if needed Important rules: - Do not add SEO metadata to private dashboard pages unless needed. - Mark private app pages, admin pages, account pages, login pages, checkout pages, and user-specific pages as noindex when appropriate. - Do not create duplicate titles across important public pages. - Do not use generic descriptions. - Do not stuff keywords. - Keep titles under 60 characters when possible. - Keep descriptions around 140–160 characters when possible. - Use natural, conversion-focused SEO copy. - Make sure social previews look clean when shared. Also check for: - Missing alt text on important images - Weak heading structure - Pages with more than one H1 - Pages with no H1 - Public pages with poor content hierarchy - Broken or empty meta values - Hardcoded placeholder SEO text - Pages that should have stronger keyword targeting After implementation, give me a final SEO report that includes: - Pages updated - SEO metadata added per page - Pages marked noindex - Any SEO issues found - Any SEO issues fixed - Any SEO issues that still need manual review - Recommendations for future SEO improvements Remember: This is an SEO implementation task only. Do not redesign the app. Do not change app functionality. Do not change user flows. Do not modify permissions. Do not remove content. Do not rewrite entire pages unless it is required only for proper headings or SEO structure.
Expert playbooks, on demand
The complete prompt ecosystem
From a free library to ordered build packs and a curated vault — the right prompt for every step.
Built for people using AI to build real software
Base44 Builders
Plan your entities, roles, pages, permissions, and prompts before burning credits.
Vibe Coders
Turn your rough idea into a structured build plan AI can actually follow.
Founders
Validate your app structure before spending time or money building the wrong thing.
Agencies
Create client-ready app plans, scopes, and build prompts in minutes instead of days.
Freelancers
Look more professional, quote better, and build with fewer revisions.
"I stopped asking Base44 to guess what I wanted. Now I give it structured prompts from Kode Architect and the builds are cleaner from the start."
Marcus T.
Base44 Builder
"The permission planning alone saved me from shipping an app that exposed customer data."
Priya R.
Startup Founder
"I used to waste credits fixing the same bugs over and over. Now I architect first, then build."
Devon K.
Agency Owner
Frequently asked questions
Everything you need to know about audits, services, and building with structure.
Still have a question?
Get in touch →Need your app built for you?
I'll build it, start to finish.
Custom app development for founders and businesses who want it done right the first time — clean architecture, secure data rules, payments, integrations, and a launch-ready build. You bring the idea, I handle the engineering.
Free scoping call · Fixed-price quote before any work starts

















