DEV Community: Akshay Jatin Solanki

I Wanted YouTube's Simplicity in VLC — So I Built My Own Media Player

Akshay Jatin Solanki — Thu, 01 Oct 2026 18:37:39 +0000

I Wanted YouTube's Simplicity in VLC — So I Built My Own Media Player

I use VLC because it plays almost everything.

MKV. MP4. WebM. AVI. MOV. Multiple audio tracks. Subtitles. You name it.

But there was one thing I kept wishing VLC had:

A simpler, more modern interface.

Something that felt as easy to use as YouTube, while keeping the flexibility of a desktop media player.

So I decided to build it.

Meet Simple YT Style Player — a lightweight media player inspired by YouTube's simplicity and VLC's versatility, now running on both Windows and Android.

View the project on GitHub →

Before vs After

The idea is easier to understand with a real example.

Imagine you've downloaded a large MKV movie containing:

Multiple audio languages
Embedded subtitles
A long runtime
A quiet audio mix

Before

You open a traditional media player and start searching through menus for:

Audio Track
Subtitle Track
Playback Speed
Aspect Ratio
Rotation
Brightness
Volume
Loop
Picture-in-Picture

The functionality is there, but the experience can feel unnecessarily complicated.

After

The goal with Simple YT Style Player is much simpler:

Open file
   ↓
Choose audio / subtitles
   ↓
Play
   ↓
Swipe / seek / adjust
   ↓
Keep watching

And when you need advanced controls, they're still there.

The idea was not to remove functionality — it was to make the functionality easier to reach.

What It Can Do

The player currently supports a surprisingly wide range of playback features.

Playback

MKV, MP4, WebM, AVI, MOV and other formats supported through FFmpeg
Multiple audio-track selection
Embedded subtitle support
Playback speed from 0.25× to 2×
Configurable skip interval
Looping
Resume playback
Touch scrubbing
Long-file hour-aware timestamps

Picture & Sound

16:9, 4:3 and source aspect ratio
Video rotation
Brightness adjustment
Volume up to 200%
Reactive audio visualiser with multiple themes
Picture-in-picture mode

Desktop Features

File associations
Auto-hiding playback controls
High-DPI support
Keyboard shortcuts

One Player, Two Platforms

One of the interesting parts of the project was making the same player work across Windows and Android.

The architecture is roughly:

             Simple YT Style Player
                       │
                Shared UI / Logic
                       │
              ┌────────┴────────┐
              │                 │
           Windows            Android
              │                 │
        Rust + FFmpeg      Rust + FFmpegKit
              │                 │
              └────────┬────────┘
                       │
                 Media Playback

The project uses Tauri 2 as the native shell and Rust for the core media operations.

The interface itself is intentionally lightweight:

Vanilla HTML + CSS + JavaScript.

No UI framework is required.

Why Rust + Tauri?

The first version of this project was built using Electron + HTML.

It worked, but I wanted the next version to feel more like a real native application.

So version 2 was rebuilt around:

Tauri 2
Rust
FFmpeg / FFprobe
Vanilla HTML/CSS/JavaScript

This gave me a shared application architecture that could target both desktop and mobile while keeping the core media logic in Rust.

The Android Problem I Had to Solve

One of the more interesting technical challenges was Android playback.

A normal Android file picker can return a content:// URI.

But the WebView-based interface cannot simply treat that URI like a normal local file.

So the application resolves the selected file and serves it through a local HTTP connection.

Why?

Because video playback engines naturally work with HTTP byte-range requests.

Instead of trying to force the player to consume an Android content:// URI directly, the application exposes the local file through a loopback connection and lets the video engine request the parts of the file it needs.

That also means seeking and buffering behave much more naturally.

Subtitles Without Extra Files

Another feature I wanted was support for subtitles embedded directly inside media containers.

For example, an MKV can contain:

Movie
├── Video
├── English Audio
├── Hindi Audio
├── English Subtitles
└── Hindi Subtitles

The player can inspect the container, expose the available subtitle tracks, and allow the user to switch between them without requiring separate .srt files.

The same idea applies to multiple audio tracks.

The Controls Stay Out of the Way

One design choice I particularly like is the auto-hiding control interface.

During playback, the controls disappear rather than permanently occupying the screen.

On mobile, the layout also adapts between portrait and landscape orientation.

The goal is simple:

The video should remain the focus.

Picture-in-Picture

Sometimes you don't actually want the video to stop just because you need to use another application.

The player therefore supports picture-in-picture, allowing playback to continue in a smaller floating window.

This is particularly useful for tutorials, lectures, reference videos and long-form content.

Keyboard Shortcuts

The desktop version also supports familiar keyboard controls:

Key	Action
`Space` / `K`	Play / Pause
`M`	Mute / Unmute
`O`	Open a file
`F`	Fullscreen
`I` / `P`	Picture-in-picture
`←`	Skip backward
`→`	Skip forward

No Account. No Ads. No Telemetry.

This is one of the principles behind the project.

The player is designed to play your files.

There is:

No account
No sign-in
No advertising
No analytics
No external backend required for playback

It can work completely offline.

Windows + Android Releases

The current repository provides builds for:

Windows 10 / 11 (64-bit)

and

Android 8.0+ (arm64)

The installers and APK are available from the GitHub Releases page.

Download the latest release →

Build It Yourself

The project is open source and can also be built from source.

Windows

npm install
npm run tauri:build

For development:

npm run tauri:dev

Android

rustup target add aarch64-linux-android
npm run android:dev

For an APK:

npm run android:apk

The repository also includes automated Rust tests for media probing, subtitle extraction and audio remuxing using real FFmpeg-generated media fixtures.

Architecture

The project separates the user interface from the platform-specific media implementation.

This became especially important when adding Android support because Windows and Android cannot execute FFmpeg in exactly the same way.

Windows uses FFmpeg sidecar processes, while Android uses FFmpegKit in-process through JNI.

The higher-level player logic can still remain shared.

From a "Skin" to a Real Player

The project started from a simple idea:

"What if VLC had a cleaner, more YouTube-like interface?"

But that idea gradually grew into something bigger.

Version 1 was an Electron + HTML implementation for Windows.

Version 2 became a Rust + Tauri 2 application for Windows and Android, with a growing set of playback and mobile features.

So although the repository is still called:

vlc-youtubeskin

the project has evolved into something closer to a standalone media player.

What I Want to Build Next

There is still plenty I'd like to improve.

Possible future directions include:

More playback controls
Better media library management
Additional mobile polish
More visual themes
Playlist support
Further performance improvements

The project is still evolving.

Try It

If you've ever wanted something between VLC's compatibility and YouTube's simplicity, give it a try.

⭐ GitHub — Simple YT Style Player

The project is released under the MIT License.

And that's really how this started:

I wanted a media player I'd actually enjoy using, so I built one.

Outlook Can't Search Multiple Categories — So I Built It

Akshay Jatin Solanki — Thu, 01 Oct 2026 18:31:59 +0000

Outlook Can't Search Multiple Categories — So I Built It

I use Outlook categories heavily to organise email.

Project. Client. Follow Up. Important. Finance.

The problem came later.

Once I had several categories assigned to hundreds or thousands of emails, I wanted to do something simple:

"Show me emails that have BOTH Project AND Follow Up."

Or:

"Show me emails that have Finance OR Client."

That is where Outlook's native search became frustrating.

So instead of continuing to manually scroll through folders and emails, I built my own multi-category search tool using Outlook VBA.

View the project on GitHub →

What I Built

The tool adds a dedicated search panel to Classic Outlook on Windows.

You can select multiple categories and choose how they should be matched:

AND — an email must contain all selected categories
OR — an email must contain at least one selected category

Then you can further narrow the results using additional filters.

Before vs After

Here's the kind of problem that led me to build it.

Imagine you have an email history containing:

500+ emails
↓
Categories:
Project
Client
Follow Up
Finance
Important

You want:

Find emails tagged Project + Follow Up from a particular sender, received this month, including only messages with attachments.

Before

The workflow becomes a collection of manual steps:

1. Open Outlook search
2. Filter by category
3. Check results manually
4. Try another filter
5. Open messages one by one
6. Repeat across folders/subfolders
7. Remember which emails you already checked

The more conditions you add, the more tedious it becomes.

After

With the VBA search panel:

Categories:
☑ Project
☑ Follow Up

Match:
◉ AND
○ OR

Sender:
client@example.com

Date:
01 Sep → 30 Sep

Attachments:
☑ Only emails with attachments

Scope:
Inbox + Subfolders

Then:

Click Search.

The results are returned in a single grid showing the subject, sender, received date, categories and folder.

From there you can double-click an email, export the results to Excel, or save the matched emails to another Outlook folder.

That was the whole idea behind the project:

Turn a frustrating manual search into one repeatable query.

Features

Feature	What it does
Multi-category search	Search multiple Outlook categories together using AND / OR logic
Scope control	Search the Inbox, subfolders, whole mailbox, or shared mailboxes
Sender filter	Filter results by sender
Keyword filter	Search subject or email body
Attachment filter	Find emails with attachments
Date range	Filter emails by received date
Results grid	View subject, sender, date, categories and folder
Open email	Double-click a result to open the message
Export to Excel	Export the result list
Save to folder	Move or copy matched emails to another Outlook folder

Everything runs locally inside Outlook.

There is no external server, third-party service, or data upload involved.

Why I Built It

The interesting part wasn't really the VBA form.

The real problem was information retrieval.

I had already done the work of categorising my emails. The categories contained useful information about the context of each message.

But once there were many categories, finding the exact combination I needed became difficult.

I wanted something that felt less like manually navigating an email client and more like querying my own organised email history.

So the workflow became:

Categorise → Select conditions → Search → Get the exact matching emails

The Technical Part

One of the most important implementation decisions was avoiding a simple loop through every Outlook mail item.

A straightforward approach would look something like this:

For Each objItem In objFolder.Items
    ' Inspect the email
Next

That works, but it becomes increasingly expensive as the mailbox grows.

Instead, the tool uses Outlook's Folder.GetTable functionality.

Dim objTable As Outlook.Table

Set objTable = objFolder.GetTable( _
    Filter:=strDASL, _
    Columns:="Subject,ReceivedTime,SenderName,Categories,EntryID")

The idea is simple:

Read the properties required for the search without fully opening every email.

This keeps the search process lightweight, particularly when working with larger mail folders.

Exact Category Matching Matters

There is another small detail that can cause surprisingly bad search results.

Imagine you have these categories:

HR
HRS
HR-Policy

A simple substring test such as:

If InStr(1, strCats, "HR", vbTextCompare) > 0 Then

can produce false matches.

The tool therefore uses token-based category matching so that HR is treated as a distinct category rather than simply matching text containing HR.

That sounds minor, but it makes the search results much more trustworthy.

Search Scope

Another thing I wanted was control over where the search happens.

The tool supports searching across different scopes rather than forcing everything into a single folder.

That means you can use the same search idea for:

Inbox
Inbox + Subfolders
Whole Mailbox
Shared Mailboxes

This becomes especially useful when Outlook rules have already distributed emails across multiple folders.

The Results Window

The search results are presented in a grid containing information such as:

Subject
Sender
Received Date
Categories
Folder

From there, you can open a message directly, export the result list to Excel, or save the matching emails to another Outlook folder.

So the tool is not only a filter — it is intended to be a small workflow around finding and acting on the results.

Installation

The project is VBA-based, so there is no traditional installer.

1. Open Outlook's VBA Editor

Press:

Alt + F11

2. Import the VBA module

Import:

modCategorySearch.bas

3. Create the two UserForms

Create:

frmCategorySearch
frmResults

Then paste the corresponding form code from the repository.

4. Run the macro

Run:

ShowCategorySearch

You can also add the macro to Outlook's Quick Access Toolbar.

The complete installation instructions are available in the repository README.

Project Structure

Email_Categorizer_outlookvba/
├── modCategorySearch.bas
├── frmCategorySearch_code.txt
├── frmResults_code.txt
└── Smart_Email_Search_no_logo.png

Privacy

This was designed as a local productivity tool.

The repository does not require a web service or external backend.

The search runs through Outlook VBA on the user's machine.

Limitations

This project is intentionally built around Classic Outlook on Windows and VBA.

That also means it comes with the limitations of Outlook VBA itself.

There is no modern web-based add-in architecture here, and installation currently involves importing the module and creating the required UserForms.

For this project, that trade-off was acceptable because the goal was straightforward:

Make searching my categorised Outlook mail significantly easier without introducing an external application.

What I Want to Improve Next

There are several directions I'd like to explore:

Easier installation
Saved search presets
More advanced search combinations
A more polished interface
Potentially a proper Outlook add-in implementation

But for now, the VBA version solves the problem I originally set out to solve.

Try It

If you use Outlook categories heavily and have ever wished you could search several of them together, you can check out the project here:

⭐ GitHub — Outlook VBA Multi-Category Search

The project is released under the MIT License.

I'd especially be interested in hearing from people who use large Outlook mailboxes and have found other limitations in Outlook's native category/search workflow.

Built because sometimes the best way to fix a productivity problem is to build the missing feature yourself.

I Built My Own AI Copilot for Excel Desktop — Without Paying for Microsoft 365 Copilot

Akshay Jatin Solanki — Mon, 21 Sep 2026 06:01:10 +0000

I use Excel a lot.

And like many Excel users, I eventually wanted something more powerful than formulas, VBA, and endless clicking.

I wanted to be able to say:

«"Clean this data."»

«"Find the duplicate customers."»

«"Create a chart from this table."»

«"Format this report professionally."»

«"Add formulas to calculate the margin."»

«"Find the errors in this workbook."»

…and have AI actually do it inside Excel.

Microsoft already has a solution for this: Copilot for Excel.

So naturally, I tried it.

And after using it, I had a question:

What if I could build my own version?

Not another chatbot that tells me which Excel formula to type.

I mean an actual AI assistant sitting inside native Excel Desktop, capable of turning natural-language instructions into real Excel operations.

So I started building one.

And this is what came out of it:

🚀 Excel AI Assistant

GitHub repository:

https://github.com/akshayai1996/excel-addin-ai

The project is an Excel Desktop add-in that provides a Copilot-style AI sidebar, but instead of being tied to Microsoft's Copilot experience, it uses OpenCode as the AI interface.

The basic idea is:

          ┌─────────────────────┐
          │     Excel Desktop    │
          │                     │
          │  ┌───────────────┐  │
          │  │   AI Sidebar  │  │
          │  │               │  │
          │  │ "Clean this   │  │
          │  │  spreadsheet" │  │
          │  └───────┬───────┘  │
          └──────────┼───────────┘
                     │
                 Office.js
                     │
                     ▼
          ┌─────────────────────┐
          │   Python Bridge     │
          │  bridge_server.py   │
          └──────────┬──────────┘
                     │
                  OpenCode
                     │
                     ▼
          ┌─────────────────────┐
          │  AI Model / Provider│
          └─────────────────────┘

The important part is that the AI doesn't directly manipulate Excel.

It produces structured actions.

Those actions are then validated and executed by the Excel add-in.

That distinction ended up being one of the most important architectural decisions in the project.

Why I Started Building This

My original motivation wasn't:

«"I want to replace Microsoft."»

It was much simpler.

I wanted an AI assistant that I could actually use for long Excel sessions without constantly worrying about the Copilot usage allowance.

When I experimented with Microsoft Copilot for Excel, I found that after a relatively small number of interactions/edits, I could hit usage limitations.

For someone doing serious spreadsheet work, that changes the experience.

Imagine working on a complicated engineering workbook and telling the AI:

Fix the formulas.

Then:

Now format the headers.

Then:

Create a summary sheet.

Then:

Add a chart.

Then:

Find anything that looks wrong.

An AI assistant becomes much more useful when you can keep iterating.

So I started wondering:

Why should the Excel interface and the AI provider have to be the same product?

What if Excel was simply the interface...

…and I could choose the AI layer separately?

That became the idea behind this project.

The Core Idea

The project tries to separate three things:

Excel

Excel remains the actual spreadsheet application.

AI interface

The sidebar communicates with an AI system through OpenCode.

Excel execution engine

JavaScript receives structured instructions and performs the actual Excel operations through Office.js.

So instead of:

User → AI → Random JavaScript → Excel

I designed it more like:

User
↓
Natural language
↓
AI
↓
Structured Excel actions
↓
Validation
↓
Office.js execution
↓
Excel

That architecture makes the AI layer much easier to control.

What Can I Ask It To Do?

This is where it becomes interesting.

The assistant isn't just answering questions about Excel.

It can perform actual workbook operations.

For example:

"Create a table from A1:F500."

or:

"Sort the sales data by revenue descending."

or:

"Find duplicate customer IDs and highlight them."

or:

"Add a formula for profit margin."

or:

"Create a column chart showing monthly revenue."

or:

"Freeze the top row."

or:

"Replace all occurrences of LTCS with CS."

It also supports more advanced workbook operations such as pivot tables, charts, conditional formatting, formatting, formula operations, structural changes, and other Excel actions.

The AI converts the request into a structured action.

For example, conceptually:

{
"type": "sort_range",
"sheet": "Sales",
"range": "A1:F500",
"column": 6,
"ascending": false
}

The Excel execution layer then interprets that instruction.

The model doesn't get unrestricted access to execute arbitrary JavaScript.

That's intentional.

Natural Language → Actions

This is probably my favourite part of the architecture.

Suppose I tell the assistant:

«"Format this report professionally."»

That's vague.

The AI might decide that this means:

Identify the header row
Make headers bold
Apply suitable number formats
Add borders
Adjust column widths
Freeze the header row
Create a table

Those become structured Excel actions.

Something like:

format_range
set_number_format
borders
freeze_panes
create_table

The execution layer handles them.

This means the AI can reason about the workbook while the deterministic JavaScript layer remains responsible for actually changing it.

I Didn't Want Just Another Chatbot

There are already thousands of AI chat interfaces.

I wasn't interested in building another one.

The interesting question for me was:

«Can an AI assistant actually operate Excel?»

There's a huge difference between:

AI says:

«"You can use "=SUM(A1:A100)"."»

and:

AI actually inserts the formula into Excel.

The second one is much more useful.

That's the experience I was trying to build.

The Excel Add-in

The frontend is built using the Office.js ecosystem.

The main pieces are:

taskpane.html
taskpane.css
taskpane.js
excel_actions.js

The task pane provides the conversational interface.

"taskpane.js" handles the assistant interaction and communication with the bridge.

And "excel_actions.js" acts as the Excel execution layer.

The latter is intentionally substantial because Excel operations aren't always as simple as:

range.values = ...

Real spreadsheets have:

formulas
formatting
tables
charts
merged cells
hidden rows
hidden columns
filters
conditional formatting
freeze panes
structural changes
workbook state
undo requirements

So the execution layer needs to be much more careful.

The Python Bridge

The second major component is:

server/bridge_server.py

This acts as the bridge between the Office.js frontend and OpenCode.

Conceptually:

Excel WebView
↓
HTTP request
↓
Python bridge
↓
OpenCode
↓
AI model
↓
Structured response
↓
Excel

The bridge also contains the system instructions that tell the AI what kinds of Excel actions it is allowed to generate.

This is important.

Instead of asking the model:

«"Give me some JavaScript to modify Excel."»

I ask it to produce a known action format.

That gives the application a much clearer contract between the AI and Excel.

Why OpenCode?

This project isn't based on a single hard-coded AI model.

That's deliberate.

OpenCode provides an interface through which different AI models/providers can be used.

That means the Excel interface doesn't have to care whether the underlying model changes.

The architecture becomes:

Excel AI Assistant
│
▼
OpenCode
│
├── Model A
├── Model B
├── Model C
└── Other supported providers

That separation is powerful.

The Excel add-in becomes the product.

The AI model becomes an interchangeable component.

And that's exactly what I wanted.

One Important Clarification: This Is Not a "Fully Local AI" Project

I want to be very clear about this because "local AI" can be misleading.

The Excel add-in and Python bridge run locally on the user's computer.

However, OpenCode can communicate with cloud-based AI providers depending on the configuration and model being used.

So I'm not claiming:

«"Your spreadsheet never leaves your computer."»

That's not the point of this project.

The point is different:

«You can build a Copilot-style Excel experience while choosing the AI layer independently of Microsoft 365 Copilot.»

If someone configures OpenCode with a local model, that's a different setup.

If they configure it with a cloud provider, the model provider's data handling and policies apply.

I think being explicit about this is important.

What About Cost?

This is another area where I don't want to make misleading claims.

The project itself doesn't require a Microsoft 365 Copilot subscription.

But that does not mean AI inference is universally free.

Depending on how OpenCode is configured, the underlying model/provider may have:

free usage
paid usage
rate limits
API limits
account requirements
subscription requirements

So I wouldn't describe this project as:

«"Unlimited free AI."»

Instead, I'd describe it as:

«"A Copilot-style Excel interface where the AI backend is decoupled from Microsoft 365 Copilot."»

That distinction matters.

Safety Was a Big Concern

Giving an AI access to a spreadsheet is different from asking it to write a poem.

A bad Excel action can potentially destroy data.

So I didn't want the architecture to simply be:

AI → execute whatever it says

The project includes several layers intended to make workbook modifications safer.

Structured actions

The AI generates known action types instead of arbitrary JavaScript.

Validation

The bridge validates the structured response before passing it to the execution layer.

Transaction-style execution

The Excel execution layer is designed around grouped operations and state management.

Undo / redo

The project includes transactional undo/redo functionality.

Workbook backups

Automatic ".xlsx" backups can be created before batches of modifications.

These aren't guarantees that an AI can never make a mistake.

They're safeguards around an inherently probabilistic system.

It Can Work With Charts, Pivot Tables and More

One thing I particularly wanted was for the assistant to go beyond simple cell edits.

For example:

«"Create a chart showing revenue by month."»

or:

«"Create a pivot table summarising sales by region."»

or:

«"Highlight negative margins with conditional formatting."»

The assistant can translate these requests into structured Excel actions rather than merely explaining how to perform them manually.

That turns the interaction from:

Chatbot + instructions

into:

AI + spreadsheet manipulation

which is a much more interesting application.

I Also Added Test Workbooks

The repository includes test data such as:

test-data/
├── messy_test.xlsx
├── sales_test.xlsx
└── make_test_workbooks.py

I think this is important for an AI-powered spreadsheet application.

You don't want to test everything against your only important workbook.

A deliberately messy workbook gives the assistant something realistic to work on.

For example:

Messy data
↓
AI analysis
↓
Cleaning actions
↓
Excel execution
↓
Verification

That's a much better development loop.

The Project Structure

At a high level:

excel-addin-ai/
│
├── manifest.xml
├── README.md
├── DESKTOP_SETUP.md
├── setup_desktop.ps1
├── start_server.bat
│
├── server/
│ └── bridge_server.py
│
├── src/
│ ├── taskpane.html
│ ├── taskpane.css
│ ├── taskpane.js
│ └── excel_actions.js
│
├── assets/
│ ├── screenshots
│ ├── demo media
│ └── icons
│
└── test-data/
├── messy_test.xlsx
├── sales_test.xlsx
└── make_test_workbooks.py

It's intentionally not a giant AI framework.

It's basically:

Office.js + JavaScript + Python + OpenCode + Excel.

Installing It

The project is primarily aimed at Excel Desktop on Windows.

The repository contains setup scripts and documentation for the desktop environment.

The rough flow is:

Clone repository
Install dependencies
Start local bridge
Sideload Excel manifest
Open Excel Desktop
Open the AI task pane
Start talking to your workbook

The repository contains more detailed setup instructions here:

GitHub:
https://github.com/akshayai1996/excel-addin-ai

Now I Want Your Honest Feedback

This is where I need the DEV community.

I've built the thing.

I've tested it myself.

But I'm one person testing my own tool, and that's a terrible way to discover every weakness.

So if you're an Excel user, developer, automation engineer, data analyst, or just someone who spends too much time inside spreadsheets:

Try it. Break it. Be brutally honest.

Don't just tell me:

«"Nice project!"»

Tell me:

«"This doesn't work."»

«"Why does it do this?"»

«"This workflow is annoying."»

«"It should understand this automatically."»

«"This Excel operation needs to be supported differently."»

«"The AI generated the wrong action here."»

«"The UI needs to work like this instead."»

That's the feedback I'm actually looking for.

I'd especially love to hear what happens when you throw real-world Excel tasks at it rather than carefully prepared demo prompts.

Try messy workbooks.

Try large datasets.

Try formulas.

Try formatting.

Try charts.

Try pivot tables.

Try multi-step instructions.

Try deliberately ambiguous requests.

Try something that you think an Excel Copilot should be able to understand.

Then tell me what broke.

What Should I Improve?

I don't want to decide that for the community before hearing from people who actually use it.

Maybe the biggest problem is the UI.

Maybe it's workbook context.

Maybe it's the AI's reasoning.

Maybe it's execution reliability.

Maybe it's speed.

Maybe it's handling large workbooks.

Maybe it's something I haven't even considered.

Tell me.

The goal of this project isn't to claim that I've built the perfect Excel AI assistant.

The goal is to build something useful, test it with real users, and keep improving it.

The Bigger Idea

The interesting part of this project isn't really Excel.

It's the architecture.

We're entering a world where AI can understand natural language but traditional software still provides the deterministic execution layer.

That creates a useful pattern:

Human intent
↓
AI
↓
Structured commands
↓
Deterministic software
↓
Real-world result

Excel happens to be a particularly interesting environment for this because spreadsheets contain a huge amount of structured information but still require enormous amounts of manual interaction.

Imagine applying the same pattern to:

CAD
engineering software
project management
ERP systems
data analysis
reporting tools
document management
financial modelling

The AI doesn't need to replace the application.

It can become a natural-language control layer on top of the application.

That's what I'm experimenting with here.

So… Did I Build "Microsoft Copilot"?

No.

And I don't want to pretend I did.

Microsoft has a massive ecosystem behind Copilot, and this project is nowhere near that scale.

What I built is something more specific:

«A personal, extensible, Copilot-style AI interface for native Excel Desktop, where the AI backend can be changed independently through OpenCode.»

And honestly, that's what makes the project fun.

I don't need to wait for a vendor to decide what my spreadsheet assistant should be able to do.

I can build the workflow myself.

Try It

The project is open on GitHub:

https://github.com/akshayai1996/excel-addin-ai

If you're an Excel power user, Office.js developer, AI developer, or someone experimenting with AI agents controlling traditional desktop software, I'd genuinely like to know:

What would you ask an AI assistant to do inside Excel?

And more importantly:

What would you change after actually using it?

Try it.

Give me the good feedback.

Give me the bad feedback.

Give me the "why the hell did it do that?" feedback. 😄

That's probably where the next version will come from.

Final thought

The question that started this project was surprisingly simple:

«"Why should I have to use one specific AI assistant just because I'm using Excel?"»

So I built an alternative.

Not perfect.

Not finished.

But it works.

Now I want other Excel users and developers to tell me what I got wrong — and what I should build next. 🚀

I Was Tired of Saving Outlook Attachments One-by-One — So I Automated It

Akshay Jatin Solanki — Mon, 18 May 2026 15:52:41 +0000

I Was Tired of Saving Outlook Attachments One-by-One — So I Automated It

If you work heavily with Microsoft Outlook in a corporate environment, you probably know this painful routine:

Open email
Download attachment
Save file
Repeat again
Repeat 100 more times

It sounds small.

But when your work involves:

engineering documents
vendor quotations
datasheets
project files
MOMs
RFQs
procurement emails
client deliverables

…it becomes a massive repetitive productivity drain.

Especially in EPC, engineering, documentation, procurement, and project management workflows.

At one point I realized:

I was spending more time downloading attachments than actually doing meaningful work.

So I decided to automate it.

The Problem

Microsoft Outlook still doesn’t provide a clean native way to:

✅ Select multiple emails
✅ Download all attachments together
✅ Handle duplicate filenames safely
✅ Skip useless signature images
✅ Avoid repetitive clicking

Instead, the normal workflow looks like this:

❌ Open email
❌ Download attachment
❌ Save file
❌ Close email
❌ Repeat manually forever

For a few emails this is okay.

For hundreds of emails every week?

Not okay.

The Idea

I built a VBA automation tool for Outlook that allows me to:

Select multiple emails at once
Download all attachments automatically
Handle duplicate filenames
Skip inline/signature images
Prevent invalid filenames
Keep Outlook responsive during large batch operations

Now the workflow is:

✅ Select emails
✅ Run macro
✅ Choose folder
✅ Done

That’s it.

Real Productivity Impact

If you process:

100–200 emails/day
multiple attachments per email
large engineering/project documentation

this repetitive task alone can waste several hours every week.

The biggest realization for me was:

Small automation removes huge mental fatigue.

Not just time.

Mental fatigue.

Repetitive clicking slowly destroys focus during office work.

Automation fixes that.

Features

The tool includes:

Bulk Outlook attachment saving
Duplicate filename handling
Illegal filename sanitization
Inline/signature image filtering
OLE attachment filtering
MAX_PATH protection
Outlook UI responsiveness optimization
Defensive error handling
Performance optimization

It evolved from:

“simple VBA macro”

into:

“production-grade Outlook productivity automation.”

Example Workflow

Before:

❌ Open email
❌ Save attachment
❌ Repeat manually

After:

✅ Select all emails
✅ Run macro
✅ Everything downloads automatically

Who This Is Useful For

This turned out to be surprisingly useful for:

Engineering teams
EPC companies
Procurement departments
Documentation teams
Project managers
Corporate Outlook-heavy workflows
Anyone drowning in repetitive email attachments

Basically:

anyone who spends too much time inside Outlook.

Why I Shared It Open Source

A lot of office productivity problems are weirdly universal.

Thousands of people are probably repeating the same boring tasks every day manually because:

they don’t know automation is possible
nobody showed them
or they assume only “developers” can automate workflows

But small automation tools can genuinely save:

hours
frustration
repetitive effort
mental exhaustion

So I decided to publish this project publicly on GitHub.

GitHub Repository

Repository:

https://github.com/akshayai1996/Outlook-Bulk-Attachment-Saver

Future Improvements

Some ideas I may add later:

Sender-based folder sorting
Date-wise organization
CSV logging
Duplicate hash detection
ZIP extraction
Ribbon button integration
Progress bar
Power Automate integration

Final Thought

One thing I’ve started realizing recently:

A lot of impactful software is not flashy.

Sometimes the best tools are simply the ones that remove repetitive friction from everyday work.

This project started because I got tired of clicking “Save Attachment” hundreds of times.

Now it saves me hours every week.

And honestly, I wish Outlook had this feature natively.

productivity #automation #outlook #vba #office #workflow #opensource #engineering #microsoft #developers

From Frustrated to "Pro": Why I Built My Own Screen Annotation Suite from Scratch

Akshay Jatin Solanki — Fri, 17 Apr 2026 12:11:26 +0000

The Breaking Point 😫
I spent two days trying to simplify an existing, over-engineered annotation tool. It was full of bugs, heavy, and limited. I realized I was spending more time fighting the code than using the tool.

So, I did what any developer does when they reach a breaking point: I abandoned the mess and wrote it from scratch.

Introducing Simpink 🎨
I wanted something better than the "standard" tools like Epic Pen. I wanted something that felt like it belonged in 2026. After a session of intense, high-performance coding, I finished Simpink.

It’s built using Electron, Vanilla JS, and Hardware-Accelerated Canvas. It’s light, it’s fast, and it looks premium.

What makes it a "Gem"? 💎
I didn't just build a "drawing" tool; I built a presentation suite:

The Highlighter Halo: A persistent cursor aura so your audience never loses your mouse during a live demo.
Pro Video Recording: Native VP9 capture at 25 Mbps, featuring a high-fidelity Pause/Resume engine. (No more OBS required!)
Glassmorphic UI: A floating, draggable toolbar that looks like a part of a modern OS.
"The Orb": A unique minimize state that stays out of your way while keeping your tools accessible.
The "Simpink" Philosophy 🚀
I stripped away the bloat and focused on performance. Everything is rendered via the GPU for zero lag. I even converted my demonstration videos to cut the file size by 90% without losing quality—I wanted the smallest possible footprint for the user.

Open Source & Free 🌍
It is licensed under MIT. It is free for anyone—personal, professional, or commercial. Use it, break it, modify it.

Check out the code and grab the standalone installer on GitHub: 👉 https://github.com/akshayai1996/Simpink

If you've ever felt the urge to start over and build something better, let me know in the comments! Simpink is proof that sometimes, the "scratch" approach is the only way to go.

What I built in the last year — Excel VBA tools, Python scripts, HTML games & more

Akshay Jatin Solanki — Mon, 16 Mar 2026 04:21:57 +0000

Hi, I'm Akshay Jatin Solanki, an engineer from India.

Over the past year I've been building small focused tools that solve real problems. Here's a summary of what I've shipped:

🎮 Browser Games (HTML/JS)

Space Shooter — canvas-based, Web Audio, mobile + PC scaling
Chrome Dino clone — custom audio engine with Web Audio API

📊 Data Dashboards

India Housing Affordability Dashboard — 115 cities with real sqft/price data

🔧 Excel VBA Add-ins

Crosshair row/column highlighter
Merged cell filter
Navigator arrows
Delimiter text functions

🐍 Python & Numerical Tools

Cubic equation solver
Numerical integration utilities

♟️ Other

Chess agent framework with Stockfish WASM in-browser

All projects are minimal-dependency or single-file.

👉 GitHub: https://github.com/akshayai1996
👉 Web projects: https://akshayai1996.github.io/Htmlfun/
👉 LinkedIn Profile: https://www.linkedin.com/in/akshay-jatin-solanki/

Happy to get feedback on any of these!

DEV Community: Akshay Jatin Solanki

I Wanted YouTube's Simplicity in VLC — So I Built My Own Media Player

I Wanted YouTube's Simplicity in VLC — So I Built My Own Media Player

Before vs After

Before

After

What It Can Do

Playback

Picture & Sound

Desktop Features

One Player, Two Platforms

Why Rust + Tauri?

The Android Problem I Had to Solve

Subtitles Without Extra Files

The Controls Stay Out of the Way

Picture-in-Picture

Keyboard Shortcuts

No Account. No Ads. No Telemetry.

Windows + Android Releases

Build It Yourself

Windows

Android

Architecture

From a "Skin" to a Real Player

What I Want to Build Next

Try It

Outlook Can't Search Multiple Categories — So I Built It

Outlook Can't Search Multiple Categories — So I Built It

What I Built

Before vs After

Before

After

Features

Why I Built It

The Technical Part

Exact Category Matching Matters

Search Scope

The Results Window

Installation

1. Open Outlook's VBA Editor

2. Import the VBA module

3. Create the two UserForms

4. Run the macro

Project Structure

Privacy

Limitations

What I Want to Improve Next

Try It

I Built My Own AI Copilot for Excel Desktop — Without Paying for Microsoft 365 Copilot

I Was Tired of Saving Outlook Attachments One-by-One — So I Automated It

I Was Tired of Saving Outlook Attachments One-by-One — So I Automated It

The Problem

The Idea

Real Productivity Impact

Features

Example Workflow

Who This Is Useful For

Why I Shared It Open Source

GitHub Repository

Future Improvements

Final Thought

Tags

productivity #automation #outlook #vba #office #workflow #opensource #engineering #microsoft #developers

From Frustrated to "Pro": Why I Built My Own Screen Annotation Suite from Scratch

What I built in the last year — Excel VBA tools, Python scripts, HTML games & more

🎮 Browser Games (HTML/JS)

📊 Data Dashboards

🔧 Excel VBA Add-ins

🐍 Python & Numerical Tools

♟️ Other