Platform Hub

Things we have built ourselves.

Two platforms, designed and engineered end to end by the team behind Ideally Us. They are where our advice comes from: real products, real constraints, and the mistakes we would rather you did not repeat.

Education · AI agents in the classroom

Hoklok 學樂An AI homework platform for Hong Kong primary schools where every worksheet is personalised to the child and every decision stays with the teacher.

SectorPrimary education, Hong Kong
BuiltJuly 2026, 48 commits
StackReact, Fastify, PostgreSQL, any LLM
StatusPilot‑ready

The problem

Ask a primary teacher what the job is and they will say teaching. Watch one for a week and you see worksheets written on Sunday night, forty scripts marked on Tuesday, scores copied into a spreadsheet on Friday. The teaching is squeezed by everything around it.

A child reads harder when the passage is about something they care about, but nobody has time to write four versions of Tuesday’s homework. And when a school applies for EDB or QEF funding, the impact evidence gets assembled from spreadsheets at midnight.

The tools on the market fix the wrong half. AI tutors talk to the student and leave the teacher out. Differentiation tools sort by reading level, not by what a nine‑year‑old is interested in. Adaptive systems let the software drive and shrink the teacher’s role.

What we built

Hoklok takes the production work off the teacher’s desk and leaves every decision on it. Students pick their interests from ten categories. The teacher fills one form: subject, topic, level, difficulty, question counts. The class splits itself by interest and the system drafts one themed variant per group, same skills, same difficulty, different passage.

Nothing reaches a child without sign‑off. Each variant lands in a review screen where the teacher edits wording, fixes options, changes marks, regenerates or rejects, then sets the release window. Objective questions mark themselves with a why‑right and why‑wrong for every option and the exact sentence in the passage as evidence. Written answers go to a marking queue.

Every answer is an event tagged with the skill it tests, so progress against each child’s start‑of‑term baseline builds itself. Each school gets its own database, and schools bring their own AI provider and key, encrypted at rest. Security hardening followed an external review: short‑lived tokens, rotating sessions, lockouts, audit trail.

  1. 01

    Students choose

    Ten interest categories, picked by the child. Space and science for one, food and cooking for another.

  2. 02

    Teacher briefs once

    One form sets subject, topic, level, difficulty and counts. A toggle produces a single common worksheet for tests.

  3. 03

    AI drafts variants

    One passage per interest group, identical skills and difficulty. Evidence that is not in the passage is dropped by the server.

  4. 04

    Teacher reviews

    Edit, re‑mark, regenerate or reject every item, then schedule release and closing time.

  5. 05

    Marking with evidence

    Objective questions self‑mark with per‑option feedback and the supporting sentence highlighted. Written work goes to the teacher.

  6. 06

    Progress builds itself

    Skill‑tagged events roll up into class gaps and each child’s trajectory against baseline. No Friday spreadsheet.

Where it stands

The full loop shipped in July 2026: tenancy, onboarding, generation, review, marking, analytics, a deployment kit and 79 automated tests. It is ready for first pilot schools, and the next build is the impact report that turns the progress data into the evidence a funding application needs.

What we learned

  • Keep the teacher as editor‑in‑chief. Review before release is the product’s position.
  • Make evidence structural. If a quoted sentence is not in the passage, the server discards the question rather than showing a wrong highlight.
  • Isolation and model choice sell. A database per school and bring‑your‑own‑key are unglamorous, and they are what a school can trust and budget for.
  • The buying trigger is measured impact. The data pipeline was built first; the report that consumes it is the most valuable piece still to build.
SectorLive events
BuiltJuly to August 2026
StackReact, Cloudflare Workers, Agents SDK
StatusWorking prototype

The problem

People who follow specific artists, comedians or scenes, often across more than one city, find out late. The comedian played two weeks ago. The band added a date and it sold out before you heard. For anyone who travels for shows, a late alert also costs the flight and the hotel.

The existing alerts are narrow. Music apps cover an artist near you. Ticket vendors alert you to one artist on one platform. None of them can express a real intention like any stand‑up in London in the next three months, and none cover comedy, theatre, talks and festivals in one place.

What we built

Zero FOMO turns the intention into a sentence with four slots, who, what, where and when, plus a channel and a cadence. The rule editor renders it as pressable tiles and backtests it before you save: this rule would have caught this many events in the last ninety days.

Matched events land on a radar that reads like a split‑flap departures board, grouped by month, each one linking out to its source. Zero FOMO never sells tickets. Artist rules alert instantly; category rules arrive as a morning digest; quiet hours hold everything until you are awake.

Behind it, a scout on Cloudflare Workers is designed to pull from Ticketmaster, Songkick, SeatGeek and Eventbrite plus an AI search for the gaps, then normalise, de‑duplicate and score every candidate against your rules. The AI resolves fuzzy intent, a British comedian, into actual names. You decide what counts: interested, dismissed, or got tickets.

  1. 01

    Write the rule

    Who, what, where, when, as tiles. Ten live rules free, a hundred on the paid tier.

  2. 02

    Backtest it

    See what the rule would have caught over the last ninety days before it goes live.

  3. 03

    The scout watches

    A daily run over four ticketing sources and an open‑web AI search, de‑duplicated into one catalogue.

  4. 04

    Match and score

    Every candidate is scored against your rules; fuzzy phrases resolve to real artists and venues.

  5. 05

    Alert on your terms

    Instant for artists, a daily digest for categories, quiet hours respected, email, push or webhook.

  6. 06

    You decide

    Interested, dismiss, or got tickets. Every event links to its source. We never sell the ticket.

Where it stands

Three design directions were explored in July 2026 and one, the split‑flap board, was taken to a working prototype in August: seven screens, the rule editor with backtest, alerts, quiet hours and pricing, all running client‑side. The matching engine and the scout backend are designed and scoped but not yet built, and the product has no users yet.

What we learned

  • The sentence is the product. Every design direction converged on one line, and the interface that made that line legible is what got built.
  • Decide the direction before writing code. Two visual systems and three flows in five weeks was cheap on paper and would have been expensive after.
  • Do not encode pricing before the value exists. Tiers and rule caps were finished before a single event had been matched.
  • Keep design tokens as one source of truth. Copying the token file verbatim kept the prototype and the design from drifting.

Book a 30‑minute call.

Tell us where you are. We will tell you honestly whether we can help, what it would take, and what we would do first. No pitch, no pressure.