My friend spent more time choosing a local AI model than building. So I built Hack Day Starter.

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

What I Built

A friend of mine wanted to try building with local AI for a hackathon project.

He had a 24 GB Apple Silicon laptop and wanted to build locally, but before he could start building, he had to figure out which model would actually make sense for his machine.

The problem wasn't coming up with an AI idea. It was getting from:

"I want to use a local AI model."

to:

"I have a working project."

Before actually building, there were several questions to answer:

• Which model can this laptop realistically run?
• How much RAM does it need?
• Is there enough disk space to download it?
• Does it support tool calling?
• What exact Ollama model tag should be used?
• How do I connect that model to a real application?
• What happens when Ollama is not running?
• What happens when the model hasn't been downloaded yet?

That setup work can take away a lot of valuable hackathon time.

So I built Hack Day Starter.

It is a hardware-aware local AI model recommender and starter generator.

You describe the machine you're building on. Hack Day Starter filters and ranks verified local models for that hardware, explains why a model fits, lets you choose between a Local Chat or Tool-Calling Agent, and generates a ready-to-run TypeScript starter for Ollama.

The idea is simple:

Remove the setup decision that happens before the real building begins.

The flow looks like this:

Hardware profile
      ↓
Compatibility filtering
      ↓
Verified model recommendation
      ↓
Local Chat / Tool-Calling Agent
      ↓
Generated TypeScript starter
      ↓
Ollama + local model
      ↓
Start building

This was built during the Hacktoberfest 2026 "Build for a Friend" challenge.

Demo

Live App

Hack Day Starter → https://hack-day-starter.vercel.app

Video Demo

The demo starts with a hardware profile and ends with a real local tool-calling application running through Ollama.

The web app is the recommender and generator.

The generated project is the thing the developer actually takes away and runs locally.

Code

GitHub → https://github.com/TechGenDM/Hack-Day-Starter

How I Built It

The stack is Next.js, TypeScript, Tailwind CSS, and Ollama.

But the interesting part isn't the framework stack.

It is the set of decisions I made around model selection and local execution.

1. I didn't want another static "RAM → model" table

A simple mapping would have been easy:

8 GB  → small model
16 GB → medium model
24 GB → larger model

But that breaks down quickly.

Two models with similar parameter counts can have very different memory requirements, context windows, capabilities, and practical hardware fit.

So Hack Day Starter builds a hardware profile using information such as:

• RAM
• free disk space
• operating system
• Apple Silicon / GPU information
• NVIDIA VRAM where applicable
• intended use case

The recommendation engine first removes models that should not be recommended at all, then ranks the remaining models using factors such as memory headroom, disk headroom, hardware acceleration, task relevance, model capacity, and verified capabilities.

The recommendation itself is deterministic.

I didn't ask another LLM to decide which model should be used.

2. Model information needs to be treated as data, not truth

Local AI changes quickly.

A tutorial written a few months ago can easily point to a model that has been replaced, changed, or isn't appropriate for the hardware anymore.

So I created a curated Verified Model Registry.

The registry currently tracks 23 model entries and records information such as:

• exact Ollama tags
• model size
• context window
• lifecycle status
• capabilities
• verification status

The recommendation layer only considers models that pass the project's local and verification rules.

The generator checks the registry again before creating a starter, so an arbitrary model tag can't simply be supplied by the client to bypass those checks.

3. Chat and Agents are different starting points

I didn't want the generated project to become another giant framework.

There are two intentionally small starter types.

Local Chat

A minimal TypeScript application that communicates directly with the local Ollama API.

Tool-Calling Agent

A small agent loop where the model can request a tool, the local runtime executes it, and the result is sent back to the model.

For the demo, I verified a complete local tool-calling run with Gemma 4 12B:

User:
What is 342 multiplied by 19, and then divide by 4?

Model → Tool Call:
calculate({"expression":"(342 * 19) / 4"})

Tool Result:
1624.5

Model:
342 multiplied by 19, divided by 4, equals 1624.5.

That was important to me.

I didn't want to stop at "the model supports tool calling."

I wanted to see the complete loop actually work:

model → tool request → local execution → tool result → model response

4. The generator doesn't use an LLM to generate the code

This was another deliberate decision.

Hack Day Starter generates the starter project from deterministic templates.

That means the application controls:

• the project structure
• the selected model
• the exact Ollama tag
• the setup commands
• the starter type

The same input should produce the same project.

For a developer tool whose whole purpose is to remove setup uncertainty, predictable generation matters more than making the generator itself "AI-powered."

5. I learned that local AI has another failure mode: setup

Getting a model selection right is only half the job.

A generated application can still fail immediately because:

Ollama isn't running

or:

The model hasn't been downloaded

So the generated starters include a readiness check.

Instead of showing a raw connection error, the starter explains what is missing:

Ollama not running
        ↓
Start Ollama

Model not installed
        ↓
ollama pull <exact-model-tag>

Ready
        ↓
npm run dev

That sounds like a small UX detail.

For someone new to local AI, it can be the difference between "I understand what happened" and "the project is broken."

6. I added safety boundaries around generation and tools

The project also has a few hard checks:

• arbitrary model tags are rejected
• retired or unverified models cannot be used
• Agent starters require verified tool-calling support
• the exact selected Ollama tag is preserved
• the calculator uses a strict parser instead of eval() or new Function()

The repository currently has 36/36 automated tests passing across recommendation logic, registry validation, starter generation, readiness checks, security checks, and setup-flow contracts.

What Building This Taught Me

The hardest part wasn't making a model answer a prompt.

The harder problem was deciding what should happen before the prompt ever reaches the model.

I started with the obvious mental model:

"Give me hardware → give me a model."

The project became much more useful when I treated it as:

"Give me hardware → tell me what I can safely use → explain why → give me a runnable starting point."

That changed the project from a model lookup tool into a bootstrapper.

I also learned that "local AI" is not just about inference.

The developer still has to install the runtime, download the weights, understand the hardware limits, and connect everything to an application.

The real product is reducing that friction.

Handing It Over

Before finishing the project, I ran the workflow with a friend.

The part that mattered most was that he didn't need me to explain what model to choose or what command to run next. The recommendation, exact model tag, and setup steps were visible in the product itself.

The important test wasn't whether I could use the application.

I already built it.

The real test was whether someone else could go through:

hardware → recommendation → starter → setup

without needing me to explain every screen.

That was the standard I used for the final UX.

There is still plenty I could improve, but the core hand-off works: the recommendation explains itself, the selected model is explicit, and the generated project tells the developer exactly what to do next.

Why Does Open Innovation Matter?

A closed AI API could have helped me build an AI application.

But it would not have solved the particular problem I was trying to solve.

The core of Hack Day Starter is local model selection and local execution.

The developer can:

• choose a model based on their own hardware
• inspect the model information used by the recommendation
• download the weights locally
• run inference through Ollama
• swap to another compatible model
• inspect and modify the generated TypeScript code
• build without making a hosted inference API a requirement

That control matters because the model is not just an API endpoint anymore.

It becomes part of the developer's own environment.

It also changes the privacy boundary.

For the generated application, inference can happen through the developer's local Ollama instance rather than sending prompts to a third-party inference service.

There are real tradeoffs.

Local models still need enough hardware. Downloading weights takes disk space and time. Smaller models won't always match the quality of large hosted frontier models.

I don't think those tradeoffs make local AI universally better.

They make it different.

For this project, the open approach gives the developer more control over:

the model, the runtime, the hardware, the code, and where the data goes.

That's exactly what I wanted my friend to have.

I wanted to create a shorter path from "Can my laptop run this?" to "I'm building."

Prize Categories

Best Use of Gemma

I'm entering Best Use of Gemma because Gemma 4 12B is used as a real local model in the project, and I verified a complete tool-calling workflow with it through Ollama.

---

Built for a friend during Hacktoberfest 2026.