DEV Community: Raven

I Wanted a Workout Tracker That Respected My Data, So I Built KOVA

Raven — Sun, 01 Nov 2026 14:02:51 +0000

Building an offline-first fitness application focused on privacy, personal training history, and putting users in control of their own data.

Fitness applications have an interesting business model.

You track your workouts, record your progress, build routines, and gradually accumulate months or even years of personal training data.

But where does all that information actually live?

For many applications, your training history depends on an account, a cloud service, or a subscription.

I started thinking about a different approach.

What if a workout tracker could be genuinely useful without requiring users to depend on a remote service?

That idea became KOVA.

Explore KOVA

Your training history should belong to you

A workout tracker should be relatively simple in principle.

You perform an exercise, record your sets and repetitions, track your progress, and use that information to make better training decisions.

Yet, over time, these records become something more valuable than individual workout entries.

They become your training history.

Your personal records, routines, measurements, exercise preferences, and progress represent actual effort accumulated over months or years.

I believe that information should remain under the user's control.

That's the philosophy behind KOVA.

More than recording sets and repetitions

KOVA is designed as a broader training companion rather than a basic exercise logging application.

Here are some of the areas it brings together.

1. Workout tracking

Record exercises, sets, repetitions, and training sessions.

The objective is to make logging straightforward enough that tracking doesn't become more annoying than the workout itself.

2. Workout planning and routines

Organize training sessions and create routines around your training preferences.

Having a structured plan makes it easier to stay consistent and understand what you're working toward.

3. Exercise library

Browse exercises and use an organized exercise library when planning workouts.

A good exercise library is more than a list of names. It helps make workout planning and tracking easier to navigate.

4. Progress tracking

Track your training history, personal records, measurements, and progress over time.

Instead of relying entirely on memory, you have a record of what you've actually accomplished.

5. Training journal

Keep notes and additional context around your training.

Numbers tell part of the story. Sometimes you also want to remember how a session felt or what you changed.

Offline-first is a design decision

One of the central ideas behind KOVA is that a workout tracker shouldn't need a permanent internet connection to remain useful.

An offline-first approach changes how an application is designed.

Instead of treating a remote server as the only source of truth, the application prioritizes local data availability.

This has practical advantages:

Your workouts remain accessible without an internet connection.
Logging doesn't need to depend on network availability.
Your training experience isn't built around a cloud service being online.
Your personal records remain part of your own application experience.

Offline-first doesn't automatically guarantee perfect privacy or data security. Those still require deliberate engineering decisions.

But it creates a foundation where the user doesn't have to depend on a remote service for every interaction.

Designing around the actual workout experience

A fitness application has a different usability problem from most productivity applications.

People don't necessarily want to spend several minutes navigating menus between sets.

The interface needs to make common actions easy to reach.

That's why KOVA brings together workout sessions, routines, exercise browsing, progress, notes, and personal training information into one application.

The design direction is intentionally restrained, with a dark, minimal visual language rather than overwhelming dashboards and unnecessary decoration.

The application should support the training experience, not compete with it.

Building KOVA

KOVA has also been an interesting software engineering project because of the number of interconnected features involved.

Workout tracking, exercise libraries, routines, measurements, and progress statistics all depend on consistent underlying data.

Changing one part of the application shouldn't accidentally break another.

This makes architecture and data integrity particularly important.

The project has involved working through challenges around:

Managing structured exercise and workout data.
Keeping training records consistent.
Designing reusable exercise and workout experiences.
Supporting offline-first workflows.
Making progress information understandable.
Maintaining a cohesive mobile experience.

I wanted to approach it as a proper training platform rather than a collection of disconnected screens.

The bigger idea: your training, your data

Technology should make personal progress easier to understand, not create unnecessary dependencies.

A workout tracker shouldn't make you feel like you're borrowing your own training history.

KOVA is built around a simple principle:

Your training. Your data. Yours.

It's an ongoing project, and there's still room to improve the experience, expand its capabilities, and refine how people interact with their training history.

Try KOVA

If you're looking for a more private, offline-first approach to workout tracking, explore KOVA:

Visit KOVA

I'm interested in hearing from people who care about fitness tracking, offline-first applications, privacy-focused software, and building products that give users more control over their data.

Because at the end of the day, your progress should belong to you.

I Built an Android AI Assistant That Doesn't Need the Cloud

Raven — Sun, 01 Nov 2026 14:01:35 +0000

Running language models locally on Android, keeping conversations on-device, and exploring what happens when AI doesn't depend on a server.

Most AI applications have something in common.

You type a message, send it somewhere, wait for a server to process it, and receive a response.

It's convenient. It's also an architecture we've become so accustomed to that we rarely question it.

What if the model didn't need to run on someone else's infrastructure?

What if your phone could handle the inference itself?

That question is what led me to build Snor, an Android application designed around local AI inference.

Explore Snor

The idea: AI without the usual cloud dependency

I wanted to experiment with something different from the typical AI chatbot architecture.

Instead of making a remote API the center of the application, I wanted the phone itself to be capable of running language models.

That introduces an entirely different set of engineering problems.

You're no longer just building a chat interface around an API.

You're dealing with:

Model loading and memory consumption.
CPU and GPU inference.
Context window management.
Native Android integration.
Generation latency.
Device-specific performance limitations.

The interesting part is that all these constraints become part of the application design.

Running LLMs directly on Android

Snor is built around local model inference.

One of the technologies involved is llama.cpp, which makes it possible to run compatible quantized language models using GGUF files.

The application also explores LiteRT-LM for on-device inference.

This means model execution can happen directly on the device rather than requiring every prompt to be sent to an external AI provider.

For smaller devices, this distinction matters.

A model that works comfortably on a desktop might be completely impractical on a phone with limited available memory.

That's why model selection, quantization, and resource management are important parts of the project.

Why smaller models?

One of the more interesting directions I've been exploring is lightweight models.

Instead of assuming that bigger models are always better, I've been focusing on the SmolLM2 family, particularly:

SmolLM2 135M
SmolLM2 360M

These models aren't intended to compete with large frontier models.

Their value is in exploring what can be accomplished with relatively small models under mobile hardware constraints.

There are trade-offs, obviously.

Smaller models have limited reasoning capabilities, and they aren't suitable for every task. They can also produce incorrect or incomplete answers.

But that limitation is part of the engineering problem.

A useful local AI application shouldn't pretend that a tiny model can do everything.

It should manage expectations, handle output carefully, and acknowledge when it cannot provide a reliable answer.

Privacy is an architectural decision

One of the main reasons for building Snor around local inference is data control.

When inference happens locally, conversations don't need to be transmitted to a remote model provider.

Snor is designed around:

Local-first AI inference.
No account requirement.
No default cloud dependency.
On-device conversation storage.
Optional cloud AI integrations when users explicitly choose them.

This distinction is important.

Privacy shouldn't just be a marketing statement added to an application description. It should influence how the software is architected.

Local inference provides a different relationship between the user, the application, and the model.

The engineering challenges are more interesting than the chat interface

The UI is only one part of the project.

The difficult work happens underneath it.

1. Native model integration

Running native inference engines inside a Flutter application requires communication between Dart and native code.

Snor uses native integration to connect its application layer with the inference engines.

This creates additional responsibilities around model lifecycle management, memory handling, and safe execution.

2. Model lifecycle and concurrency

Native inference isn't something you want to manage casually.

Loading a model, generating a response, clearing context, and disposing of native resources need predictable execution.

Concurrent operations can cause serious problems if the underlying native resources aren't protected.

This is why synchronization and controlled model lifecycle management are important parts of the implementation.

3. Working within mobile hardware limitations

Android devices don't have unlimited memory or desktop-class cooling systems.

Model size, available RAM, context length, and inference settings all affect the experience.

A mobile AI application needs to account for those constraints rather than assuming every device behaves the same way.

4. Making smaller models useful

A smaller model shouldn't be given an unlimited conversation history and expected to perform like a much larger model.

Snor explores bounded conversation history, model-specific context limits, and output constraints to keep interactions manageable.

The goal is to build a more predictable experience around the capabilities of the model actually running.

Local-first doesn't have to mean cloud-never

I don't think local AI and cloud AI need to be competing philosophies.

They solve different problems.

Local models offer more control over data and can work without an internet connection.

Cloud models offer access to significantly larger models and more demanding capabilities.

Snor explores a local-first approach while allowing optional cloud integrations.

The important distinction is that cloud usage should be a deliberate choice rather than an invisible requirement.

What I'm exploring next

Snor is an ongoing experiment in making local AI practical on Android.

Some areas I'm interested in improving include:

Better inference performance across different Android devices.
More reliable model downloads and loading.
Improved handling of partial generation and interrupted inference.
Smarter context management.
Better lightweight model selection.
A more polished mobile AI experience.

I find this space particularly interesting because mobile hardware keeps evolving, while efficient inference techniques and smaller models continue to make local AI more practical.

There's still a lot to figure out.

Try Snor

If you're interested in running language models locally on Android, you can explore the project here:

Visit Snor

I'm particularly interested in hearing from developers experimenting with llama.cpp, GGUF models, Flutter, and on-device inference.

The bigger question I'm exploring is simple:

How much useful AI can we actually fit inside a phone, without depending on someone else's server?

I Got Tired of Making Study Materials Instead of Studying, So I Built Cramio

Raven — Sun, 01 Nov 2026 13:53:48 +0000

An experiment in building an AI-powered study companion for students, using React, Capacitor, Supabase, and a little frustration with the way we study.

There's a funny problem with studying.

You sit down because you want to learn something. Three hours later, you've organized your PDFs, highlighted paragraphs, rewritten notes, created a few flashcards, and somehow haven't actually studied that much.

Congratulations. You've successfully procrastinated using productivity tools.

I've experienced this enough times to start questioning the workflow itself.

Why does preparing to study sometimes feel like an entirely separate subject?

That question eventually turned into Cramio.

Explore Cramio →

The real problem wasn't a lack of study materials

Students already have materials. Plenty of them, actually.

Lecture slides, PDFs, textbooks, handwritten notes, screenshots, and documents scattered across different folders.

The problem is what happens next.

A PDF contains 40 pages of information. You need to understand it, identify the important concepts, create questions, and test whether you've actually retained anything.

Most of that preparation is repetitive.

I started thinking: what if the application could handle some of that preparation, while the student focused on understanding the material?

Not another chatbot with a fancy interface. Not another application that simply summarizes everything and calls it learning.

I wanted something built around the actual studying workflow.

Building Cramio: From raw materials to active learning

Cramio is an AI-powered study application that turns existing learning materials into resources students can actively use.

The central idea is simple:

Your materials should become the starting point of your learning experience, not another thing you have to manually process.

Here's how that translates into the product.

From reading to reviewing

Instead of manually rewriting an entire lecture document, Cramio helps generate organized study notes.

The goal is to make lengthy learning materials easier to navigate and revisit.

From memorizing to active recall

Flashcards are useful because they force you to retrieve information instead of passively rereading it.

Cramio uses AI to help generate question-and-answer cards from study materials, making it easier to start practicing.

From guessing to testing

Reading something five times doesn't necessarily mean you understand it.

That's why Cramio also includes AI-generated quizzes, allowing students to test their understanding and identify areas that need more attention.

When the material gets confusing

Sometimes the problem isn't memorization. It's understanding a concept in the first place.

Cramio also includes an AI study assistant to help students work through questions and difficult topics.

The engineering behind it

I didn't want Cramio to become a collection of disconnected AI features.

The challenge was creating an application where authentication, study materials, AI generation, and the actual learning experience worked together.

The current architecture uses:

React for the application interface.
Capacitor to bring the web application into an Android environment.
Supabase for backend services and data management.
Clerk for authentication.
AI-powered workflows for generating learning resources.

One important engineering consideration is that AI-generated content needs structure.

Generating text is relatively straightforward. Generating useful educational material that students can actually review is a different problem.

A flashcard should test a meaningful concept. A quiz should assess understanding. Notes should be readable rather than becoming another wall of generated text.

That's the difference between adding AI to an application and designing an application around a meaningful AI-assisted workflow.

Why Android first?

I wanted to focus on making the experience accessible through an actual mobile application.

Students don't always study at a desk with a laptop open. Sometimes they're reviewing materials between classes, commuting, or studying from their phones.

Building with Capacitor gives Cramio a way to share its React application architecture while delivering an Android experience.

It also introduces its own challenges: mobile interactions, navigation, authentication flows, responsive layouts, and making sure the application feels native enough to use comfortably.

These are the kinds of details that don't always show up in a feature announcement, but they matter enormously to the actual product.

I'm not trying to replace studying with AI

This is probably the most important distinction.

AI shouldn't become another shortcut that makes students feel productive without actually learning anything.

Summarizing a chapter isn't the same as understanding it. Generating flashcards isn't the same as remembering their answers.

The interesting opportunity is using AI to reduce the friction between receiving learning materials and actively engaging with them.

Cramio is built around that idea.

What's next?

Cramio is an ongoing project, and there's still plenty to improve.

Some areas I'm particularly interested in are:

Improving the quality and usefulness of AI-generated study materials.
Making PDF processing more reliable.
Refining the mobile learning experience.
Making studying more engaging without turning the application into a distraction.
Building a better workflow around active recall and self-assessment.

I want to keep approaching this as an engineering problem: identify friction, understand its cause, and build something that genuinely improves the experience.

Try it yourself

If you're a student who spends too much time preparing materials instead of actually studying, Cramio might be worth exploring.

Visit Cramio

And if you're a developer interested in building AI-powered applications, I'd be interested in hearing how you're approaching the challenge of making AI genuinely useful beyond a chat interface.

Because honestly, students already have enough things to memorize. They shouldn't have to memorize an entire workflow just to start studying.

I Built Monbii - A Habit App Where Your Companion Grows With You

Raven — Thu, 30 Apr 2026 02:32:25 +0000

I got tired of habit apps that feel like spreadsheets pretending to be motivation.

So I built something different: Monbii.

It’s a minimalist habit app where your companion evolves based on how consistent you are.

Not in a “points and badges” way, but in a way where your behavior actually changes what you see and interact with.

If you stay consistent, your companion grows.

If you don’t, it reflects that.

There’s also a simple battle system that evaluates your progress every few days based on your habits.

And reminders are built like a system, not spam. They feel more like a companion checking in than a generic notification.

What I used

React + Capacitor JS (mobile-first web app)
Zustand for state management
Supabase / Lovable Cloud for syncing data
Lottie for mascot animations

What I learned building this

Most habit apps fail because there’s no emotional attachment
Users don’t care about features, they care about feedback loops
If the first 10 seconds don’t feel rewarding, nothing else matters
Simplicity beats “feature richness” every time

What I’m improving next

Making the companion reactions more dynamic
Refining the progression system
Improving the battle system so it actually reflects behavior better

🔗 Live: https://monbii.vercel.app/

I Built an AI CLI That Writes Git Commits So You Don’t Have To

Raven — Thu, 30 Apr 2026 02:20:28 +0000

Let’s be honest.

Most commit messages look like this:

fix stuff
update again
final-final-actually-final

They’re useless.

And the worst part? You know they’re bad, but you still write them because stopping to craft a proper message feels like friction.

So I built something to remove that friction entirely.

🚀 Introducing gac (Git Auto Commit)

gac is an AI-powered CLI that analyzes your Git changes and writes structured, meaningful commit messages for you.

Not random fluff.
Not generic summaries.
Actual useful commits.

💥 The Real Problem

Git isn’t broken.
Our habits are.

Bad commit messages create:

messy project history
painful debugging sessions
confusion in team collaboration

And consistency is hard when you're moving fast.

So instead of relying on discipline… I automated it.

⚙️ What gac Does

✨ AI-Generated Commit Messages

Reads your staged changes (diffs) and generates structured messages using the Conventional Commits format.

🔄 Smart Sync Checks

Runs git fetch and warns you if your branch is behind before committing.
No more surprise merge conflicts later.

📦 Interactive Staging

Forgot to stage files?
gac detects that and asks if you want to stage everything.

🚀 Post-Commit Actions

After committing, gac can:

push your changes
open a GitHub PR (for non-main branches)

🧠 Diff Noise Filtering

Automatically ignores:

package-lock.json
bun.lock
other low-signal files

So the AI focuses on what actually matters.

🎨 Custom Styles

Choose how your commits sound:

conventional
minimal
detailed
verbose
vibe (for when you're feeling chaotic)

🔌 Extensible by Design

.gacignore → exclude files from analysis
custom prompts → control AI behavior per repo

🛠 Installation

npm install -g gac-cli

Or from source:

git clone https://github.com/ravvdevv/gac.git
cd gac
bun install
bun link

🔑 Setup

gac --key YOUR_API_KEY
gac --model openrouter/free

🧪 Usage

Just run:

gac

That’s it.

🧩 Useful Flags

gac --amend     # regenerate last commit message
gac --dry-run   # preview without committing
gac --copy      # copy message to clipboard

🤔 Why This Actually Matters

Good commit messages are leverage.

They help you:

debug faster
collaborate better
understand your own code months later

But writing them every time is annoying enough that most people don’t.

So the system breaks.

gac fixes the system, not your motivation.

🔮 What’s Next

This is just the start.

The goal isn’t just “better commits.”
It’s turning the CLI into a smarter workflow assistant that reduces cognitive load across development.

📦 Try It Out

👉 https://github.com/ravvdevv/gac

🧠 Final Thought

If your commit history still looks like:

update
fix
pls work

You don’t need more discipline.

You need better tooling.

The Internet Shows What We Do. It Hides How We Feel.

Raven — Sun, 22 Feb 2026 11:17:03 +0000

The internet is incredible at visibility.

It shows what people are building.

Shipping.

Launching.

Scaling.

Winning.

Polished screenshots.

Milestone posts.

“Big news 🚀” updates.

Perfectly framed productivity.

But it hides something fundamental.

How people actually feel.

Behind the commits and announcements:

Anxiety
Loneliness
Burnout
Quiet doubt
Silence

We scroll through highlight reels while quietly falling apart.

As builders, we’ve optimized for performance, metrics, growth, engagement.

But we haven’t optimized for emotional honesty.

So I built something different.

Introducing BULONG

BULONG is a live, anonymous emotional map.

It lets people drop a whisper about how they actually feel — right where they are, or tied to a memory of a place.

No usernames.

No followers.

No profiles.

No metrics.

No performance.

Just raw emotion, placed on a map.

When you open it, you don’t see status.

You see honesty.

A stranger in your city who feels overwhelmed.

Someone three blocks away who can’t sleep.

Someone across the world whispering, “I’m tired too.”

“Bulong” means whisper.

And the quiet thoughts we hide are often the loudest ones inside us.

Why Build This?

Because the current internet rewards visibility without vulnerability.

We measure everything:

Followers
Likes
Shares
Views
Retention

But there’s no place designed purely for emotional presence.

Not therapy.

Not advice.

Not fixing.

Just visibility.

And sometimes the most powerful thing a person can see is this:

You’re not the only one feeling it.

This Isn’t a Mental Health App

It’s not diagnosing.

It’s not coaching.

It’s not moderating your growth journey.

It’s emotional visibility at scale.

A quiet layer of the internet where people can exist without performing.

Because sometimes you don’t need answers.

You just need to know someone else is carrying something too.

A Question

If this existed during your lowest moment…

Would you have opened it?

Explore BULONG

Explore it here: https://bulong-map.vercel.app

I Built My Own Social Media Platform (And Turned It Into a Game)

Raven — Wed, 18 Feb 2026 15:25:36 +0000

Most social platforms reward noise.

The loudest voices win. The fastest takes spread. The algorithm decides what matters.

So I decided to build something different.

I created Hypenote — a community-driven discussion platform where influence isn’t random. It’s earned.

👉 Check it out here: https://www.hypenote.online/

The Core Idea: Aura

On Hypenote, every user has something called Aura.

Upvotes increase your Aura

Downvotes decrease it

High Aura increases your influence

Low Aura limits your power

Aura isn’t just a vanity number. It changes how the system treats you.

High Aura users can:

Pin posts

Create “circles” (private communities)

Have stronger voting weight

Unlock cosmetic badges

Low Aura users:

Have post cooldowns

Carry less voting weight

Your influence is directly tied to how the community values your contributions.

It’s not just content. It’s reputation.

Making It Feel Like a Game

I didn’t want another static discussion board. I wanted something dynamic.

So I added mechanics inspired by game systems:

Aura decay over time (stay active or lose influence)

Streak bonuses for consistent participation

Daily limited posts

Early community slot limits

Anonymous confessions

Unfiltered controversial takes

Scarcity creates behavior.
Reputation creates tension.
Influence creates competition.

Now it’s not just posting. It’s strategy.

Why I Built It

I’ve always been fascinated by how platforms shape behavior.

Reddit has karma.
Twitter has followers.
Stack Overflow has reputation.

But what if influence wasn’t just social proof — what if it actively changed your capabilities?

Hypenote is an experiment in that idea.

Can you design a platform where reputation actually matters?

Can you create a system that rewards quality over noise?

I don’t know yet.

That’s the fun part.

What I Learned Building It

Gamification changes everything.

Scarcity drives engagement.

Moderation isn’t optional — it’s survival.

Social systems are psychology engines disguised as apps.

Building a social platform forces you to think about behavior, incentives, and abuse patterns. You’re not just writing code — you’re designing human interaction.

What’s Next

Right now, Hypenote is focused on:

Core posting and threaded discussions

Aura mechanics

Basic moderation and rate limiting

Dark theme and responsive UI

Next steps:

Smarter trending algorithms

Improved moderation tooling

Expanding the “circle” system

Refining Aura weight logic

This is still early. It’s an evolving system.

But building your own social media platform from scratch?
That changes how you see the internet.

Hypenote is live, but it’s actively being improved.

You might encounter small bugs, UI inconsistencies, or experimental mechanics while I continue upgrading and refining the system. That’s part of building in public.

Feedback is welcome. Iteration is constant.

If nothing else, I learned one thing:

Platforms don’t just host conversations.
They shape them.

And if you can shape behavior, you’re not building an app.
You’re building a system.

I Built an AI Portfolio You Can Actually Talk To

Raven — Thu, 08 May 2025 14:30:44 +0000

🚀 Just launched my AI-Powered Developer Portfolio — meet my AI Assistant, your virtual guide through my projects and skills. 🤖💬

Imagine having an assistant that can walk you through all my latest work, explain my tech stack, and even chat with you like it’s me. That’s what this portfolio does — and more.

Here’s how it works

GitHub REST API – Pulls live data from my GitHub to keep track of my latest commits, projects, and contributions.
Pollinations AI API – The magic behind the assistant. It processes the GitHub data and answers questions like it’s me, in a conversational way.
Real-time Q&A – Want to know about my latest project, tech choices, or past work? Ask the AI, and it responds like an assistant who knows everything about me (and my code).

It’s like having me as an assistant — but smarter, faster, and available 24/7. No need to dig through a static portfolio or outdated resume. Just ask, and the AI delivers. 💡

Check out my AI Portfolio here
👉 https://ravsalt.github.io/ai-portfolio/

Explore the code on GitHub
📦 https://github.com/Ravsalt/ai-portfolio
‎ ‎ ‎ ‎ ‎

Why Did I Build This?

AI Meets Productivity: I wanted a portfolio that’s more than just a digital CV. It’s a real-time assistant that keeps track of my projects, answers questions, and interacts as if I were right there with you.
Always Up-to-Date: No more worrying about outdated info. The assistant always knows what I'm working on and is synced with my live GitHub activity.
Open Source & Customizable: This isn’t a one-off project. Feel free to fork it, remix it, and adapt it to create your own
AI assistant-powered portfolio.
‎
‎ ‎ ‎ ‎ ‎ ‎

💬 I’d Love Your Feedback, Ideas, or Contributions!
If you’re curious or want to suggest ways to make it better, hit me up! Fork the repo, improve the AI, or use it as a base to build your own AI assistant portfolio.‎ ‎ ‎
‎ ‎