StickHive

Problem

A student juggling coursework, an organisation role and a part-time job takes notes in whatever fragments time allows: three lines during a lecture, a pasted wall of text, a voice memo on the walk home. The notes survive; the meaning does not, because a hurried capture has no structure, no course attached and no link to the deadline it belongs to — and the deadline lives in the campus LMS, in a different tab.

Constraints

• Competition rules: no UI framework and no CSS framework — the interface is hand-written.
• Shared hosting with no native modules, so persistence runs on SQLite through the runtime's own module rather than a compiled driver.
• Provider API keys live only in the backend environment; nothing sensitive may reach the frontend.
• Free tiers are metered per input method, so the quota is part of the product, not an afterthought.
• When no AI key is configured the features must degrade into something honest rather than failing loudly.

Decisions

1. Read the campus Moodle schedule one way only, and never write anything back to it.

   rejected Two-way sync that marks work done in both systems.

   The LMS is the institution's system of record; an app that writes into it can corrupt an academic record, and two-way sync means owning conflict resolution for data I do not control. One-way read plus a deep link gives the AI the real deadlines and course names while every submission decision stays in Moodle where the lecturer expects it.

2. Do the Moodle fetch from the student's own browser and keep only the resulting schedule server-side, with the password never leaving the browser.

   rejected Store the student's Moodle credentials and let the server log in.

   The campus blocks datacenter IPs, so a server-side login would not work anyway — but the stronger reason is that storing a student's institutional password to save an API call is a bad trade at any convenience. The password is used once, in the browser, to mint a session token; the token is stored encrypted and the account stays separate from the StickHive account.

3. Three input methods with their own metered quotas, and make the quota visible in the header.

   rejected Voice-only capture, which is the interesting feature.

   Voice is the fastest path when it works and the most fragile when it does not: a noisy room, a 25MB limit, a rate-limited transcription provider. Manual entry costs nothing and always works, the AI tidy-up costs a model call, and recording costs the most — so the tiers follow the real cost of each path, and showing the count in the header means the student is never surprised by a refusal.

4. Degrade gracefully with no API keys configured: keep the raw note in the Inbox with a warning toast rather than blocking the capture.

   rejected Disable the AI features when the key is missing.

   The worst outcome for a capture tool is losing the two sentences someone typed in a corridor. Saving the raw text and saying plainly that the AI step is unavailable keeps the tool useful in every configuration — which is also what makes the app demonstrable without handing a judge an API key.

The hard part

Keeping the note, the course and the deadline from drifting apart. The AI can only structure what it is given: without the schedule it invents plausible course names and wrong dates, and a wrong deadline in a to-do list is worse than no deadline at all. The genuinely hard part was the context pipeline — fetching the schedule through the student's browser because the campus blocks datacenter IPs, storing it only for the structuring step, and keeping an account model where the institution's credentials never touch my server while the app still knows what is due on Thursday.

Outcome

• 3

  input methods: manual, AI-structured paste, voice or upload

• 0

  UI or CSS frameworks, and no native database module

• 1-way

  Moodle read with a deep link back — nothing written to the LMS

• Prototype

  built and submitted for INSPIRE 1.0

Read from the repository and the running app on 11 October 2026. This is a competition prototype, not a product with users: the account model, quotas and Moodle integration work, and the AI features fall back honestly when provider keys are absent. The screenshot below is the real signed-in app running locally, with real schedule entries synced from the student's own Moodle account, which is why the agenda looks lived-in rather than staged.

Figures and revisions

◎ Screenshot shows real synced schedule data

FIG. 1

source: StickHive local prototype · demo accountchecked: 11 Oct 2026