Why I developed Askling
When I study, I notice a difference between recognising a familiar text and being able to explain a concept myself. A slide can feel clear on the second reading. When I try to describe the connection to someone without looking at it, the gaps become visible. Askling gives that moment a defined place in the study routine: the learner has to put an idea into their own words.
The idea connects my work on learning software with a question I also encounter as a teaching assistant: how can I encourage someone to formulate a thought themselves? The AI takes the role of a curious counterpart. It asks about a term, a connection or a reason. I respond in my own words and receive follow-up questions or feedback on my explanation.
My contribution covers the product concept, learning workflow and implementation: importing materials, generating a plan, designing the conversation view and storing its state locally. Askling is the independently usable, self-hosted version of this approach. It is distinct from the separately planned managed TeachBack AI offering. This case study describes the public Askling repository only.
From a PDF to an explanation of my own
The workflow starts with personal course materials. I select searchable PDFs, enter a subject and specify the available study period. Askling extracts the text on the device and adds document names and page headings. The next stage uses that text: a language model generates daily sections containing a topic, summary and material context. The plan is saved locally and can then be opened.
A study day leads into a conversation view. Questions refer to the selected material and ask the learner to describe or explain it. For object-oriented programming, a suitable question might be: why is a shared interface useful when different classes perform the same task in different ways? This illustrates the intended type of question; it is neither a recorded conversation nor a promise of a model's exact wording.
The interface keeps the main question, answer and follow-up messages together, making it easier to see which explanation a response refers to. The plan, progress and conversation history live in the same application. The workflow is intended to make it easier to start explaining rather than postponing it. Whether that improves exam results cannot be inferred from an implementation alone.
The central product decision: independent use
For Askling, I chose an architecture without a central user account or an application server of my own. The first-run screen configures the AI provider and then opens the dashboard. There is no registration with a service operated by me. People who run the application themselves also decide which model endpoint it uses for plan generation and tutoring.
This reduces the infrastructure needed for a personal study workflow. It also moves responsibility to the person using the device: configuring a provider, understanding its costs and looking after local data. A local database does not provide automatic synchronisation between a laptop and a phone. Those limitations are part of the product and should be clear before someone starts relying on it.
The architecture suits a personal tool and people who want control over their study setup. It does not imply that every calculation works without a network. Requests to an external AI provider need a connection. A local model endpoint can also be configured, but setting up that runtime and establishing whether its model is suitable remain separate tasks.
How the application is structured
Askling is implemented in Dart with Flutter. Screens and their state are organised by feature: setup, dashboard, planner, plan details and study session. Riverpod connects these views to repositories and services. Shared logic for PDF processing, plan generation and model requests sits outside the individual screens. A provider communication problem can therefore be handled in one shared service rather than separately in every view.
Hive provides local storage. Plans, study days, messages, profile information and extracted document text have separate storage areas. On the web this uses browser storage; on other platforms the database lives in the application's data directory. Local storage is not an automatic backup. Clearing browser data or losing a device can affect the study history, so those are distinct concerns.
Provider configuration uses flutter_secure_storage. Its actual storage mechanism depends on the platform, so I do not promise an identical key store everywhere. Credentials are entered at runtime and do not belong in the distributed app bundle. For this case study, the key architectural distinction is between local application data and communication with the configured model endpoint.
What stays local and what the AI receives
New PDF imports are converted locally into Markdown text with document and page labels. The original files are not retained for these imports and are not sent to the model as PDFs. The converted text remains available for generation and later retries. Page labels preserve a simple reference to the source, but they do not reconstruct complex tables or the original page layout.
During plan generation, the configured AI endpoint receives the prepared text and information such as subject and study period. Study sessions add the relevant material section and conversation content. Choosing an external provider therefore means sending content to that provider. Local storage and local computation are separate properties. The diagram shows this boundary explicitly rather than implying that all AI processing happens on the device.
The import requires searchable text. A scanned page without a text layer needs OCR first. Formulas, tables and unusual reading orders can also lose information during extraction. The generated study plan is consequently a starting point for personal study, not evidence that every page has been understood completely or correctly. Its content still needs to make sense against the original material.
A shared interface for different models
Askling includes presets for several providers and supports a custom endpoint. At the protocol level, I distinguish two request formats: OpenAI-compatible chat completions and Anthropic's Messages format. Similar product capabilities do not imply identical authentication, parameters or response structures. A shared LLM service handles these differences rather than distributing them across every screen in the application.
The output limit is a concrete example. The service uses a different parameter name for the official OpenAI endpoint than for compatible endpoints. Anthropic also requires its own message structure. These details are invisible in the study workflow, but determine whether a request is accepted at all. Tests exercise the differences with controlled responses and without real credentials or paid model calls.
Provider choice comes with a trade-off. Models differ in context size, response formatting, speed and quality. A tested adapter cannot guarantee that every arbitrary model will generate a useful plan. I treat protocol compatibility as a technical interface question and a model's educational suitability as a separate question. Both have to work for a particular deployment and its actual learning materials.
An incomplete response must not become a finished plan
Long plan generation can fail because of an output limit or a connection problem. Askling divides generation into batches of at most three study days. Each response is checked for the expected number and order of days and the required fields. If the provider reports a truncated output, the application rejects it rather than silently saving a shortened result as a completed plan.
The extracted Markdown remains available for a retry. A provider error should not force the learner to convert every PDF again. Reloading the browser during the original conversion is a different interruption: files that have not yet been saved may need to be selected again. These two failure modes require different explanations and recovery paths, even though both can look like a generation failure to a learner.
The conversation interface also treats model responses as content rather than arbitrary instructions to the application. For example, image URLs in AI-generated Markdown are rendered as alternative text instead of automatically loading remote images. These choices do not solve every risk in an AI application. They do make the data flow more predictable and remove an unnecessary additional network path.
What I checked in the current version
This case study is based on a recorded version of the public repository inspected on 16 October 2026. I compared the code for importing, local storage, model adapters and plan validation with its associated tests. A successful GitHub Actions run exists for the same commit. That correspondence matters: a green test result is useful evidence only when its relationship to the code being described is clear.
The tests cover different request formats, truncated or incomplete plan responses and reuse of document text after a provider failure. They use controlled test cases. That makes it possible to verify particular technical behaviours without paying for model calls or transmitting confidential lecture material. It also keeps the evidence narrower and more reproducible than a general statement that the AI works.
These checks do not establish educational effectiveness. The README contains broader metrics for which I did not find supporting study documentation during this research. I therefore do not repeat a percentage reduction in study time or an accuracy or success rate. The supported claim here is an implemented, technically checked application with an explicit learning workflow, rather than a measured improvement in learning outcomes.
What this project shows about my work
Askling connects product design with the engineering behind an AI interface. Its visible feature is a study conversation. Before that can be useful, files have to be read, context assembled, responses structured, state saved and failures explained. Those transitions shaped the project. They are also relevant to other software products where a model needs to participate in a dependable, understandable workflow.
For further development, I would start with small, traceable study tasks to understand which follow-up questions help and where models create false confidence. That means subject-reviewed sample conversations, realistic PDF imports and a clear distinction between technical operation and educational value. More providers or additional features become worthwhile when the basic workflow has been assessed against those concrete examples.
The source is publicly available under the PolyForm Noncommercial License 1.0.0. I therefore describe Askling as source-available for noncommercial use. The repository provides a way to inspect the implementation and experiment within its licence terms. On my website, it is a concrete example of turning a learning idea into a connected product with technical decisions that can be examined.