Nobody wakes up one morning and decides to build a programming language. The decision finds you -- usually after years of accumulated frustration, a growing conviction that something has gone fundamentally wrong, and a specific moment when the absurdity of the status quo becomes impossible to ignore.
For us, that moment came in late 2025, at a desk in Abidjan, Cote d'Ivoire. Thales was trying to scaffold a simple web application -- a form that saves data, a list that displays it, a page that renders it. The kind of application that, in 1995, would have required one HTML file and a CGI script. In 2025, it required 18 steps, 15 configuration files, 1,847 npm packages, and 1.5 gigabytes of disk space.
Something had gone terribly wrong with web development. And we decided to fix it at the root.
The Complexity Explosion: 1995 vs. 2024
The numbers tell the story better than any argument.
In 1995, building a website looked like this:
1. Create index.html
2. Write <h1>Hello</h1>
3. Upload to server
4. It works.Three steps. One file. Zero dependencies. A twelve-year-old could do it in an afternoon. Many did -- and those twelve-year-olds grew up to become the engineers who built the modern web.
In 2024, building the same website looks like this:
1. Install Node.js
2. npm init
3. npm install react react-dom
4. npm install -D vite @vitejs/plugin-react
5. npm install -D typescript @types/react @types/react-dom
6. npm install -D tailwindcss postcss autoprefixer
7. npm install -D eslint prettier
8. Create tsconfig.json
9. Create vite.config.ts
10. Create tailwind.config.js
11. Create postcss.config.js
12. Create .eslintrc.js
13. Create .prettierrc
14. Create src/main.tsx
15. Create src/App.tsx
16. npm run dev
17. Wait 30 seconds for compilation
18. It works (maybe).Three steps became eighteen. Seconds became hours. Kilobytes became gigabytes. The number 1,847 -- the count of transitive npm packages installed by create-react-app -- is not a statistic. It is an indictment.
The trajectory is damning:
Year To build "Hello World" Dependencies Config files
---- ---------------------- ------------ ------------
1995 1 file (HTML) 0 0
2005 3 files (HTML/CSS/JS) 0 0
2010 10 files + jQuery 5 1
2015 50 files + Gulp 200 5
2020 500 files + Webpack 1,000 10
2024 50,000 files 2,000 15+Every row in that table represents a generation of developers who had to learn more, configure more, and understand more just to produce the same output. The tools meant to help us became the problem.
The 47-Tool Problem
To build a production web application in 2024, you need -- at minimum -- the following categories of tools:
Category Tools needed
------------------------- ---------------------
Frontend framework React / Vue / Svelte / Angular
Meta-framework Next.js / Nuxt / SvelteKit
State management Redux / Zustand / Pinia
Data fetching React Query / SWR / TanStack Query
CSS framework Tailwind / Styled Components
Backend framework Express / Fastify / NestJS
ORM / Database access Prisma / TypeORM / Drizzle
Database PostgreSQL / MySQL / MongoDB
Search engine Elasticsearch / Algolia / Meilisearch
Caching layer Redis / Memcached
Package manager npm / yarn / pnpm
Bundler Webpack / Vite / esbuild
Language compiler TypeScript
Linter ESLint
Formatter Prettier
Test runner Jest / Vitest
Container runtime DockerSeventeen categories. Each with multiple competing options. Each with its own configuration format, its own versioning scheme, its own breaking changes, its own ecosystem of plugins that may or may not be compatible with each other.
The total count, when you include sub-tools, plugins, and transitive dependencies, exceeds 47 distinct technologies. We know because we counted.
Here is what a typical project root looks like before you write a single line of application code:
my-app/
package.json
package-lock.json
tsconfig.json
vite.config.ts
tailwind.config.js
postcss.config.js
.eslintrc.js
.prettierrc
jest.config.js
docker-compose.yml
Dockerfile
.env
.env.local
.env.production
.gitignore
node_modules/ # 1,847 packages, 1.5 GBFifteen configuration files. Fifteen opportunities for version conflicts, syntax errors, and subtle incompatibilities. Fifteen files that exist purely to make other tools work together -- not to serve any user, not to solve any business problem, not to create any value.
The Human Cost
This complexity is not merely an aesthetic problem. It has concrete, measurable consequences.
For beginners, the learning curve is now measured in months, not days. A student in Abidjan who wants to learn web development does not face a knowledge problem -- the information exists. They face a tooling problem. Before they can write Hello
For professionals, the daily experience of web development has become one of configuration, not creation. A senior engineer at a Fortune 500 company spends more time updating dependencies, resolving version conflicts, and migrating between framework versions than building features. The phrase "it works on my machine" has not gone away; it has merely evolved into "it works with this exact combination of package versions."
For businesses, projects take three times longer than they should. Technical debt accumulates from day one -- not because engineers write bad code, but because the foundation beneath them is a stack of 47 independently versioned tools that were never designed to work together. Hiring is a nightmare because every team uses a different combination of the same categories, and "React experience" means something different at every company.
For emerging markets, the situation is catastrophic. Downloading 1.5 gigabytes of node_modules on a connection that averages 2 Mbps takes hours. Every npm install costs real money in mobile data. Unreliable power means that a long build process -- which might take 30 seconds in San Francisco -- risks losing work entirely when the electricity cuts out. The gap between "developed" and "developing" is not about talent; it is about bandwidth.
The Root Cause
The problem is not React. React is an excellent UI library. The problem is not npm. npm is a competent package manager. The problem is not TypeScript, or Tailwind, or Prisma, or any individual tool.
The problem is that we are building with Lego blocks that do not fit together.
Each tool solves its own problem in isolation:
React solves UI reactivity
Prisma solves database access
Express solves HTTP routing
Redux solves state management
Tailwind solves styling
Vite solves bundling
TypeScript solves type safetyBut none of them solve the actual problem: building an application. You still have to wire them together. Configure them. Keep them compatible. Update them when they break. Rewrite your glue code when one of them releases a major version with breaking changes.
The JavaScript ecosystem did not set out to create this mess. It evolved organically, one reasonable decision at a time. Each tool was a genuine improvement over what came before. But the cumulative effect is a Rube Goldberg machine -- an astonishingly complex apparatus that, after all its gears and levers and pulleys, produces the same output that a single HTML file produced in 1995.
The Question That Started Everything
Sitting in Abidjan, staring at yet another npm install progress bar, Thales asked a question:
What if there was a single tool that just... built apps?
Not a framework. Not a library. Not a "better JavaScript" or a "Rust-based bundler" or a "type-safe ORM." Those are incremental improvements to a fundamentally broken architecture. They make the Rube Goldberg machine slightly more efficient without questioning why the machine exists.
What if, instead, you had a programming language where building a web application was as simple as it was in 1995 -- but with all the power of 2026?
What if you could write this:
todos = []
newTodo = ""entity Todo { title: text done: bool = false }
My Todos
{for todo in todos}
Save it as app.flin. Run flin dev. Done.
No package.json. No tsconfig.json. No bundler configuration. No ORM setup. No database migration. No state management library. No seventeen-step initialization process. One file. One command. A complete, working, database-backed todo application.
That is the question that started FLIN.
Why a Language, Not a Framework
The first instinct, when faced with complexity, is to build a better framework. A framework that bundles the right tools, pre-configures them correctly, and hides the seams. This is what Next.js did for React, what Nuxt did for Vue, what SvelteKit did for Svelte.
Frameworks help. But they do not solve the underlying problem because they are built on top of the existing stack. Next.js still requires Node.js, still uses npm, still pulls in hundreds of packages, still generates a node_modules directory that weighs over a gigabyte. The complexity is hidden, not eliminated.
A language is different. A language defines its own rules from the ground up. It does not need to accommodate the decisions of 47 other tools because it is the only tool.
Consider what FLIN eliminates by being a language rather than a framework:
What a framework must accommodate What a language can eliminate
----------------------------------- ---------------------------
Node.js runtime No runtime dependency
npm package manager No package manager
TypeScript compiler Built-in type system
Bundler (Webpack/Vite) No bundler needed
ORM (Prisma/Drizzle) Built-in entity system
State management (Redux) All variables are reactive
CSS framework (Tailwind) Built-in styling
Test runner (Jest) Built-in testing
Config files (15+) Zero config filesA framework is a set of opinions about how to use existing tools. A language is a set of opinions about how to think about problems. The difference is fundamental.
Why We Were the Ones to Build It
Two factors made it possible for us to attempt this.
First, the CEO-AI CTO model. Building a programming language is traditionally a multi-year, multi-team effort. The Rust compiler has hundreds of contributors. TypeScript has a dedicated team at Microsoft. We had two: Thales, the CEO of ZeroSuite, making architectural and product decisions, and Claude, the AI CTO, implementing them at the speed of thought.
This model -- one human with deep product intuition and market understanding, one AI with unlimited patience for compiler theory and systems programming -- is uniquely suited to language design. Thales could articulate what the language should feel like for a developer in Abidjan or Lagos. Claude could translate that feeling into a lexer, a parser, a type checker, and a code generator.
Second, the African perspective. Most programming languages are designed in environments with fast internet, cheap storage, reliable power, and abundant engineering talent. FLIN was designed in Cote d'Ivoire, where none of those assumptions hold. This is not a disadvantage; it is a design constraint that produces better software for everyone.
When you design for a developer who has 2 Mbps and pays per megabyte, you produce a language with zero dependencies and a single binary. That language also happens to be better for a developer in San Francisco who is tired of waiting 45 seconds for their Next.js development server to start.
When you design for a student who has never seen a tsconfig.json, you produce a language where one file is enough. That language also happens to be better for a senior engineer who has configured a thousand tsconfig.json files and would rather not configure another.
Constraints breed innovation. And the constraints of building software in West Africa are exactly the constraints that the global web development ecosystem needs imposed on it.
The Name
FLIN is not an acronym. It is a word from Fongbe, a language spoken in Benin, Thales's country of origin.
In Fongbe, the phrase "E flin nu" means "It remembers things." The elephant -- sacred in Beninese culture -- is the animal that never forgets.
The name captures the core architectural insight of FLIN: memory-native design. In FLIN, every entity automatically tracks its history. You can query any record at any point in time. The language itself remembers everything, just as the elephant does.
// Save a user
save User { name: "Juste", email: "[email protected]" }// Later, query the user as they were yesterday user @ yesterday
// Or two versions ago user @ -2
// Or on a specific date user @ "2025-06-15"
// Or see every version that ever existed user.history ```
We will tell the full naming story in the third article of this series. For now, know that the name is not a marketing exercise. It is a design philosophy encoded in three syllables.
What Came Next
The question -- "What if there was a single tool that just built apps?" -- was asked in late 2025. On January 1, 2026, we started building the answer.
The first session lasted 45 minutes. We created the Rust project structure, defined 42 keywords, implemented 60+ token types for the lexer, and wrote 25 unit tests. The project was called flin-official, and it compiled on the first attempt.
flin-official/
Cargo.toml
src/
main.rs
lib.rs
lexer/
mod.rs
token.rs # 650+ lines, 42 keywords, 60+ token types
parser/mod.rs
typechecker/mod.rs
codegen/mod.rs
vm/mod.rs
database/mod.rs
server/mod.rs
error/mod.rs
examples/
counter.flin
todo.flinTwelve files. A thousand lines of Rust. The skeleton of a programming language that would replace 47 technologies with one.
This series documents how we built it -- every architectural decision, every code snippet, every hard-won lesson. Not as a retrospective, but as a blueprint. Because the next FLIN might come from a developer in Lagos, or Nairobi, or Dakar. And when it does, they should not have to start from zero.
---
Next in the series: [47 Technologies Replaced by One Language] -- What if you could delete React, Next.js, Redux, Prisma, Express, Tailwind, and 41 other tools?