FLIN v1.0.0-alpha.2 has 3,452 passing tests, 409 native functions, a complete compiler pipeline, an embedded database engine, an HTTP server with WebSocket and SSE support, a security layer with OAuth and JWT, a search system with BM25 and semantic vectors, an AI gateway with 8 providers, and an admin console. By any reasonable measure, this is an impressive body of work.

It is also not ready for v1.0.

The gap between "impressive alpha" and "production-stable v1.0" is not about building more features. It is about closing the gaps that would cause a developer to abandon FLIN in frustration, a security auditor to flag the deployment, or an operator to wake up at 3 AM to a silent data corruption issue. This article maps every gap, the plan to close each one, and the reasoning behind what ships in v1.0 and what waits for v1.1.

What Already Exists

Before cataloging the gaps, it is important to acknowledge the foundation. FLIN alpha already includes capabilities that many production frameworks lack:

// This already works in FLIN alpha:

entity Product { name: text @required @minLength(3) price: int @min(0) description: text image: file category: text @one_of(["electronics", "clothing", "food"]) created_at: time @default(now) }

route GET "/products" { guard rate_limit(100, 60)

products = Product .where(category == query.category || query.category == none) .order(created_at, "desc") .limit(20)

}

route POST "/products" { guard auth guard role("admin")

validate { name: text @required price: int @required @min(0) }

product = Product { ...body } save product { id: product.id, name: product.name } } ```

Entity definition with validation, file-based routing with guards, rate limiting, authentication, role-based access control, template rendering, query building -- all working, all tested. The core developer experience is solid.

The gaps are at the edges: where the framework meets production infrastructure, where developers need tools beyond coding, and where enterprise requirements exceed startup requirements.

Phase 1: Alpha 2 -- Quick Wins (Complete)

Phase 1 addressed the most immediately visible gaps -- items that a developer would notice within the first hour of using FLIN:

These six items were each small-to-medium in scope. Markdown rendering added pulldown-cmark and a single native function. CSV export was implemented from scratch (no external crate needed). CORS configuration extended the existing flin.config parser. Each item took roughly one session.

Phase 1 was about removing friction. A developer building a blog needs Markdown. A developer building a dashboard needs CSV export. A developer deploying to production needs CORS configuration and a deployment guide. Without these, FLIN is a toy. With them, it is a tool.

Phase 2: Beta -- Production Readiness (Complete)

Phase 2 tackled the features that production applications require -- not for day-one development, but for day-thirty deployment:

The two most critical items were the testing framework and database migrations.

The testing framework lets developers write tests in FLIN itself:

// tests/product.test.flin

test "creating a product saves to database" { product = Product { name: "Test Item", price: 999 } save product assert product.id != none assert Product.count > 0 }

test "price must be non-negative" { product = Product { name: "Bad Item", price: -1 } result = try save product assert result is error assert result.message.contains("min") }

test "name is required" { product = Product { price: 100 } result = try save product assert result is error assert result.message.contains("required") } ```

Without flin test, developers have no way to verify that their applications work correctly after changes. This was the single biggest gap for professional adoption.

Database migrations solved the second biggest gap: schema evolution. Before migrations, adding a field to an entity required deleting .flindb and re-seeding. With migrations, schema changes are detected, applied, and logged automatically:

$ flin migrate myapp/

Detected schema changes: Product: + discount: float (default: 0.0) ~ price: int -> float (coercion: lossless) - legacy_sku: text (data preserved in migration log)

Apply these changes? [y/N] y

Migration applied successfully. Records migrated: 1,247 Duration: 340ms Log: .flindb/migrations.json ```

Phase 3: Release Candidate -- Scale and Polish

Phase 3 contains the features that differentiate FLIN from a competent framework into an enterprise-ready platform. These are larger in scope and more complex in implementation:

Plugin and Extension System

The most requested feature by early testers. Developers want to share reusable FLIN packages -- entity definitions, components, middleware, utilities. The plugin system requires a package format, a resolution algorithm, a registry, and CLI integration.

// flin.config
dependencies {
    flin-auth: "^1.0"
    flin-stripe: "^2.0"
    flin-analytics: "^1.0"
}

$ flin add flin-stripe
Installing [email protected]...
  + 3 entities (Customer, Subscription, Invoice)
  + 2 components (CheckoutButton, PricingTable)
  + 5 native functions (stripe_checkout, stripe_customer_create, ...)
Done.

This is an XL-sized task. Package resolution alone -- handling version conflicts, circular dependencies, and platform-specific packages -- is a multi-session effort. We estimate 4-6 sessions for the initial implementation.

Multi-Tenancy

SaaS applications need data isolation per tenant. FLIN will support two strategies: database-level isolation (separate .flindb per tenant) and row-level isolation (automatic tenant_id filtering on every query).

// flin.config
multitenancy {
    strategy: "row"
    field: "tenant_id"
    resolver: "subdomain"
}

// Developer writes normal queries -- tenant scoping is automatic products = Product.where(price > 1000) // Runtime translates to: Product.where(price > 1000 && tenant_id == current_tenant) ```

Multi-tenancy requires deep integration with the query builder, the entity system, and the admin console. It is a large task but has a clearly defined scope.

Performance Profiling

Built-in request profiling with a development toolbar:

Request: 23ms | Queries: 4 (3.2ms) | Template: 8ms | Memory: 2.1MB

The profiler instruments the request pipeline and injects a collapsible toolbar into HTML responses during development mode. It tracks query count (to detect N+1 problems), template render time, memory allocation, and end-to-end latency.

Internationalization (i18n)

FLIN applications should support multiple languages without architectural gymnastics:

// translations/fr.json
{
    "welcome": "Bienvenue, {name} !",
    "products.count": "{count} produit | {count} produits",
    "errors.required": "Ce champ est obligatoire"
}

// Usage in templates

{t("welcome", name: user.name)}

{t("products.count", count: products.len)}

This is a medium-sized task: a translation file format, a t() native function, pluralization rules, and locale detection from the Accept-Language header.

What Does Not Ship in v1.0

Not every feature makes the cut. Some are explicitly deferred to v1.1 or later:

Real-time collaboration. Operational Transform or CRDT-based concurrent editing. This is a massive technical challenge with limited demand for v1.0 use cases.

Visual query builder. A drag-and-drop interface for constructing entity queries. Nice to have, but the textual query builder is already intuitive.

Mobile SDK. Native iOS/Android libraries for FLIN-backed applications. The HTTP API already supports mobile clients; a dedicated SDK is a v1.1 concern.

Distributed deployment. Horizontal scaling across multiple servers with data replication. FLIN v1.0 targets single-server deployments. Scaling comes later.

The decision of what to defer is not about difficulty -- it is about audience. FLIN v1.0 targets individual developers and small teams building web applications. Distributed deployment is an enterprise concern. Real-time collaboration is a niche requirement. Mobile SDKs are a convenience, not a necessity. By focusing v1.0 on the core use case, we avoid the trap of building everything for everyone and shipping nothing for anyone.

The Path from Here

The remaining work breaks down as follows:

Weeks 1-2: Plugin system foundation. Package format, local resolution, flin add command. No registry yet -- packages are loaded from local directories or git URLs.

Weeks 3-4: Multi-tenancy. Row-level isolation first (simpler, covers 80% of use cases), database-level isolation second.

Weeks 5-6: Performance profiling. Instrumentation across the request pipeline, development toolbar, slow query detection.

Weeks 7-8: Internationalization. Translation files, t() function, pluralization, locale detection.

Weeks 9-10: Documentation sprint. Comprehensive guide covering every subsystem, API reference, tutorials, deployment recipes.

Weeks 11-12: Release candidate. Bug fixes, edge case hardening, performance tuning, final test pass.

This is an aggressive timeline. Twelve weeks from alpha to stable. But the foundation is solid -- 3,452 tests, 409 native functions, a complete compiler pipeline, and three phases of production hardening. The remaining work is additive, not foundational. We are building rooms on a finished house, not pouring the foundation.

The Honest Assessment

FLIN at alpha is a genuine achievement. A programming language with a compiler, a VM, an embedded database, an HTTP server, a search engine, an AI gateway, and an admin console -- built in under two months by two people, one of whom is an AI. The test suite is comprehensive. The architecture is clean. The developer experience, within the boundaries of what is implemented, is excellent.

But "within the boundaries of what is implemented" is the critical qualifier. A developer who needs Markdown rendering and does not find it gives up. A developer who needs database migrations and does not find them gives up. A developer who needs to write tests and cannot gives up. Phase 1 and Phase 2 closed the most critical of these gaps. Phase 3 will close the rest.

The path from alpha to stable is not a sprint -- it is a methodical closing of every gap that would cause a real developer, building a real application, to hit a wall. When no wall remains, we ship v1.0.

// The state of FLIN today
flin_status = {
    version: "v1.0.0-alpha.2",
    tests: 3452,
    native_functions: 409,
    embedded_components: 180,
    embedded_icons: 1675,
    ai_providers: 8,
    storage_backends: 4,
    document_formats: 9,
    sessions_completed: 337,
    built_by: ["Juste A. GNIMAVO", "Claude"],
    built_from: "Abidjan",
    status: "alpha, approaching beta",
    next_milestone: "v1.0.0-beta.1"
}

From Abidjan, with zero human engineers, building a language that replaces 47 technologies. The remaining work is significant but finite. We know exactly what needs to be done. And we will do it.

---

This is Part 190 of the "How We Built FLIN" series, documenting how a CEO in Abidjan and an AI CTO designed and built a programming language from scratch.

Series Navigation: - [189] Tracking Sync and State Management - [190] From Alpha to Stable: The Remaining Work (you are here) - Next arc: [191-200] FLIN Ecosystem and Tooling