Prototype Apps Need Exit Inventory

GitHub's 4 August changelog says GitHub Spark on github.com is being deprecated. New users and new app creation stopped immediately. Existing users can access Spark until 31 August 2026 to export apps they already created. Deployed apps keep running, but future editing moves elsewhere.

The same notice links the shutdown to a second dependency: GitHub Models was retired on 30 July. Spark apps that used the old useModel inferencing path need a replacement provider if their AI features should keep working. Two days later, GitHub added Kimi K3 to Copilot, with gradual rollout, administrator enablement for Business and Enterprise, provider list pricing under usage-based billing, and a recommendation to review open-weight models against security, compliance, and data-governance requirements.

Those are separate product notes, but they form a useful operating pattern for small teams: AI-assisted app creation is getting easier, while the surfaces that created, hosted, edited, billed, and powered those apps can change quickly.

The repeated angle to avoid

The last ten posts here covered Copilot billing handovers, code-quality setup, comment-triggered agents, AI gateway budgets, model entitlements, agent worktrees, stacked pull requests, review-agent context, package-malware controls, and inference-region routing. Older overlapping posts covered AI credit chargeback, model routing, prototype experiment lanes, dependency intake, review environments, and agent audit trails.

The weak version of this article would repeat the old X needs Y pattern: prototypes need governance. That is true and not useful enough. The sharper thesis is that a prototype's exit path is now part of the product design. When the creation surface, inference API, model policy, and billing route can separate after launch, operators need to know which mini apps are disposable experiments and which have quietly become business systems.

Spark is a reminder that creation and ownership are different

AI app builders are attractive because they reduce the distance between idea and working utility. A founder can make a margin calculator. A marketer can make a product-description helper. A local-service operator can make a quote triage form. A developer can make an internal log summariser or schema checker without opening a full product backlog.

That speed is the point. The risk appears later, when the app outlives the tool that created it.

A prototype can become operational through usage, not through ceremony. Nobody has to rename it "production" for it to matter. It only has to become part of a staff routine, customer journey, reporting habit, SEO workflow, onboarding flow, or lead qualification process. Once that happens, the operating question changes from "can this tool make an app?" to "who owns the app if the tool stops editing it?"

Use this distinction:

Prototype role	Example	Exit risk
Throwaway exploration	Testing whether an idea is worth building	Safe to delete if the idea fails
Staff convenience	Internal calculator, summariser, checklist, data cleaner	Work continues, but nobody knows where the source or logs live
Customer-facing utility	Quote helper, product finder, eligibility checker	Users see failures before the team notices the platform dependency
Content or SEO tool	Schema generator, FAQ drafter, redirect checker	Outputs may keep shaping public pages after the model route changes
Operational bridge	Temporary CRM mapper, import tool, webhook tester	Temporary code becomes the hidden path between business systems

The mechanism is simple: the easier it is to create a small app, the easier it is to skip the ownership transfer that normally happens in a planned build.

Inferencing is a separate dependency from the app

The Spark notice is useful because it separates deployed app continuity from AI feature continuity. A deployed app may keep serving. But if the app depended on GitHub Models through useModel, the AI capability needs a new inference provider, API key, billing route, and data-governance review.

That is the trap for operators. A mini app may look "still live" while one of its decision-making parts has lost its provider. Or the team may replace the provider quickly and accidentally change cost, latency, data retention, output style, moderation posture, or regional routing.

For practical web work, treat inferencing as its own runtime dependency:

1. Locate the call path. Search exported code for model hooks, provider clients, environment variables, server routes, and prompt templates.
2. Classify the data. Public content generation is different from customer PII, invoices, uploaded photos, CRM notes, lead values, or support transcripts.
3. Choose the replacement route deliberately. Do not swap providers only because the first example works.
4. Record billing ownership. A staff utility should not silently spend from a developer's personal key.
5. Retest representative cases. Compare outputs on real fixtures, not a happy-path demo prompt.
6. Update the user experience. If AI is unavailable, the app should degrade to a useful manual path rather than fail with a vague provider error.

This connects to recent model-entitlement and gateway-budget posts without repeating them. The new point is narrower: exported prototype code needs an inference migration plan even if the deployment itself survives.

New models make exits less mechanical

Kimi K3 becoming available in Copilot is not directly a Spark migration path. It is still relevant because it shows how fast model catalogs and policy surfaces move. The announcement says Business and Enterprise administrators must enable the Kimi K3 policy before organization members can select it, that the model is billed under usage-based pricing, and that open-weight models deserve security, compliance, and data-governance review.

That means a prototype exit cannot be reduced to "pick the newest model." A coding assistant may help export and refactor the app. A gateway or provider may run the app's AI features. An administrator may need to enable a model for development work. A different billing owner may pay for production inference. Those are four separate decisions.

The failure modes are predictable:

• the exported app works locally because a developer has a personal key, but the business has no production billing owner;
• a model replacement changes the structure of generated copy, breaking downstream formatting or review expectations;
• an internal tool starts sending customer data to a provider route that was only approved for public content;
• an app that was supposed to be temporary keeps running with no dependency updates, monitoring, or owner;
• a prototype built for experimentation becomes a customer promise without accessibility, security, analytics, or fallback checks.

The right response is not to slow every experiment. It is to graduate only the experiments that earn an exit record.

A prototype exit inventory

Use this inventory when an AI-built mini app is exported, migrated, adopted by staff, linked from a website, or used in a revenue workflow.

prototype_exit_inventory:
  app_name: quote-followup-helper
  current_role: staff_convenience | customer_facing | content_tool | operational_bridge | throwaway
  business_surface: local_service_leads
  owner: growth_operations
  source_location: github_repo_or_export_archive
  deployed_url: https://example.com/tool
  creation_surface: github_spark | internal_agent | no_code_builder | other
  edit_path_after_exit: repository_pull_request
  runtime:
    hosting: vercel | cloudflare | github_pages | other
    environment_variables:
      - CRM_API_URL
      - AI_PROVIDER_API_KEY
    logs_location: provider_dashboard_or_log_sink
  inference:
    uses_ai: true
    old_provider: github_models_useModel
    replacement_provider: selected_provider_name
    approved_data_classes:
      - public
      - internal
    blocked_data_classes:
      - payment_data
      - customer_pii_without_consent
    billing_owner: operations
  evidence:
    exported_before_deadline: true
    fixtures_retested:
      - normal_lead
      - spam_lead
      - long_message
      - missing_required_field
    fallback_behavior: deterministic_form_and_human_followup
    rollback_plan: remove_public_link_and_restore_previous_workflow
  review_date: 2026-09-01

This can live in a repository README, issue, spreadsheet, or operations runbook. The format matters less than the join it creates: app, owner, source, runtime, inference, billing, data class, fixtures, and fallback.

A decision rule for graduation

Before a prototype becomes part of the business, apply a simple rule:

If people would notice when the prototype breaks, export it, assign an owner, document the inference route, add a fallback, and retest it like a small production system.

That rule keeps experiments cheap. A disposable prototype can stay disposable. A useful internal tool can remain lightweight. But a customer-facing quote helper, product finder, lead scorer, or content generator should not depend on an editing surface, model API, or billing route that nobody can name.

The practical lesson from Spark's shutdown is not that one product went away. It is that AI app builders compress creation time without automatically creating operational memory. For small teams, the durable artifact is not the demo. It is the exit inventory that lets the useful parts survive after the demo surface moves on.