The most ambitious programming language project of 2026 did not come from San Francisco, Berlin, or Tokyo. It came from Abidjan -- the economic capital of Cote d'Ivoire, a city of five million people on the southern coast of West Africa.
The person who started it is not a PhD in programming language theory. He did not work at Google on V8, or at Mozilla on Rust, or at Apple on Swift. His name is Juste Thales Gnimavo, he is the CEO of ZeroSuite, and his CTO is an AI.
This is the story of building a programming language with a $200/month budget, no human engineering team, and the conviction that the next generation of developers will not learn to code on the tools Silicon Valley built for itself.
The Desk in Abidjan
Abidjan is not a city that appears on lists of "tech hubs to watch." It is not Nairobi with its established startup ecosystem. It is not Lagos with its venture capital flow. It is not Cape Town with its proximity to European markets. Abidjan is a French-speaking West African city where the tech industry is nascent, where developer communities are small, and where the infrastructure challenges are real.
The internet averages 5-15 Mbps on a good day. Power outages are routine -- not daily, but frequent enough that you plan around them. Air conditioning is a luxury that affects how long you can work in the afternoon heat. Mobile data costs real money, and a 1.5 GB download represents a meaningful expense.
This is where FLIN was born. Not despite these constraints, but because of them.
Juste works from a desk in Abidjan with a MacBook, a stable-enough internet connection, and a subscription to Claude -- the AI that serves as his CTO. The monthly budget for the entire FLIN project, including compute costs for the AI, cloud services for testing, and incidental expenses, is approximately $200.
Two hundred dollars. Per month. For a programming language with a compiler, a virtual machine, a temporal database, an HTTP server, 409 built-in functions, 180 embedded UI components, and 3,452 passing tests.
The CEO + AI CTO Model
The conventional wisdom says that building a programming language requires a team of experienced compiler engineers, years of development time, and significant funding. The Rust language took seven years from inception to 1.0, backed by Mozilla's resources. Swift was developed by a team at Apple. Go had the full backing of Google.
FLIN has two people: one human and one AI.
The division of labor is not "human designs, AI implements." It is more nuanced than that. Juste brings domain expertise -- he understands the pain of building web applications in Africa, he knows what developers in emerging markets need, and he makes the product decisions that shape FLIN's design. Claude brings technical execution -- it writes Rust code, designs data structures, implements algorithms, and produces correct software at a speed that no human developer could match alone.
A typical development session looks like this:
Session 001 - January 1, 2026
Duration: ~45 minutesCompleted: - Created Cargo.toml with dependencies - Created src/main.rs skeleton - Created module directories (lexer, parser, typechecker, codegen, vm, database, server, error) - Defined Position and Span structs - Defined Keyword enum (42 keywords) - Defined TokenKind enum (60+ token types) - Defined Token struct - Implemented Display for tokens - Added 25+ unit tests for keyword lookup
Files created: 14 Lines of Rust: ~1,000 ```
Forty-five minutes. Fourteen files. One thousand lines of correct, tested Rust code. This is not a rough sketch -- these are production token definitions that still power the compiler today, three months and 336 sessions later.
The speed is possible because of how the AI CTO model works. There is no code review process that takes three days. There is no "set up my development environment" phase. There is no context-switching between a Slack conversation about architecture and an IDE where the code lives. Juste describes what he wants, Claude produces it, and the Rust compiler verifies it. The feedback loop is minutes, not days.
But speed without quality is just fast failure. What makes the model work is Rust's compiler as a third team member. When Claude generates code, cargo check immediately verifies that it compiles. cargo test verifies that it behaves correctly. cargo clippy verifies that it follows Rust idioms. The AI produces code; the compiler validates it; the human makes architectural decisions. Three roles, two entities, zero wasted cycles.
The $200/Month Constraint
The budget constraint is not a hardship story. It is a design constraint -- and like all good design constraints, it produces better outcomes.
When you have $200/month, you cannot afford:
- Cloud infrastructure for CI/CD. So the test suite must run locally, fast. FLIN's 3,452 tests complete in under 30 seconds on a MacBook.
- A team of contractors or freelancers. So every piece of code must be written by the two-person team. No outsourcing the boring parts.
- Multiple development environments. So the toolchain must be simple. Rust, Cargo, a terminal. No Docker orchestration for development, no Kubernetes cluster, no staging environment.
- Paid APIs for core functionality. So the database (FlinDB) is embedded, the HTTP server is built-in, and the compiler is self-contained. External API costs are limited to AI gateway calls, which are passed through to the end user.
These constraints shaped FLIN's architecture in ways that benefit every user:
- FlinDB is embedded because we could not afford a managed PostgreSQL instance for development. The result is that FLIN users also do not need a managed database -- it just works, out of the box.
- The single-binary distribution exists because we could not afford CDN costs for a multi-file distribution. The result is that FLIN installs in one command, anywhere in the world.
- The 409 built-in functions exist because we could not afford to depend on npm packages (and the Node.js runtime they require). The result is that FLIN has zero external dependencies at runtime.
What started as a budget limitation became a product advantage. The best tools are often built under constraints that force simplicity.
Why Africa Matters
FLIN could have been built to solve the problems of San Francisco developers. Those problems are real -- toolchain complexity, JavaScript fatigue, configuration hell. But the problems are survivable. A developer in San Francisco has fast internet, unlimited power, cheap compute, and an employer who pays for the tools.
The problems are existential in Africa.
When downloading node_modules costs a day's mobile data budget, the developer does not download node_modules. They do not learn React. They do not build web applications. They are excluded from the global software economy -- not by lack of talent or motivation, but by the tools themselves.
FLIN's "zero dependencies, single binary" model is not a nice-to-have for African developers. It is a prerequisite for participation. A developer in Dakar or Douala or Dar es Salaam can download a 15 MB binary, create a .flin file, and start building. No npm. No 1.5 GB download. No complex toolchain. No barrier between "I want to build something" and "I am building something."
The name FLIN itself reflects this orientation. It comes from Fongbe, a language spoken in Benin:
E flin nu
| | |
| | +-- "things" / "stuff"
| +------ "remember" / "not forget"
+--------- "it" (3rd person)Translation: "It remembers things" ```
The elephant is FLIN's symbol because in Fongbe culture, elephants represent memory and wisdom. "Elephants never forget" -- like FLIN's temporal database, which maintains the complete history of every record. And the elephant is a symbol of Africa, where the language was conceived.
This is not performative. The name, the symbol, and the design philosophy are rooted in the same place: a belief that the next billion developers will come from Africa, Asia, and Latin America, and they deserve tools built for their reality.
The Session Log: 336 Sessions and Counting
Every FLIN development session is logged. Session 001 was January 1, 2026 -- project setup and token definitions. Session 336 was the most recent, completing database migrations and schema diffing. Between those bookends, the complete history of a programming language's development is documented.
The session logs reveal a development cadence that no traditional team could sustain:
January 2026: Sessions 001-090 Lexer, parser, AST, type checker foundations
February 2026: Sessions 091-250 Code generator, VM, FlinDB, HTTP server,
native functions
March 2026: Sessions 251-336 UI components, testing framework, migrations,
Stripe, webhooks, production readinessThree hundred and thirty-six sessions in 85 days. An average of four sessions per day. Each session focused, documented, and producing tested code. The AI CTO model enables this cadence because Claude does not get tired, does not lose context between sessions (within a conversation), and does not need coffee breaks.
But Juste does get tired. The human in the loop is the bottleneck -- not in code production, but in decision-making. Choosing whether FlinDB should use B-trees or LSM trees. Deciding whether the @ operator should work on entity instances or query results. Determining whether FLIN's import system should use filesystem paths or module names. These are product decisions that require understanding the user, the market, and the vision.
The AI produces code. The human produces direction. Neither can do the other's job.
The Toolchain: Deliberately Simple
FLIN's development environment is:
- A MacBook.
- Rust (installed via rustup).
- A terminal (iTerm2).
- Claude (via API and CLI).
- Git (for version control).
There is no IDE with language-specific extensions. There is no Docker for the development database (FlinDB is embedded). There is no CI/CD pipeline (tests run locally). There is no staging environment (the binary is the same everywhere). There is no project management tool beyond Markdown files in the repository.
This simplicity is a choice, not a limitation. Every tool you add to a development workflow creates maintenance burden, requires configuration, and introduces potential failure points. When your team is two entities and your budget is $200/month, every unnecessary tool is an enemy.
The build process is:
cargo build --release # Compile the FLIN compiler + runtime
cargo test # Run 3,452 tests
cargo clippy -D warnings # Lint for Rust idioms and potential bugsThree commands. If all three pass, the code is ready. No Jenkins pipeline. No GitHub Actions workflow. No "the tests pass locally but fail in CI" debugging sessions.
What Abidjan Taught Us About Language Design
Living in Abidjan did not just constrain FLIN's budget. It shaped FLIN's design philosophy.
Offline-first is not an edge case. In Abidjan, internet connectivity is intermittent. FlinDB is embedded specifically so that FLIN applications work without an internet connection. The database is local. The compiler is local. The server is local. If the internet goes down, you can still develop, still test, and still run your application.
Simplicity is a feature, not a limitation. When your users include self-taught developers in Francophone Africa who learned HTML from YouTube videos on mobile phones, you cannot afford a steep learning curve. FLIN's syntax is designed so that someone who knows HTML and basic variable assignment can build a real application. The entity, save, delete, and for keywords were chosen because they read like English (and map intuitively to French: entite, sauvegarder, supprimer, pour).
Binary size matters. A 15 MB binary downloads in seconds on a slow connection. A 1.5 GB toolchain does not download at all. FLIN's single-binary distribution is not a technical flex -- it is an accessibility requirement.
The developer's time is the scarcest resource. In Silicon Valley, developer time is expensive because salaries are high. In Abidjan, developer time is expensive because there are so few developers. Either way, a tool that wastes developer time on configuration, dependency management, and boilerplate is a tool that fails its users. FLIN's zero-configuration, zero-dependency model respects the developer's time regardless of where they sit.
The Broader Bet: Software From the Periphery
FLIN is part of ZeroSuite, a company building six software products from Abidjan with zero human engineers. The thesis is audacious: that the CEO + AI CTO model can produce software that competes with -- and in some cases surpasses -- products built by well-funded teams in traditional tech hubs.
The products are:
- Deblo.ai -- An AI educational platform for African students, from primary school through the baccalaureat.
- Deblo Pro -- A professional AI assistant for SYSCOHADA accountants, lawyers, and auditors.
- sh0.dev -- A single-binary PaaS platform for self-hosted deployments, written in Rust.
- FLIN -- A memory-native programming language.
- ZeroCore -- The embedded database engine that powers FlinDB.
- ThalesAndHisAiCtoClaude.com -- The blog you are reading, documenting the journey.
Six products. One human. One AI. Two hundred dollars a month.
This is not a proof of concept. Deblo.ai has real students. sh0.dev has real deployments. FLIN has 3,452 passing tests and 409 working functions. The model works.
It works because AI has fundamentally changed what is possible for a solo founder. Tasks that once required a team -- writing a lexer, implementing a type checker, building a database engine, creating a deployment pipeline -- can now be accomplished by one person directing an AI with sufficient capability and context.
And it works from Abidjan because the internet is global. Claude does not care whether the terminal it connects to is in San Francisco or Cote d'Ivoire. The Rust compiler produces the same binary regardless of the developer's time zone. Cargo downloads crates at the same speed from crates.io whether the request originates in Mountain View or Marcory.
The geographic advantage of traditional tech hubs -- proximity to talent, investors, and customers -- matters less every year. The talent is the AI. The investment is $200/month. The customers are global.
What Comes Next
FLIN's roadmap to v1.0 is documented in the previous article in this series. The technical milestones are clear: plugin system, multi-file imports, performance optimization, and ultimately self-hosting -- the moment FLIN can compile itself.
But the milestone that matters most is not technical. It is the moment a developer in Lome, or Cotonou, or Ouagadougou downloads the FLIN binary, creates their first .flin file, and builds something real. Something that solves a problem in their community. Something that would have been inaccessible behind the wall of npm, React, TypeScript, and 1,847 dependencies.
That is why we are building FLIN from Abidjan. Not because it is the obvious place to build a programming language. Because it is the necessary place. The constraints of this city -- the slow internet, the power outages, the limited budgets, the small developer communities -- are the constraints that billions of people share. A language designed for these constraints is a language designed for the world.
Every major programming language has been built by a team at a well-funded company in a wealthy country. FLIN is being built by a founder in West Africa and an AI, on a budget that would not cover a single engineer's monthly coffee tab in San Francisco.
If it works -- and 3,452 passing tests suggest it might -- it proves something larger than a language. It proves that the era of geographic gatekeeping in software is ending. That the tools of creation are no longer reserved for those who happen to live near Sand Hill Road. That the next Rust, the next Go, the next Swift might come from Abidjan, or Accra, or Addis Ababa.
E flin nu. It remembers things.
And perhaps the most important thing it remembers is that great software can come from anywhere.
---
This is Part 10 of the "How We Built FLIN" series, documenting how a CEO in Abidjan and an AI CTO built a programming language from scratch.
Series Navigation: - [6] Why We Chose Rust to Build a Programming Language - [7] Writing Apps Like It's 1995 With the Power of 2026 - [8] What FLIN Looks Like in Practice: First Examples - [9] The Roadmap to FLIN v1.0 - [10] Building a Programming Language From Abidjan, Cote d'Ivoire (you are here)