Noeta

Your notes become a deck that tells you what it does not cover, writes cards for what you got wrong, and brings each one back before you forget it.

Comment

What it does

You give Noeta the material you actually have to learn: pasted notes, a PDF or slide deck, a photo of a page, a recording, or a link to an article. About a minute later you have a deck of flashcards, a quiz that tells you what you missed, and a schedule that decides when each card comes back.

Three things make it more than a generator.

The schedule is per card and per person. Grading a card as hard moves that card for you and for nothing else, using FSRS over the card's whole history rather than its last answer.

The deck answers back. Get a quiz question wrong and the deck writes new cards for what you missed, into the same deck, scheduled with the rest. Meet a card that is pitched badly and you can ask for it in plainer words, mid-session, and the rewrite is stored rather than shown once.

It tells you what the deck does not cover. A deck can be studied to the last card and still leave you unprepared, because the deck was never the whole subject. Noeta maps a deck against the topic list it infers for that subject and says which topics are missing, and it says out loud that the list is inferred rather than an official syllabus.

How we built it

One FastAPI service on Cloud Run serves the API, the browser client, the public deck pages and the landing page from a single image. Gemini through Vertex AI does the reading and the writing. Firestore holds decks, schedules and purchases. Firebase verifies accounts. Secret Manager holds the keys.

The browser client has no build step. It is ES modules served as files, so what runs in the browser is what sits in the repository.

The repository starts on 3 July 2026 with an empty Python package and grows over 251 commits, carrying 824 unit tests and a browser suite that drives the shipped client rather than a copy of it. No product template or starter kit was used. The dependencies are named in pyproject.toml and are ordinary libraries: FastAPI, pydantic, pypdf, python-pptx, python-docx, the Google GenAI client, firebase-admin and an FSRS implementation.

AI that runs the business, not just the product

Four agents have taken 97 decisions in production between 29 July and 17 August, and every decision any of them takes is written to a log the public can read at /ops. Open it before you read the rest of this: blueprint 54, tutor 31, curator 9, growth 3. The count moves while you are reading, because the curator wakes on a schedule; the page is the source, not this paragraph. The page names only the agents that have actually acted, so it cannot claim more than has happened:

  • tutor rewrites a stored flashcard when a learner says it is not working, and writes new cards for the questions a learner missed. It changes the product's own data, not a chat reply.
  • blueprint maps a deck against the topic list it infers for that subject and records the coverage it found.
  • growth decides what a public deck page should say about a deck: its title, its description and its opening paragraph.
  • curator re-evaluates the catalogue every six hours on a scheduler and picks what the front page puts forward, with its reasoning recorded.

A fifth, support, answers a question about the product from the product's own behaviour. It fires when somebody asks, and nobody has yet, so it is absent from the log rather than padded into it.

The log records the agent, the decision, what it was given, and when. It is the same log the operators read, published rather than paraphrased.

Check two things before you believe any of it. The curator fires on a Cloud Scheduler job every six hours whether or not anyone is watching, so the catalogue keeps changing through a month of judging with nobody at the desk. And each agent writes to the product's own data: the cards a learner studies tomorrow, the copy on a public page, the coverage map a deck shows. None of them hands a human a draft to approve.

Category impact: Education and Human Potential

Noeta has no graduation stories. It has not been in enough hands for long enough to have any, and I would rather say that than dress up three friends as a cohort.

Here is the problem it goes after. You can finish a deck, feel ready, and sit an exam that asks about the third of the subject your notes never covered - the deck was never the syllabus, and nothing told you so. Noeta maps a deck against the topics it would expect a course on that subject to include, shows you which ones the deck leaves out, and says on the page that this reading is its own guess rather than an official curriculum. Miss a quiz question and the deck writes cards for what you missed, then schedules them with the rest.

What it costs a learner to find that out: nothing. No account, no card, no install, two decks a day on the free plan, a sample deck one press from the landing page, and public deck pages anyone can read with a link. Your material can be a lecture, a PDF, a photo of a page or a link, which matters most for whoever has notes and no textbook.

On the phone

An Android client is built and runs against this same service: fourteen screens in Jetpack Compose, covering onboarding, the study loop, the session screen, sign-in and the plan, wired to the engine through the same API the browser client uses. It carries its own test suite, including screenshot tests that hold it to the brand the web pages use.

It is not in the Play Store yet. The developer account is open and the release work is under way; there is no signing key, no listing and no track so far, so the honest status is a client that works and a release still being prepared. We would rather say that here than let a screenshot imply otherwise, and we are not going to promise you a date.

The web app closed the gap in the meantime. Noeta installs to a phone's home screen from the browser: it ships a manifest, its own icons and a service worker, opens without an address bar, and carries the paper colour into the phone's own chrome. On a phone that is one press from wherever a student keeps the rest of their work, with nothing to download. The worker deliberately holds no cache - a cached client can outlive the API it was written against, and a student meeting that would see a broken deck with no way to tell why.

What our Gemini bill looks like when this works

A business that runs on model calls should be able to say what one costs it, so we measured it twice: once per call, and once against Google's own meter.

Per call. Every Gemini response carries a usage block, and the service adds it up per task. Measured in production on 16 August, one deck built from a short paste of notes: two Gemini calls, 1,730 tokens - 245 in and 1,086 out to write the cards and quiz, 210 in and 189 out to name the concepts they test. At the published rate for gemini-2.5-flash that deck costs us about a third of a US cent. A Pro subscriber who hit the daily cap every day for a month would build 450 decks and spend roughly 1.50 dollars of Gemini against a GBP 4.99 subscription.

Across the whole service. Cloud Monitoring, which is Google's count rather than ours, records 5,911,462 tokens over 465 model invocations in the thirty days to 17 August: 5.43M on gemini-2.5-flash and 484k on gemini-2.5-flash-lite. Most of that is our own browser suite and demo recordings rather than demand, and we are not presenting it as traction. It is there because it is the number a judge can verify.

One caveat on our own meter, since the submission points at it: /internal/usage reports the Cloud Run instance that answers, not the whole service, so a reader can land on an instance that has served no generation and see zeros. That is why the evidence pack quotes Cloud Monitoring instead.

Two caveats on the cost itself. The per-deck measurement is one deck from a paragraph of text; a sixty-page lecture PDF reads longer and costs more, and we have not yet measured the spread. And the arithmetic uses Google's list price rather than an invoice, because trial credit means we have not been billed yet.

That matters for the shape of our demand on Gemini, which is not one call per signup. The curator re-reads the catalogue every six hours forever. Every quiz a learner fails asks the tutor for new cards. Every deck built asks blueprint for a coverage map, and every public page asks growth for its copy. Our token use follows retention and library size, so a learner who stays through an exam season costs us more model calls in month three than in month one - and pays for them monthly.

The stack is Google's on purpose, and not shallowly: Gemini through Vertex AI, Cloud Run, Firestore, Firebase Authentication, Secret Manager, Cloud Scheduler for the curator, Cloud Build and Artifact Registry for deploys. There is no second cloud to fall back to and no abstraction layer waiting to be pointed somewhere else. Trial credit covers today; the GBP 4.99 subscription is what covers the calls after it, which is why the price went up on the plan screen before a single deck had been sold.

Who does what, and who else this could pay

What the agents do, day to day. Gemini reads the learner's material and writes the flashcards and the quiz. It names the concept each card tests, which is what the mastery map is built from. When a learner says a card is not working, it rewrites that card in place. When a learner misses quiz questions, it writes new cards for exactly those and files them into the same deck. Every six hours, whether or not anyone is watching, it re-reads the catalogue and decides what the front page puts forward. When a deck gets a public page, it writes the title, the description and the opening paragraph a stranger reads first. None of that passes through a person. There is no review queue in this product: the agents write to the data a learner meets tomorrow.

What the human does. Decides what to build and what to refuse. Sets the price and the caps. Writes the brand and the words on the pages. Chooses that a coverage map must say out loud that its topic list is inferred rather than official, because a confident wrong syllabus is worse than none. And carries it when an agent is wrong, which is why the decision log is public rather than internal.

Jobs created so far: none. No employees, no contractors, nobody paid a fee. That follows from having no revenue, and we would rather write the zero than dress up a solo project as a team.

Where money would first leave this business for somebody outside it. Not a headcount projection, but the mechanism the product already has.

Deck authorship is the first one. The catalogue exists, the public deck pages exist, and the curator already decides which decks earn the front page. Paying a teacher or a tutor for a deck that earns its place there is a pricing decision on machinery that is already running, not a new product. A subject teacher who has spent years making materials owns something this catalogue wants, and the curator already measures which of it people study.

Tutoring is the second, and it is enabled income rather than a job we create. A tutor meeting a new student spends the first sessions working out what that student's own notes leave uncovered. That is the judgment the coverage map makes in about a minute. A tutor who uses it reaches the useful part of the first session sooner and can carry more students in the same hours.

The learner's own economic opportunity is the qualification they are sitting for, and we are not going to claim credit for it. What we can honestly say is what it costs them to try: nothing. No account, no card, nothing to install, two decks a day free, and public deck pages any study group can read from a link. That matters most for somebody with notes and no textbook, which is the common case outside well-funded schools.

The story of building it this way. One person, from 3 July to 17 August, 251 commits. The agents were not built to be impressive; they were built because a business with one person and no revenue cannot staff a merchandiser, a copywriter or a support desk, and those jobs still have to be done every day. So the catalogue is merchandised by an agent on a schedule, the public pages are written by an agent, and support that would have been a reply is instead a change to the learner's own cards.

The same arithmetic set the guardrails. An agent with a budget and nobody watching is how a founder wakes up to a bill they did not choose, so a daily generation ceiling stops the whole service rather than trusting the agents to be reasonable. And the token meter exists because a business that runs on model calls should be able to state what one costs: two calls and 1,730 tokens for a deck, about a third of a US cent.

Challenges

The failures worth naming are the quiet ones.

A transcript library changed its interface in a major version. Every test in that module injected its own fetch, so the one function that touched the library was never run by anything, and the whole video path died in production while a thorough-looking suite stayed green. It is now tested against the real class by name.

YouTube declines to hand captions to requests from a datacentre. The code normalised every provider error into one, so a refusal aimed at our server was reported to the learner as a fact about their video: "that video has no captions we can read", about a video with captions. The two are separate now, and the message says which happened.

The browser suite looked flaky for two days. The cause was measured rather than guessed: the first call into the token verifier costs about 24 seconds while it fetches signing keys, and that landed inside the client's own 30 second deadline. Warming the verifier before the browser needs it turned an intermittent suite into a clean one.

What we learned

Silent success is the expensive failure mode. A screen that renders empty, a message that blames the learner's material, a deck named after a filename, a token meter that reports zeros because it is counting the wrong instance: none of these raise an error, and all of them are the product being wrong at the person reading it. Most of the engineering here goes on making failures say what happened.

What is next

Three things, in the order they matter to a learner.

First, progress that spans decks instead of stopping at one. Every concept a person has met lives in the model already; what is missing is the screen that puts them in one place and says which ones come back this week.

Second, a video route that does not depend on our server's address. YouTube declines to hand captions to a datacentre, so a learner with a lecture link gets a refusal we cannot fix from where we stand.

Third, accounts we can count. The free allowance is keyed to an account today, which means it counts addresses rather than people, and we would rather know the real number before we tune the price.

Built With

Share this project:

Updates