Basevolt
Notion-style admin panel for your DB in < 60s. Local-first
Introducing AI Chat — Your Intelligent Workspace Co-Pilot 🤖
We are thrilled to introduce a powerful, built-in AI assistant directly inside Basevolt. This isn't just a basic chatbot; it is a smart collaborator that understands your data structure and can actively help you build and manage your workspace.
Here is what your new assistant can do for you:
Build Dashboards & Views Automatically: Instead of clicking around to set up your workspace, you can simply tell the AI what you need. Ask it to "create a project management dashboard" or "generate a view for high-priority tasks," and watch it spin up the structure automatically.
Direct Data Queries: Finding specific information is now as simple as asking a question. You can query your tables in plain language to pull exactly the numbers, records, or insights you are looking for without writing complex filters.
Configure Webhooks & Actions: Want to connect your data to other tools? Tell the AI to set up a webhook or connect an automation, and it will handle the heavy lifting of linking your system actions together.
Bonjour & 日本語 — New Languages Added 🌐
Basevolt is officially expanding its global footprint! We've introduced full native translation support for two new languages:
French (Français)
Japanese (日本語)
Every button, menu, and even the AI's response logic has been carefully localized to ensure a smooth, natural native experience from start to finish.
Sleeker Settings Panel ⚡
To support the new AI capabilities and multilingual choices, we've completely redesigned the preferences and settings window. It is now faster and cleaner than ever, letting you customize your workspace and swap between your preferred AI models with a single click.
Just shipped two features that turn Basevolt from "a database table viewer" into something that actually feels like a product:
Gallery View — records as visual cards 🖼️
Until now, every view in Basevolt was a table. Tables work, but they're terrible for image-heavy data — portfolios, product catalogs, team directories. Gallery View lets you browse records as cards with large images and clean layouts. Think Airtable's Gallery View, but local-first, running directly on your database.
Dashboard Widgets — build your own live dashboard 📊
This is the bigger one. Dashboards used to mean "connect your DB to Metabase and hope it works" or "build a custom dashboard from scratch." Now you can assemble one inside Basevolt with four widget types:
- Chart Widget — Bar, line, or area charts. Sales over time, signups by month, whatever trend you need.
- Metric Widget — Big number display. "Total Users: 1,247" or "MRR: $850." KPIs at a glance.
- Table Widget — Raw data when you need the details. Orders, customers, event logs.
- Text Widget — Titles, descriptions, annotations to organize the layout. Makes the dashboard readable for humans.
Mix and match all four. Drag them around. It's a live dashboard that reads directly from your database — no ETL, no cloud pipeline, no extra tools.
Why this matters (to me anyway):
I've been talking to early users and the feedback was pretty consistent: "I can see my data, but I can't understand my data." Tables show you rows. Dashboards show you meaning. Gallery View shows you context. These two features together close that gap.
Also — this puts Basevolt closer to "lightweight internal tool" territory. Not competing with Retool on complexity, but for the 80% of cases where someone just wants to see their data visually and track a few KPIs, it's getting there.
Question for other IH founders: I know I should be doing marketing right now. But every morning I open my editor and think "just one more feature, then I'll promote it." Building is what I'm good at. Putting myself out there is uncomfortable. For those who've been through this — did you force yourself to stop building and switch to marketing? How did you make that mental shift?
Hey Indie Hackers!
It’s time for another Basevolt update. For v0.8.4, I focused on reducing "friction" and "mystery"—the two things that kill productivity when managing databases.
Here’s what’s new in the lab:
💅 The UI Glow-up: Side Sheets are here
Gone are the days of jumping between pages just to check a record. Record details now slide open in a Side Sheet. This gives you more screen real estate and makes browsing linked records a breeze. It feels less like a database and more like a polished product.
🔗 Webhook Log Center (No more "Silent Failures")
We’ve all been there: a webhook fails, and you have no idea why. I’ve launched a dedicated Webhook Log Center where you can see every execution in real-time. The best part? If something goes wrong, you can retry with one click.
✨ No-SQL? No Stress.
I wanted to make complex data relations as easy as Notion. With the new Lookup & Rollup features, you can pull customer emails into invoices, calculate totals, or count records just by pointing and clicking. No complex SQL queries required.
🗺️ DataMap & Auto-IDs
DataMap: You can now switch between a clean UI View and a deep-dive Data View instantly.
ID Generation: For those using plain strings, we now support auto-generating UUIDs or ULIDs.
Basevolt is still the same local-first tool you love, just smoother, smarter, and with way less clicking around.
I’d love to hear your thoughts:
What’s the most annoying part of your current admin workflow? I’m looking for more "boilerplate taxes" to kill in the next version!
One of the biggest pain points when building admin panels is "silent failures" in automations. You trigger an action, but you have no idea if the webhook actually hit the server or why it failed.
I just finished the Webhook Log logic for Basevolt!
Now, instead of digging through server logs or guessing, you can see every outgoing hook directly in your local admin panel.
What’s included:
Real-time status: Instantly see Success/Fail codes.
Payload Inspection: View exactly what data was sent.
Error Debugging: Catch failed triggers before they affect your production data.
I’m currently stress-testing this locally to ensure it stays "strictly local" and lightning-fast. It will be part of the next release.
As a local-first tool, adding this operational layer without adding technical debt to your main repo has been a fun challenge.
Would love to hear from fellow IHers: What's the most annoying part of managing webhooks in your current setup?
-
1
NICE JOB !
-
1
Nice — “silent failures” is such a real pain point.
Having logs inside the admin panel instead of digging through server logs is a big win.
The most annoying part for me has been:
→ not knowing if a failure is my payload, their endpoint, or timing/retries
→ and having no clean way to replay failed webhooksIf you add:
→ retry / replay
→ basic failure categorizationthat becomes super powerful.
Also, I’m running a small project (Tokyo Lore) where we highlight tools solving dev pain like this.
Since you’re building a clean local-first solution, this could resonate well — happy to share more if you’re interested 👍
-
1
You're speaking my language! Actually, both one-click Replay and Status/Categorization filtering are already live in the current build.
I built them precisely for that reason—nothing kills productivity faster than manually re-triggering a flow just to see if a payload tweak worked.
Regarding Tokyo Lore, I have to admit I’m not familiar with it yet, but it sounds like exactly the kind of community Basevolt belongs in. I’d love to hear more about what you guys are doing and how I can get involved.
Thanks for the heads-up! 🚀
-
1
That’s perfect — replay + categorization already solves 80% of the real pain 👍
Totally agree, manually re-triggering flows is the worst.
On Tokyo Lore — it’s a small, focused round where we highlight tools like this and put them in front of builders who actually use/debug systems daily.
The idea is to see:
→ what clicks instantly
→ what people rely on
→ what becomes part of their workflowSince Basevolt is solving a very real dev pain (and doing it cleanly), it could fit really well.
Here’s the link: tokyolore.com
Happy to walk you through it if you want 👍
-
-
-
1
This hits home — the “silent failure” problem with webhooks is way more common than people admit. I’ve run into situations where everything looked fine from the UI, but something broke in between and there was zero visibility into what actually happened.
Really like the idea of having logs directly in the admin layer instead of jumping between tools.
Curious — since this is local-first, how do you handle scenarios where debugging needs to happen across environments (like staging vs production)? Do you see this staying purely local, or is there a plan to optionally sync/share logs when teams need visibility?
Also, the “Notion for databases” angle is interesting — especially for quickly spinning up internal tools. Have you tested this with more complex relational schemas (e.g., deeply nested relationships)? That’s usually where most admin tools start to struggle.
-
1
High-five on the "visibility" part! It’s all about peace of mind.
To your questions:
1. Cross-environment: Basevolt is a desktop tool, so you just switch your connection to see logs for Staging or Prod. No cloud middleman. For teams, I’m leaning towards "Export to share" or simple snapshots. My goal is to keep your data under your control, not host it on my servers.
2. Complex Schemas: This is actually where Basevolt shines. I've designed the Data Map to handle those messy, deeply nested relationships that usually break standard tools. You can even define "Virtual Relations"—linking tables that aren't physically connected in the DB—to make a complex schema look as simple as a Notion page.
It’s built to handle real-world database "chaos" without the typical CRUD limitations. 🛠️
-
-
1
Most developers have experienced that sinking feeling when a user reports a data mismatch, and you're left digging through messy cloud logs or raw database entries trying to piece together where a trigger went silent. It is a massive waste of time to build a custom dashboard just to monitor outgoing signals, yet flying blind often leads to critical production errors that go unnoticed for days. Since you are maintaining a "strictly local" philosophy, how do you handle the storage and rotation of these webhook logs so they don't eventually bloat the user's local environment or impact the performance of the admin panel?
-
1
Great question! This is exactly why a local-first approach shines.
For storage, logs are kept in a local SQLite instance separate from the production DB, so there's zero impact on your actual data performance.
Regarding "bloat," I’ve implemented an auto-rotation policy: users can set a retention limit (e.g., keep last 5,000 logs). Since it's all local, even 10k logs is just a few MBs—nothing compared to the gigabytes wasted by typical cloud logging agents.
It’s all about giving the dev visibility without the infrastructure tax.
-
1
Using a separate SQLite instance is a clever move because it decouples the debugging noise from the actual production environment. Setting a rotation policy like that gives developers the visibility they need without the typical infrastructure tax or bloat that usually comes with cloud logging.
It reminds me of how I approach Digital PR and Media Placements on sites like MSN or AP News. In that field the strategy is all about ensuring the technical foundation is solid so that when we push for high authority placements the results are predictable rather than a guessing game. Having that same kind of transparency in your local environment means you can scale without worrying about hidden failures.
Keeping the retention limit user-definable is definitely the right way to maintain that lightning fast feel while keeping the environment clean.
-
1
Totally agree, no more guessing. Getting the basics right early makes scaling way easier. Thanks for the input, Muhammad!
-
1
Spot on, Dylan! Whether it's a solid technical foundation for an app or a high-authority PR campaign, 'predictability' is the key to scaling. I actually apply the same level of precision when I’m placing brands on MSN or AP News—ensuring every link is technically sound and indexed. Since you're also in this space, I'd love to swap some notes or even collaborate if you have clients looking for that kind of high-authority reach.
-
-
-
-
Hello Indie Hackers!
I’m a developer who loves building, but I’ve always hated one thing: creating internal admin panels.
Every time I start a new project, I find myself stuck in the "Boilerplate Tax"—writing the same CRUD logic, forms, and tables over and over again. I tried using AI to generate code, but managing fragmented codebases for multiple projects became a mess. I also tried traditional DB clients, but they felt too "raw" when I needed to see relations or media assets.
That’s why I built Basevolt.
It’s a local-first desktop app that turns any SQL database into a polished, Notion-style admin panel in under 60 seconds.
Key philosophy behind it:
Zero Deploy: Just connect your DB and start managing data.
Local-first: Your data stays on your machine. Privacy by design.
AI-Enhanced: It automatically handles naming and icons so it feels like a real product, not a spreadsheet.
I just added Webhook & Action logs to help debug local-first workflows, and I'm currently working on an AI-assisted Dashboard to give founders a "Command Center" view without writing a single line of SQL.
I’d love to hear your "brutal" feedback. What’s the most annoying part of your current admin workflow?
Comment