# GITP — Get it to production

Product concept, positioning and launch plan for Dennis and his cofounder. Research date: 10 September 2026.

**Recommendation:** position GITP as the production step after building with AI. The user connects GitHub or uploads an app. GITP’s AI investigates the app, identifies what is needed and returns with a report and a phased improvement plan. The user then chooses what to run, pays a fixed package fee plus transparent usage, reviews the changes and tests the delivery. Hosting and management are optional recurring packages.

This document describes the proposed offer. The existing platform was not supplied or technically audited. Three AI research agents contributed product strategy, AppSec/SRE and European cloud/privacy perspectives. No external human experts were contacted. Source-backed claims are linked where used; recommendations and business assumptions are our synthesis.

## 1. The refined brief

Create a clear, credible English website for a global audience of founders, agencies/freelancers and organizations with an AI-built app. Explain the problem after the demo works, the automatic assessment, the improvements a customer can buy, the evidence delivered and the optional route to hosting and management.

The site should answer five questions quickly:

1. Is this for an app like mine?
2. What do I need to do to start?
3. What will your AI investigate and return?
4. What do I receive after an improvement, and how can I verify it?
5. What is fixed-price, what is usage-based and how is spending controlled?

The name is **GITP — Get it to production**. English is the default website language; all three customer groups are represented.

## 2. The customer experience

**Connect → AI investigates → report and plan → choose packages → AI improves → review and test → launch → optional hosting and management.**

The customer does not prepare a technical brief, identify the stack, diagnose problems or choose an assessment scope. Automatic discovery is an internal part of the work. Before a paid scan starts, the interface shows the published package fee, usage rates and budget; that is a purchase decision, not a technical intake.

AI investigates the available code, architecture, visible features, dependencies, integrations and existing tests. It distinguishes evidence from inference. Inaccessible services, unsupported components and unknown business rules remain visible. Only where essential information cannot be established does the system return with a focused question. Source access alone cannot reveal every intended business rule, production configuration or third-party account setting.

### Core website promise

> You built it. Let’s get it to production.
>
> Connect GitHub or upload your app. Our AI works out what it needs for production and gives you a clear plan. Choose what we improve, review the changes and try the result.

A “vibe-coded app” here means an app largely created by describing desired behavior to AI, trying the result and refining it through further prompts. Examples include customer portals, booking apps and internal tools. Lovable, Bolt, Replit and coding assistants such as Cursor are recognizable examples of building tools. They are not guaranteed integrations or endorsements. [Bolt](https://bolt.new/), [Cursor](https://cursor.com/)

## 3. One promise for three audiences

| Audience | Recognizable moment | Desired outcome | What matters commercially |
|---|---|---|---|
| Founders and small teams | “I’m ready for my first real customers.” | Clear priorities and a dependable first release | Understandable evidence and predictable spending |
| Agencies and freelancers | “I want to hand this over with confidence.” | Tests, review and a transferable delivery | Repeatable quality checks across client projects |
| Organizations | “This prototype deserves a place in our business.” | Answers about access, data, continuity and responsibility | An informed decision about adoption and operation |

Market to all three as requested. Operationally, begin with a well-supported stack shared by suitable pilot apps. Select it after examining the existing platform and actual incoming projects. A TypeScript web app with a known backend/database combination is one candidate, not a validated compatibility claim.

Have automatic discovery flag unsupported technology or applications requiring specialist review. The customer should not have to classify the architecture first. Safety-critical systems, heavily regulated uses and major migrations require a separate decision before execution.

## 4. Where GITP can stand out

A generic AI code scanner is a weak differentiator. Lovable already offers Basic and Deep security scans, remediation options and third-party security integrations. Its documentation also states that scans cannot guarantee complete security. [Lovable security](https://docs.lovable.dev/features/security)

Replit describes a Security Agent that examines architecture, creates a threat model, reports findings and prepares remediation changes for review. [Replit Security Agent](https://replit.com/blog/meet-replit-security-agent)

Preview environments are established functionality too: Vercel supports GitHub integration and automatic previews for changes. [Vercel for GitHub](https://vercel.com/docs/git/vercel-for-github)

**Our inference:** differentiation comes from the complete production journey across the original building tool’s boundaries: automatic discovery, business-relevant priorities, simple package pricing, executed improvements, functional validation, reviewable evidence and an optional operating relationship. Validate actual platform independence before claiming support for every app.

Do not rely on “our AI finds more bugs” as the only reason to buy. The stronger outcome is that the customer understands the next step, can afford it, can inspect the result and knows who operates the app afterwards.

## 5. Fixed packages plus transparent usage

The commercial model is defined; actual prices are not yet supplied. Do not invent live prices or treat usage estimates as fixed totals.

| Package | What the customer receives | Fixed component | Variable component |
|---|---|---|---|
| AI app scan | Automatic analysis, findings, coverage, priorities and a phased improvement plan | Fixed scan package fee | Measured AI token usage |
| Improvement package | Defined changes, explanation, code differences, relevant tests and a private preview | Fixed fee for the published package scope | Measured AI token usage |
| Launch package | Agreed release checks, deployment, recovery setup and handover | Fixed launch fee | Any disclosed AI or external usage |
| Hosting | Environment appropriate to selected availability and data requirements | Fixed monthly hosting package | Usage such as compute, storage and bandwidth beyond stated inclusions |
| Management | Defined maintenance, monitoring follow-up and incident coverage | Fixed monthly management package | Only separately disclosed usage or explicitly approved extra work |

A full improvement plan can combine packages. It should still show each package’s scope, fixed fee and usage budget. Avoid turning every app into an open-ended hourly consulting quote. Internal complexity detection maps the work to supported packages or explains why a specialist proposal is required.

Customers can take the report elsewhere. A launch-blocking issue cannot be bypassed by declining its improvement package; declining stops or postpones the release path. Hosting and management remain optional.

### What must be visible before every paid run

- Package name, fixed price, deliverables and exclusions.
- AI model or model class, input/output token rates, billing unit and any separate cached-token rates.
- A token-use estimate, clearly identified as an estimate, and an approved usage budget.
- Other metered services, included allowances, rates and measurement units.
- Billing currency, tax treatment and payment timing.
- What happens if a run is cancelled, fails, retries or reaches its spending limit.

**Recommended spending rule:** a run pauses before exceeding the approved usage budget and explains the additional work. The customer must approve a higher limit. Enforce this in the execution system, not just with a visual counter. Reserve budget for in-flight requests and bound their possible cost so the provider cannot incur an uncontrolled overrun. If a provider cannot be bounded precisely, absorb unapproved excess instead of billing it silently.

Show a final itemized breakdown: fixed fee, actual billable input/output tokens, rate applied, credits/refunds and other authorized charges. Show the same running breakdown during execution. A partial result must say which checks or improvements remain incomplete.

Tokens are units of text processed or generated by an AI model; a codebase’s size alone does not determine the bill. Repository context, output, repeated checks and retries can all affect usage. Decide whether tool execution, internal retries and platform failures are billable. If there is a markup on model costs, disclose the customer rate and avoid claiming pass-through pricing.

For hosting, fixed-price does not mean unlimited resources. Publish included capacity and usage units. Spending alerts, limits and their consequences must be specified. Automatically pausing a scan is different from shutting down a live customer app; the latter needs a separately agreed operational policy.

### Decisions before opening purchases

Set the actual package fees, currency, model rates/markup, usage caps, inclusions, cancellation/refund rules, billing cadence and tax presentation. These are business decisions still to be made. The first website shows the structure with an explicit “to be confirmed” notice.

Measure unit economics through pilots: execution, human review, AI and sandbox usage, rework and allocated support. Include scans that do not convert into paid improvements. A useful internal check is `price = expected direct cost / (1 − target gross margin)`, but willingness to pay and customer value need independent validation.

## 6. Make evidence part of the product

Every improvement follows the same chain:

**Finding → user/business impact → agreed outcome → change → test → preview → remaining gaps.**

Example: changing an invoice ID exposes another customer’s invoice. The improvement checks ownership before returning data. Evidence shows that the owner retains access, a different customer cannot retrieve it and a signed-out visitor receives no data. Load testing remains “not tested” if it was not performed.

Bind findings and evidence to a specific source version, test date, test definitions and examined scope. Preserve the original failing test so an agent cannot obtain a passing result by weakening the control. Use an independent evaluation process and human review for critical changes. A preview supports customer acceptance but does not substitute for security or recovery testing.

Use **passed, failed, not tested and not applicable**. A scanner that never ran cannot produce a passed control. Avoid a single reassuring security percentage: one broken access boundary can outweigh many passing checks.

OWASP ASVS provides verifiable application security requirements that can inform the assessment profile. Use versioned references and a documented selection. Applying selected controls is not certification or proof of complete conformity. [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/)

| Stage | Proposed acceptance criteria within the examined scope |
|---|---|
| Scan | Source version recorded; reproducibility investigated; architecture/data flows identified; evidence and unknowns visible |
| Foundation | Clean build works; agreed key journeys work; configuration and errors are manageable; no exposed secrets in published output |
| Security | Relevant sign-in, access and tenant boundaries tested; critical blockers resolved; sensitive changes reviewed |
| Reliability | Relevant failure/retry scenarios checked; agreed performance targets tested; useful logs without sensitive payloads |
| Launch | Exact tested artifact deployed; alerts reach an owner; restore/rollback tested; migrations planned; technical release review and customer acceptance |

Production readiness means readiness for the defined use and release conditions, with residual risk visible. Do not claim every defect is found or that an app is universally secure.

## 7. Build a safe AI execution system

Customer code is untrusted input. The low-effort customer experience requires substantial controls behind the scenes:

1. **Minimal connection permissions.** Use a GitHub App limited to selected repositories. Separate read access from later branch/PR write access and keep short-lived tokens away from the environment running customer code. [GitHub App best practices](https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app)
2. **Static intake first.** Check archives for size, expansion limits, path traversal and symlinks. Detect and redact secrets before model processing. Do not blindly run installation scripts or repository workflows.
3. **Fresh isolation for each task.** Bound network, compute, memory, storage, time and cost. No production credentials, host sockets, internal network access or shared writable caches. GitHub specifically warns that untrusted code can compromise persistent self-hosted runners. [GitHub secure use](https://docs.github.com/en/actions/reference/security/secure-use)
4. **Separate agent reasoning from authority.** Repository instructions, code comments and tool output cannot grant permissions. Enforce tools, network and deployment policy outside the model. This also addresses indirect prompt injection. [OWASP prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)
5. **Controlled delivery.** Use synthetic test data and protected previews on separate domains. Require human review for permissions, payments, encryption, personal data, production data and destructive migrations.
6. **A processing record.** Show which AI, scanning, logging and hosting services receive code, where it is processed, retention and deletion rules. Obtain necessary authority to process the submitted project.
7. **Continuing maintenance.** Vulnerabilities and changes remain relevant after release, according to the management package. NIST SSDF supports security throughout the development lifecycle and responding to residual vulnerabilities. [NIST SSDF](https://csrc.nist.gov/projects/ssdf)

## 8. Hosting has three independent dimensions

| Dimension | Choices | Define before subscription |
|---|---|---|
| Availability | Standard, redundant, tailored continuity | Capacity, failure scenarios, backups, acceptable data loss and recovery targets |
| Data and control | Supply-chain visibility, European setup, additional requirements | Locations, providers, ownership/control, support, subprocessors, keys and exit arrangements |
| Management | Self-managed, essential, extended | Maintenance windows, response coverage, incident ownership, included work and escalation |

Redundancy must address the app, database and critical dependencies. A second web server alone does not establish continuity. Do not publish uptime or 24/7-response promises before the architecture, measurement, staffing and contract support them. An infrastructure SLA is not automatically the availability of the entire customer application. [Google SRE on service levels](https://sre.google/sre-book/service-level-objectives/)

### European hosting and the CLOUD Act

European storage alone does not determine which foreign disclosure powers can apply. US law at 18 USC §2713 refers to data within a covered provider’s possession, custody or control regardless of location. Assess jurisdiction and effective control alongside server geography. [18 USC §2713](https://uscode.house.gov/view.xhtml?edition=prelim&num=0&req=granuleid%3AUSC-prelim-title18-section2713)

The EDPB’s final Article 48 guidelines explain that a foreign government request is not, by itself, a legal basis for processing and transfer. GDPR compliance and the potential reach of another jurisdiction require distinct analysis. [EDPB Article 48 guidelines](https://www.edpb.europa.eu/documents/guideline/guidelines-022024-on-article-48-gdpr_en)

Include production, backups, logs, source hosting, AI providers, email, analytics, external APIs, support and subprocessors in the assessment. Access from outside the EEA and who can read decrypted data or control keys can matter. [EDPB supplementary transfer measures](https://www.edpb.europa.eu/system/files/documents/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf)

Suitable wording is “European hosting with explicit requirements for data location, suppliers and access.” Avoid a blanket “CLOUD Act-free” promise. Requirements must cover GITP’s analysis/improvement chain as well as the final hosting. Have a qualified privacy lawyer review provider arrangements and specific claims before commercial use.

## 9. Human expertise required behind the experience

| Role | Concrete responsibility | When |
|---|---|---|
| Product strategist / UX writer | Validate paid demand, simplify reports and explain fixed-plus-usage pricing | Before and during pilots |
| Senior fullstack engineer | Validate supported stacks, existing platform capability and delivery quality | From the first customer project |
| AppSec engineer | Assessment profile, access model, classification and critical change review | Before code intake and for sensitive improvements |
| SRE / cloud architect | Isolation, budget enforcement, deployment, monitoring, recovery and service design | Before running customer code or providing hosting |
| Privacy lawyer | Processing chain, transfers, provider claims and contracts | Before real customer processing under the proposed terms |
| Independent penetration tester | Challenge the execution system and tenant isolation | Before broad intake and after relevant changes |

One person may cover several roles, but accountability must be explicit. These are internal delivery controls, not mandatory intake meetings for every customer. AI research in this assignment is not a replacement for those human responsibilities.

## 10. Three routes to market

| Route | Advantage | Trade-off | Recommendation |
|---|---|---|---|
| AI-driven workflow with specialist review behind the scenes | Immediate connection, automatic investigation and controlled learning from paid improvement packages | Review capacity initially limits scale | **Recommended**, accessible to all three audiences |
| Broad self-service across many stacks | Potentially high volume | More variable cost, unsupported projects and difficult failure handling | Expand after pilots demonstrate repeatability |
| Enterprise-led European data control | Larger engagements and explicit governance needs | Longer buying cycles and heavier supplier requirements | Develop when technology and operational capacity support it |

### A proposed first 90 days

**Weeks 1–2:** inspect the existing platform, select the first supported stack and define automatic discovery, package boundaries and spending controls. Run a small set of problem interviews across all three audiences; test the English website and report example.

**Weeks 3–6:** run controlled pilots with paid scans and improvement packages under explicitly agreed pilot prices. Measure analysis quality, actual token usage, estimate error, human review time, total cost, rework and customer acceptance. Require clear release criteria.

**Weeks 7–10:** standardize repeatable controls and reports. Independently challenge isolation and budget enforcement. Test export, rollback, restore and provider-chain assumptions. Determine which costs belong in the fixed fee versus metered usage.

**Weeks 11–13:** publish fees and rates informed by actual costs and willingness to pay. Define cancellation, retry and failure policies. Expand only the stacks and service levels you can deliver. Prioritize transparent execution over unsupported promises of universal coverage.

### Three business assumptions to test

1. **Customers will pay beyond their building tool.** Look for paid scans and improvements tied to a real launch or handover problem, not just website interest.
2. **Fixed package delivery is repeatable and profitable.** Measure full cost, including review and rework, without weakening checks to preserve margin.
3. **Recurring hosting and management remain healthy after support costs.** Validate actual incidents, coverage expectations and recovery effort against package revenue.

## 11. What the website implements

The English homepage includes the core promise, a sample AI report, an explanation of vibe-coded apps and AI agents, three audience scenarios, four delivery steps, interactive finding/change/test tabs, fixed-plus-usage pricing, hosting and management options, FAQs and a connection-oriented closing section. The hero focuses on the brand illustration; the sample report appears in its own section after the delivery steps.

No client logos, testimonials, certifications, uptime figures or real prices have been invented. The findings and test results are explicitly fictional. Tabs and expandable explanations work as a presentation; live GitHub connections, uploads, scanning, repair, billing and operational hosting are not connected to this website.

The existing platform and its delivery capabilities still need a separate review. The website is a first product and positioning concept, with this document available from the footer.

## 12. Scope extension: AI agents

The founders also want GITP to serve people building AI agents. The positioning is now “For your vibe-coded apps & AI agents”, with the same connect-first workflow and transparent package-plus-usage model.

Proposed agent assessments should cover tool and data access, permitted actions, required approvals, failure handling and usage limits. Evidence should identify the tested agent version, its available tools and the scenarios exercised. The scan must state unsupported components and any behavior that needs further testing. This is a product-scope decision, not evidence that all agent frameworks are already supported by the existing platform.