Build in public · 2 min read

Building Fylune in public: the first useful loop

What we are shipping first, what we are deliberately postponing, and how we will know the product is earning trust.

Fylune Team

Fylune begins with a narrow promise: open an ordinary project folder, write comfortably, and let an external AI help without losing control of the source files.

The current Fylune feature set starts with local files, offline editing, a free core editor, automatic asset paths, and complete Markdown rendering. Safe AI review comes after those foundations.

The first loop

  1. Open a real local folder.
  2. Navigate its existing structure.
  3. Create or edit Markdown and MDX.
  4. Review changes before an agent-written update lands.
  5. Recover cleanly when the source changed underneath the proposal.

This loop is intentionally smaller than “an operating system for all knowledge.” It is also something we can test with real work every day.

What waits

Accounts, billing, team administration, and cloud sync come later. The architecture leaves room for them, but none is allowed to become a dependency of local editing.

The trust test

The product is working when people are willing to open a folder they care about, not a disposable demo project, and still understand exactly what Fylune is doing.

What we measure first

Early success is behavioral, not theatrical. People should be able to create and edit real files, move between documents, paste an asset without repairing its URL, and reopen the project in another tool. The free local editor must remain useful without an account.

We are not treating waitlist size as proof that the product loop works. A closed alpha gives us a smaller and more honest test: do people trust Fylune with a folder they already depend on?