Why I stopped trusting my own backup scripts (and built a SaaS instead)

Ivan Kovac — Thu, 12 Feb 2026 12:09:59 +0000

The "Oh S***" Moment

We’ve all been there. You have a side project running on a $5 VPS. You wrote a quick bash script to run pg_dump or mysqldump every night at 3 AM. You put it in crontab. You felt responsible. You felt safe.

Then, six months later, you actually need that data.

You go to your backup folder. File size: 0kb.

Or worse, the file is there, but when you try to restore it, you realize you never tested the restore command, and version mismatches are throwing errors everywhere.

This is exactly why I started building Oops Backup.

The Problem: Backups are easy. Restores are hard.

As developers, we obsess over the backup part. "Is the data saved?"

But we rarely obsess over the restore part. "Can I get this app back online in 5 minutes if the server catches fire?"

I realized that my collection of haphazard shell scripts and cron jobs had three major flaws:

No Visibility: If a backup failed silently (disk full, credentials changed), I wouldn't know until it was too late.
Storage Hell: Storing backups on the same server as the database is a recipe for disaster. Moving them to S3 via scripts is annoying to maintain.
Restore Anxiety: Restoring a database usually meant SSH-ing in, finding the file, unzipping it, and praying the import command worked.

Building The Solution (And Learning to Say "No")

I decided to build a tool that treats Backup & Restore as a first-class citizen, not an afterthought.

The Features:

Automated Scheduling: No more manual cron editing.
Storage: Native integrations for S3-compatible storage (AWS, Cloudflare R2, Backblaze B2), Oops Storage or SFTP transfer.
One-Click Restore: This is the killer feature. You can browse your backups and restore them to a specific database instance via the UI.

The Pivot: Killing MSSQL

Building in public means admitting when you’re wrong.

Initially, I wanted to support everything: MongoDB, PostgreSQL, MySQL, and Microsoft SQL Server.

Last week, I officially dropped support for MSSQL.

Why? Because trying to support the Windows-heavy ecosystem of MSSQL inside a lightweight tool was bloating the project and distracting me from the core user base. 95% of indie hackers and devs I know run on the "LAMP" or "MERN" stack equivalents.

By cutting MSSQL, I could double down on making the Postgres, Mongo, and MySQL experience flawless. Sometimes, you have to cut a feature to save the product.

Where I am now

I’m currently finalizing and polishing the UI. I’m building this in public and sharing the journey on X, Threads and Bluesky.

If you’re tired of trusting a backup.sh file you wrote three years ago, I’d love for you to check out what I’m building.

Check it out at Oops Backup

I’m looking for brutally honest feedback. What’s the one feature your current backup solution is missing?

I built LogKitty — Android log viewer that doesn’t make you cry

Ivan Kovac — Mon, 13 Oct 2025 12:46:02 +0000

Hey folks,

I just launched LogKitty, a side project that grew out of my frustration with messy logs and clunky tools. It's a sleek, fast, and surprisingly lovable log viewer designed to help developers make sense of their logs without losing their sanity.

What it does:

Parses logs like a beast
Highlights errors, warnings, and patterns
Has a clean UI that doesn’t fight you
Built with devs in mind — no fluff, just flow
Analyze Android log with AI and provide the cause and solution

I’d love feedback, bug reports, feature ideas, or just validation that I’m not the only one who needed this. Try it out here:

logkitty.com

Thanks for checking it out!

DEV Community: Ivan Kovac