DEV Community: Karan Raj

I built my mother a planting calendar that tells her what to sow this week

Karan Raj — Mon, 12 Oct 2026 06:21:26 +0000

This is a submission for the Hacktoberfest Week 1 Challenge: Touch Grass

What I Built

I built Sprout, a planting calendar that tells you what you can put in the ground this week, then gets out of the way.

My mother has a terrace she plants on every October. She does not need an app that tells her to "prepare for the season." She needs three lines and then her hands in the soil. Every planting website I looked at wanted an account, or a dropdown for her exact city, and then showed me an advert for seed companies.

The question itself is simpler than all that. Almost every cool-season vegetable is timed backwards from the first expected frost. Spinach tolerates about -6C, so it goes in roughly two months before frost and stays open until about a week before. Once you know your frost date, the rest is subtraction.

Sprout knows seven regions' frost dates. You ask it, it tells you what is open, what is not yet, and what window you have missed - then it explains it in a sentence and stops.

Demo

A real run, qwen2.5:3b on a CPU with no GPU:

==================================================================
  Sprout - Friday 09 October 2026
  North India - Delhi, Punjab, Haryana
  first frost expected 20 November  (42 days away)
==================================================================

Sow now
  Broad beans   direct          to -4C    (window closes 11 Oct)
  Peas          direct          to -3C    (window closes 16 Oct)
  Spinach       direct          to -6C    (window closes 15 Nov)
  Kale          direct          to -10C   (window closes 20 Nov)
  Carrots       direct          to -5C    (window closes 31 Oct)
  Onions        start in trays  to -5C    (window closes 21 Oct)

Not yet - sow on these dates
  Cabbage       start in trays  to -8C    (in 2 days, from 11 Oct)
  Garlic        direct          to -12C   (in 30 days, from 08 Nov)

Window has closed, next season
  ...

Then the part the model is actually for:

Get your broad beans in this week, while the ground is still workable -
they fix their own nitrogen, so whatever you plant after them will thank
you for it. Radishes are the fastest thing on this list if you want to see
something up quickly.
NEXT: Should I soak the broad bean seeds before sowing them?

And when I asked it something it should not have had an opinion about:

$ sprout.py --ask "why not sow tomatoes now?"

Tomatoes aren't open for sowing in your region at the moment. They're a
warm-season crop and there isn't room for them before the last frost in
spring. Right now, radish, spinach and lettuce are the quickest things to
get into the ground.

Code

github.com/karan244/sprout - MIT licensed.

No pip install. Standard library only, so there is no requirements.txt and no virtualenv. You need Ollama and a model, and that is the entire setup.

./run.sh                  # today, your region
./run.sh --region uk      # 7 regions, or --list to see them
./run.sh --no-ai          # facts only, instant, no model involved

How I Built It

The model is Qwen2.5:3B running locally through Ollama. It does exactly one job, and it is not the important one.

The dates are arithmetic, so the dates are in code

Every crop carries a sowing window measured in days relative to the first frost. spinach: -60 to -5 means sow from 60 days before frost until 5 days before it. Each region carries an approximate frost date. Deciding what is open today is then a date comparison: deterministic, instant, and identical every single run.

The model only explains

This split is the entire design, and I got it wrong twice before getting it right.

First attempt. I handed the model the whole computed crop list and told it not to repeat it. It repeated it anyway, in slightly different words, as though that counted as advice.

The fix was to stop giving it something to echo. It now receives only what it could not already know: the region, the frost date, and the planting-guide notes attached to whichever crops are currently open. Those notes are real horticultural knowledge - "broad beans fix their own nitrogen, so they feed the soil behind them" - that a 3B model would not reliably have. Give it that instead of a list and it has something to add.

Second bug, and a worse one. The question mode had no grounding at all. I asked it "why not sow tomatoes now?" and it answered:

It simply agreed with me, then attached confident detail. Asking a language model a question about a system it cannot see gets you agreement, not an answer. It now receives the same three computed lists as the plan, with an explicit instruction never to advise sowing something they show as closed. That question now comes back as "Tomatoes aren't open in your region at the moment", with a suggestion of what is.

A southern hemisphere bug worth mentioning

Melbourne's first frost is in April. My original date code read that as a date that had already passed this year and printed:

first frost expected 25 April (-167 days away)

...then cheerfully reported that every crop's window had closed. Frost dates now roll forward to the correct year, which for the southern hemisphere means the next one.

Things it does not do

It does not decide anything. Every date in the plan comes from the code. If the model is wrong it can only make the explanation worse, never the advice wrong.
It is cool-season only. Tomatoes, peppers and aubergines are timed against the last frost, which is a different calculation.
Frost dates are regional averages, deliberately rounded, not a forecast. --first-frost overrides them.

./selftest.sh          # 11 checks, about 40 seconds

Two of those checks exist because they caught real bugs: the frost roll-forward above, and the hallucinated-tomato case, kept as a regression test so it cannot come back quietly.

Why Does Open Innovation Matter?

The obvious reason is the same as for any local model, and it is not the interesting one here. The interesting one is that this project is mostly not an AI project at all.

Almost all of Sprout is arithmetic - frost dates, offsets, comparisons - and that part would be identical if no model existed. Which is exactly why it is better that way. Sowing dates are the kind of thing you do not want a language model improvising at 8am on a terrace. A 3B model will confidently tell you to plant tomatoes in October because you asked it nicely. Ordinary code cannot be talked into being wrong like that, and it costs nothing, takes no time, and works with the network off.

So the division of labour became: let the code hold anything a beginner would act on, and let the model hold anything that benefits from sounding like a person. The dates are arithmetic. "Get the broad beans in while the ground is still workable, and radishes if you want to see something up fast" is conversation - and that is the half a rulebook cannot do.

The privacy argument is real too, and pointed in an unexpected direction. A gardening question is not sensitive in the way a language-practice mistake is. But once a tool starts talking to a hosted model, everything you type goes with it, and I did not want a tool on my mother's terrace reporting her growing plans to a third-party logging pipeline. Running the model locally means I can hand her something without a privacy conversation attached, and it costs nothing to run forever.

Concretely: Qwen2.5:3B on a CPU answers in a few seconds, costs nothing per query, works with the network disconnected, and sent zero bytes off the machine during the whole demo above. The open-weight model was the only way to get the conversational half of this at all, and the open licence on the weights is why I could put it in something I would actually hand to my mother.

Licence

MIT. Model weights are Alibaba's Qwen, distributed under the Apache 2.0 licence.

Built with AI coding assistance. I made every design decision, chose the model, wrote and ran every line shown above, and every transcript in this post is a real capture rather than an illustration.

I built my friend a Spanish tutor that runs on her laptop and never phones home

Karan Raj — Mon, 05 Oct 2026 05:51:12 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built a Spanish practice partner for a friend who is learning from scratch and freezes when a real person talks to her. Ordering food is the specific thing: she can read a menu, but when the waiter asks "¿algo más?" she has to stop and translate in her head, and the moment passes.

So I made LingoBuddy — a terminal program she talks to instead. It holds a conversation with her in Spanish at her level, translates every line into English so she can check her own meaning, and corrects her when she drops an accent. It runs entirely on her laptop.

That last part is the whole point, which I explain below.

Demo

A real captured session, running qwen2.5:3b on a CPU with no GPU:

Luna> ¿Quieres un café con leche, por favor?
      EN: Would you like a coffee with milk?

Priya> Hola, buenos dias
Luna> Buenos días, cómo estás hoy? ¿Te gustaría algo de tomar?
      EN: Good morning, how are you today? Would you like something to drink?
      FIX: Write "días" instead of "dias"

Priya> quisiera un cafe por favor
Luna> Claro, un café para ti. ¿Te gusta con leche o sin leche?
      EN: Sure, here's a coffee for you. Do you like it with milk or without milk?
      FIX: Write "café" instead of "cafe"

Priya> adios
Luna> Adiós, buena suerte. ¡Buen provecho!
      EN: Goodbye, good luck. Enjoy your meal!
      FIX: Write "adiós" instead of "adios"

Every correction there is a missing accent she actually typed. The vocabulary command gives a card instead of continuing the conversation:

Priya> /word desayuno
      WORD: desayuno
      MEANING: breakfast; to have breakfast
      EXAMPLE: Me desayuno a las 10 de la mañana.
      EN: I have breakfast at 10 in the morning.
      TIP: Don't confuse it with "desayunar," which means to have breakfast.

Code

github.com/karan244/lingobuddy — MIT licensed.

It has no dependencies at all. It is pure Python standard library, so there is no requirements.txt, no virtualenv, and no build step. You need Ollama and a model, and that is the entire setup.

It also ships with a self-test:

./selftest.sh          # 15 checks end to end
./selftest.sh --quick  # skip the live model calls

That test found three real bugs while I was writing it, which is the most useful thing I can say about it.

How I Built It

The model is Qwen2.5:3B, an open-weight model from Alibaba, served locally by Ollama and reached over HTTP from inside WSL2. No API key, no account, no network call once it is running.

The interesting part was not the chat loop. It was discovering that a small model on a CPU cannot be given several instructions at once.

The first version failed

My first attempt asked the model for three things in a single reply: a line of Spanish, an English translation of it, and a correction of the learner. That does not work. On a 3B model I got all of the following:

The translation silently dropped from most replies
Corrections invented for mistakes the learner never made — it "corrected" her coffee order into a tea order
Every reply addressed the learner by name, because it could not work out which of us was the tutor

My second attempt tried to force the format with explicit ES: / EN: / FIX: labels and a worked example. Better, but it collapsed all three onto one line and started handing back the Spanish untranslated under an EN: label.

Fixing it by asking for less

Two changes fixed it, and both came from the same realisation: this model is reliable when asked to do exactly one thing, and unreliable otherwise.

1. Split the work. Each turn is now two separate single-purpose calls. The tutor speaks Spanish with the conversation history attached, so it remembers. Then a second, isolated call translates that one line. Two calls at roughly two seconds each instead of one that usually came back wrong.

2. Stop using the model for the checking. This was the bigger lesson. Accents are a rule problem, not a judgement problem, so they moved into a 40-entry lookup table in plain Python.

I did not arrive at that immediately. I first asked the model to reply with a fixed "no mistakes" string when the sentence was fine. It emitted that exact string for every single input, including "i want a coffee" and a sentence with no mistakes in it at all. When I replaced the sentinel with a yes/no question it did slightly better and still got roughly half of them wrong, missing quisiera un cafe one run and flagging Buenos dias on one run and not the next.

A dictionary has none of those failure modes. check_accents() costs no latency, cannot hallucinate, and was right on all nine test cases immediately. I left the ambiguous words out of it on purpose — que, esta and solo are excluded, because their unaccented forms are frequently correct and a false correction teaches the learner something wrong.

Other things worth knowing

A guard drops bad translations. looks_untranslated() counts accented characters; if a "translation" came back with two or more, it was the Spanish again, so the line is hidden rather than shown twice.
gemma3:1b was too small. I tried it first to save space and it lost the output format entirely. The README documents both so nobody repeats the experiment.
Finding Ollama took some work. It runs on Windows and listens on the WSL bridge rather than 127.0.0.1, and that address changes when WSL restarts. resolve_host() reads it from the routing table instead of hardcoding it, so it keeps working.
No GPU here. Every number above is CPU-only on a machine with 16 GB of RAM. That constraint is why the model is 3B and not 7B.

Why Does Open Innovation Matter?

A language practice partner is a bad candidate for a hosted API, for three reasons that all mattered for this specific person.

The mistakes are the sensitive part. A beginner is wrong constantly — that is the entire activity. Every wrong conjugation she typed went to a server's logs, at someone else's company, as part of someone's training data. Running it on her own machine means the failures stay private. This is the reason I chose local over a free hosted model, and it is not a close call.

It has to work on a train. She practises in the evening on her laptop. There is no guarantee of wifi, and a practice partner that needs a connection stops existing at exactly the moment she has time for it.

It has to cost nothing. A hosted chat model charges per conversation, forever. This runs indefinitely on hardware she already owns.

Concretely: open-weight Qwen2.5:3B on her CPU answers in about two seconds, costs zero per message, works with the network off, and sent zero bytes off the machine during that entire demo. A closed API could have done the translation half of this well. It could not have done the privacy part, which was the requirement.

I also used open tooling rather than a closed agent framework, which meant the accent checker could just be a Python function. Nothing about the split-calls design or the dictionary needed anyone's permission.

Licence

MIT. Model weights are Alibaba's Qwen, distributed under the Apache 2.0 licence.