A Polish handwriting companion for my son, powered by local AI

Built for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

My son is eight. He reads and types in Polish, practises joined-up handwriting on paper, and has a Windows PC and a printer. I wanted to help him practise the movement behind a letter: where the pencil starts, which way it travels, and how one letter connects to the next.

I also wanted his practice tool to work without internet during use. A Polish question should not require a cloud account or a connection to a hosted chatbot.

That led to Literkowy warsztat, roughly “Letter Workshop”: a small Windows application with a Polish interface, animated movement demonstrations, printable A4 exercises, and a local AI assistant that interprets handwriting questions.

The first pack contains a, o, m, n, l, e, ą, ma, la, and mama. It is deliberately small enough to inspect. The child can:

• Choose a letter or connected form and replay its movement.
• Read the corresponding Polish instructions.
• Print tracing, copying, and independent-practice rows.
• Type a question or ask for an easier exercise.
• Load a photo, rotate or crop it, compare it with the example, and choose what to practise next.

We did not have a worksheet from his school. The movement paths and instructions are therefore an original practice model informed by public references, including Primarium’s overview of Polish handwriting. They have been technically checked and visually inspected, but have not been approved by a teacher or verified against his school’s exact model.

Demo

Open the interactive GitHub Pages demo.

No installation or video is needed to explore the demonstration:

1. Choose a and replay its movement.
2. Click Show recorded Qwen example to see an actual response captured from the local Windows app with m selected.
3. Prepare an A4 worksheet and print it or save it as PDF.
4. Load a non-personal photo, try rotation/cropping, and select a guided observation.

The public website is a static demonstration. It uses authored hints and one clearly labelled recorded local-model response. It does not run Qwen live. The downloadable Windows application runs Qwen locally after parent setup.

The recorded model-backed prompt is:

Ołówek zatrzymuje mi się przy drugim garbku.

That means, approximately, “My pencil gets stuck at the second hump.” With m selected, the local model interpreted the request as an explanation of its movement steps. The application then displayed the authored Polish instructions for that card.

Photo feedback is guided by the child’s or parent’s observation. The image remains in browser memory and is not sent to the model or uploaded. A finished photo cannot reveal stroke direction, stroke order, pencil pressure, or grip. Public-demo worksheet metadata stays in this browser’s local storage.

Code

Source repository: gdziadkiewicz/literkowy_warsztat

The repository includes Windows setup/start scripts, the original movement pack, evaluation commands, source notices, and a sample A4 worksheet. Our application code and original content use the MIT license. Model weights and runtime binaries are downloaded separately and are not committed.

How I Built It

The application is a small Python/FastAPI service with plain HTML, CSS, JavaScript, and SVG. It runs on loopback, so the browser interface and application service stay on the same computer.

The movement pack is shared between the animation and printed worksheet. That matters: the starting point, sequence, and route shown on screen should agree with the paper exercise. Generating a plausible-looking letter image would not give me that consistency.

For language interpretation, the app uses Qwen3 4B through Ollama, running locally. The model selects an intent, a supported card, a topic, and a difficulty level. The application validates those choices before rendering the corresponding authored instructions.

This is the actual response contract from the application:

class ModelDecision(StrictModel):
    intent: Literal["explain", "practice", "easier", "unsupported", "clarify", "break"]
    card_id: CardId
    topic: Literal["steps", "start", "direction", "size", "spacing", "joins", "marks"]
    level: Literal["easy", "regular"]

A preliminary direct-classification probe misrouted several questions. That changed the design: common explicit requests use predictable routes to the content pack, while less explicit wording can reach the local model. The model chooses from the allowed catalog; it does not invent new letter shapes or rewrite stroke directions.

The runtime configuration also stays explicit:

Application: 127.0.0.1:8765
Ollama:      127.0.0.1:11435
Model:       qwen3:4b
Cloud mode:  disabled

Initial parent setup needs internet to download dependencies, Ollama, and the model. Ordinary use is designed to stay local. Worksheet history and selected observations are stored in local SQLite; raw questions and photo files are not stored in that history.

What I checked

The eight authored Polish evaluation cases passed: seven used reviewed routes, and one exercised Qwen3 locally. The model-backed case took about 4.2 seconds in the final recorded run; an earlier warm-model run took about 0.8 seconds. That is a small smoke set, not an independent benchmark or proof that all Polish phrasing works.

A browser smoke check generated the sample A4 PDF and exercised synthetic photo upload, rotation, and cropping without reported JavaScript errors.

A deliberate whole-PC run with internet disconnected, physical print review, and parent/teacher content review remain outstanding. My son has not yet provided feedback, so I cannot claim improved handwriting or a successful child trial.

Why Does Open Innovation Matter?

Running an open-weight model locally makes it possible to interpret Polish questions without sending them to a hosted AI provider. The family can inspect the application’s behavior, replace the model, and extend the movement pack.

There are practical costs: the model download is substantial, first-response latency varies, and small-model interpretation needs testing. If the model is unavailable, movement demonstrations and worksheets remain usable.

The most useful design decision was keeping flexible language interpretation connected to a finite, inspectable set of movements and instructions. That gives the assistant room to understand wording while preserving the content the child is meant to practise.

Community Wisdom

Two community reports helped frame the approach:

• FamiliaSync’s “Teaching our on-device assistant to say ‘I don’t know’” describes real intent misrouting and the need to handle unsupported requests. It reinforced the importance of checking actual phrasing and providing constrained fallbacks.
• Charles-Antoine Fournel’s report on local-model memory costs discusses memory and download tradeoffs on Android. Those device-specific results do not establish Windows performance, but they reinforced the need to measure the actual installation and keep the model’s job small.

The next useful step is a parent-supervised paper session: inspect the letter forms, check the physical print, and see whether the instructions make sense to the person this was built for.

AI assistance disclosure: Codex helped implement the application and draft this post. The reported checks are implementation smoke checks; no recipient feedback has been invented.