I Built ServiceLog for a Friend Who Always Forgets When He Last Serviced His Motorcycle

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

What I Built

I built ServiceLog, a simple vehicle service history tracker for a friend who owns a motorcycle and often forgets when the last service was done.

The problem is pretty simple.

He knows he has changed the oil, checked the brakes, or replaced the chain before. But when someone asks:

"When was the last time you serviced it?"

the answer is usually something like:

"I think it was last month... maybe."

ServiceLog was built to solve that small but annoying problem.

You can record a vehicle service with:

• Service type
• Date
• Odometer
• Notes

The dashboard then calculates maintenance intervals for supported service types and highlights the maintenance item that is currently closest to being due.

I also wanted the service history to be something you could actually ask questions about, so ServiceLog has an AI assistant.

For example:

"When was my last oil change?"

Instead of letting the AI guess, ServiceLog retrieves the actual service records and asks the model to answer using those records as evidence.

The goal is simple:

Don't remember it. Log it. Ask it later.

Demo

Live demo:

https://servicelog-eta.vercel.app

Source code:

https://github.com/rfn98/servicelog

The app currently starts with a seeded Yamaha R15 example so the main experience can be explored immediately.

Code

The complete project is open source on GitHub:

https://github.com/rfn98/servicelog

The application is built with:

• Next.js App Router
• React
• TypeScript
• Tailwind CSS
• Prisma
• PostgreSQL on Neon
• Google Gemini Interactions API
• Gemma 4 26B A4B IT

The Gemini API key stays on the server. The browser only communicates with the ServiceLog API.

How I Built It

The most important design decision was to make the AI assistant evidence-grounded instead of generative-first.

The flow looks like this:

User question
     ↓
ServiceLog API
     ↓
Deterministic record retrieval
     ↓
Relevant service records
     ↓
Gemma
     ↓
Answer + [R1] citations
     ↓
Citation validation
     ↓
Database re-read
     ↓
Answer + verified sources

The model receives a compact context containing the relevant service records:

[R1] Oil Change | 2026-09-12 | 18420 km
[R2] Brake | 2026-08-03 | 17900 km
[R3] Chain | 2026-06-15 | 16800 km

The model can cite those records using [R1], [R2], etc.

After the model responds, ServiceLog does not blindly trust the citations. It validates the references against an allowlist and re-reads the corresponding records from the database before returning them to the client.

This gives the AI assistant a much narrower job:

explain the evidence, don't invent the evidence.

Maintenance calculations are also deterministic. Maintenance intervals are calculated by application code, not by the AI model.

For the Gemini integration, I use gemma-4-26b-a4b-it through Google's Interactions API with:

• store: false
• Low temperature
• Minimal thinking level
• 15-second timeout
• Retry only for rate-limit and server errors
• No client-side API key exposure

The application currently has 113 automated tests, covering validation, maintenance calculations, API behavior, AI extraction, citation validation, empty-history behavior, and other core contracts.

Why Does Open Innovation Matter?

For a project like ServiceLog, open innovation matters because the AI component doesn't need to be a mysterious black box.

Using an open-weight Gemma model gives me a model whose role can be deliberately constrained by the application architecture.

The important part isn't simply "I added AI."

It's that the application can define what the model is allowed to know and how its answers are checked.

The service history remains the source of truth.

The model is an interface for understanding that history.

That separation also makes the system easier to reason about. If a maintenance calculation is wrong, I can inspect the deterministic application logic. If an AI response is unsupported, I can inspect the retrieved evidence and citation validation instead of treating the model output as authoritative.

Open innovation also makes experimentation more accessible. A small project built by one developer can combine open-source frameworks, open-weight models, a conventional relational database, and transparent application logic without having to build an entire AI platform from scratch.

My Agent Session

The project was built iteratively with an AI coding agent.

The agent was used for implementation, testing, debugging, security checks, database migration, and deployment preparation — while keeping the application architecture and scope deliberately constrained.

One of the useful parts of the development process was treating the agent as an implementation partner rather than allowing it to freely expand the product.

For example, the project explicitly avoids:

• AI-generated maintenance schedules
• Vehicle diagnosis
• Fake maintenance recommendations
• Unverified citations
• Automatic schema changes
• Unnecessary authentication or multi-vehicle complexity

The goal was to build a small product that actually works rather than a large demo full of speculative features.

Prize Categories

• Best Use of Gemma — ServiceLog uses Google's open-weight Gemma model as the core AI assistant. The model answers questions about the user's vehicle service history using retrieved records as evidence, with citation validation before sources are returned to the user.