Hendril Lara
All work

Agentic loops / Lucentive

Icarus

An app factory where agents build and a person gives the final go

Icarus is an app factory run by AI agents. They pick a category, name a gap the leading apps leave open, write a spec, then build the app and check it against that spec; a person gives the final go. It is in development and runs locally: no app has reached a store, and publishing is not built yet.

Product direction, concept & architecture: Hendril Lara. Implementation: Lucentive engineers.

My part
Idea, concept, architecture and project lead
Status
In development, not yet published
Stack
Python, FastAPI; apps in Flutter or web
Since
2026
Flat illustration of a single glass bell jar on a dark bench: inside, three small boxy agent figures assemble an app in mid-air, fitting interface screens and blocks into a phone-shaped frame, one on a scissor lift, one with a caliper; a red lamp on top of the jar, off; nothing else around.
Artwork in Icarus’s identity: agents assemble an app inside the chamber while the red lamp waits for the one human check.

What it is

Icarus is a production line that turns a market gap into a working app, with several apps moving through it at once. Agents choose a category inside the limits the operator sets, study the leading apps there, name one thing none of them does well, and write a spec around it: the features, how each one is judged done, and what the app must not become.

From then on, the work is held to that spec. An advisor agent scores and trims the idea, a builder writes the app feature by feature, automatic checks compare each feature with the spec, and the finished build waits for a person, who approves it or sends it back.

Diagram of ten steps on a dark background: Find a niche, Study the rivals, Name the gap, Write the spec, Advisor review, Plan, Build and check, Test, A person decides (outlined in red, with a red lamp), and Publish, marked Not built yet. A dashed red arrow runs from the person’s decision back to Build and check.
Diagram: one app through the line, drawn from Icarus’s own documentation.

Who it is for, and my part

Most app ideas die between “interesting gap” and “working app”, because finding the gap, shaping a focused product and building it is slow. I wanted a repeatable way to get from one to the other, without turning out the low-effort clones that app stores rightly reject.

I came up with Icarus and defined its shape: the steps, the spec as the single source of truth, the checks that keep a build honest, and the one human decision before release. I led the project, and Lucentive engineers built it with me.

  • Every app must trace back to a named gap, or it does not get built.
  • Each agent role can run on a different AI model, including free ones that run locally.
  • Spending caps per app and overall, plus one switch that stops everything.
  • A finished app can be handed to Loop, our marketing system, as a campaign brief.
The Icarus console on one app called TrueMatch Pantry: rows for why this niche, the competitors, the gap, the differentiator and the spec name, then the spec’s four features with must and should priorities, their acceptance criteria and the non-goals.
The operator console: the niche, rivals and gap the agents found, and the spec they wrote.

From a gap to a spec

The screens on this page come from one run on my machine, with a large hosted AI model in every role and a spending cap of a few dollars. From the allowed categories it chose cooking, listed three recipe apps already there, and settled on a gap: they suggest recipes that need ingredients you do not have, or send you to pages full of ads. Its answer was an app that shows only what you can cook with what is in your pantry right now. The discovery agents reason from what the model knows; live app-store data is not connected yet.

The spec is the source of truth. Each feature has a priority (must, should or could) and a plain test of what done means, and the spec lists non-goals so the app cannot grow beyond its idea.

Built one feature at a time, checked against the spec

The builder does not write the whole app in one go. It lays a foundation, then adds one feature at a time, and after each one automatic checks look for drift from the spec, screens nobody can reach, placeholder code and errors when each page opens in a real browser. A feature that fails gets a few rounds of fixes before the line moves on, and every step is timed and logged.

Apps come out as Flutter apps for phones or as plain web apps. Stronger models design each app from scratch; small models start from a guided layout.

Lower part of the same app page: the advisor’s strengths, risks and guidance to the builder with a pass verdict, a table of every stage with its result, cost and time, and a timeline of transitions from discovery to awaiting human.
Every step logged: the advisor’s review, each stage’s result, cost and time, and the app’s path to the gate.
The app page at the gate: a red banner reading Build did not verify, with approval disabled and a Send back to Builder button, controls to pause, retry, test the app and quarantine, and a dark console log of the build and its two rounds of fixes.
At the gate, the checks found one unreachable screen and one placeholder feature, so approval stays off until the builder fixes them.

One human decision

When an app clears its checks, it stops at the gate, under a red banner. The console shows what was built, how it matches the spec and the full log, and lets the person open the app to try it. Approving marks the app ready to publish, though the publishing step itself is not built yet; rejecting sends it back to the builder, with notes if the person writes any. The gate refuses to approve a build that failed its checks, and no setting turns it off.

The run shown here is the gate doing its job. The builder finished three of the four features, and the checks found one screen that could not be reached and one feature left as a placeholder. So the console marks the build unverified, switches approval off and offers only to send it back to the builder.

Where it stands

Icarus is in development and runs locally. Everything up to the human gate works end to end, along with budgets, alerts and the stop switch. It has produced working web apps, one of them wrapped as an Android test build and run in an emulator, and a small 3D game.

Not built yet: creating a code repository for each app and publishing to the app stores, which need real store accounts and signing. Live app-store data for discovery is planned, and the handoff to Loop has only run in test mode.

Diagram with three columns: Built, works end to end; Tried, not routine, proven once or in test mode; Planned, not built yet. Each column lists the parts of Icarus in that state.
Diagram: what is built, what has been tried, and what is still planned.
The generated app at phone width: the heading Ready to cook?, the line 100% match recipes based on your pantry, one recipe card for egg fried rice with a 10 minute badge and a 100% Match badge, and a bottom bar with Cook and Pantry tabs.
The app the line built, opened in the console’s test mode at phone width. Recipe photos come from Unsplash.

Next project

Acesa Explore a building, step inside an apartment and understand the space before a visit.

Interested in something like this?

Let’s talk about it.

Let’s talk