I have been using RayCast from ~4 years. I built 2 extensions, ~20 custom scripts, contributed to existing extensions.

I raised support tickets related to automating RayCast exports & settings. Unfortunately, there was no good resolution.

FOSS Alternatives

When looking at open source alternatives I stumbled on Vicinae, RustCast long back but they were not drop in replacements.

Recently TinyCast came out and I am using it as a primary launcher on one of the Mac. It is working well as a drop-in replacement so far without any major issues.

It is just ~6MB(Raycast ~250MB) app and consumes ~60MB RAM (RayCast ~600MB).

Software as Moat

With AI, it is getting easy to build & customise software. There is a growing trend where users are shifting towards open source alternatives(since I am in FOSS space, I might be biased).

If you think software only is a moat, it is time to re-think again!

Harness

OpenCode & oh-my-pi come with batteries included and works out of the box.

Pi is barebones & lightweight. There are quality plugins available to extend the functionality & customise the behaviour. It is extremely extensible.

Inference Server

Ollama MLX doesn't generate tokens efficiently.

Rapix-MLX, omlx are excellent at utilizing resources and generating tokens efficiently. With M5 Pro 48GB RAM, they are able to generate ~50 tokens/second with Qwen3.6-35B-A3B-4bit model.

Llama.cpp is cross-platform and it is extremely fast as well.

Local LLMs

Qwen3.6-35B-A3B model made locall LLMs usable on decent hardware.

Qwen3.6-35B-A3B - has 35B parameters & only 3B are active at a time. I use 4bit quantized model as it provides a better tradeoff between speed and accuracy. It fits in 48GB RAM with some headroom for other applications.

Bonsai has highest intelligent densisty and it can run on ~5 GB RAM.

It is surprising how fast & powerful the local LLMs have become.

Context

Around 2016, I explored various speech-to-text (STT) tools to reduce strain on writs due to RSI(Repetetive Strain Injury) and gave up on them due to their limitations.

With AI advancements, these tools have come a long way.

Open Source STT Tools

Handy

TypeWhisper

FluidVoice

HyperWhisper

VoiceInk

There are couple of paid tools but they didn't work well in noisy environment.

After trying out all these tools with local models like Parakeet, Voxstral, and Cohere Transcribe, I found that Handy + Cohere Transcribe is the best combination for my needs.

Handy has post processing as an experimental feature where we can send output of STT to other LLM models and get a fine grained output.

For example, when I dictate "git push dash dash force", the output is "git push --force" after post processing.

Conclusion

I let AI to write handy_stats.py script to track my dictation stats. I am dictating more than 10K characters per day which reduces strain on my fingers/writs.

Why?

I have been using TailScale from 4 years. Recently, I wanted to self-host HeadScale(open source TailScale server) on my own server.

During self hosting, I realised that HeadScale is not a drop-in replacement for TailScale.

App connectors are main reason I was using TailScale and HeadScale doesn't support app-connectors.

NetBird

NetBird is completely open source and has a self-hosted server. Setting up split DNS tunneling and routing is easier with NetBird.

It has a clean web UI to manage network/policies which is way better than TailScale's web UI.

It also has a cool control center to visualize the network and connected devices.

It still doesn't have support for light theme yet. Since I am not accustomed to dark theme, I am using Stylus extension and changing the theme to light theme.

html { filter: invert(1) hue-rotate(180deg); background: #fff; }
img, svg, video, canvas, [style*="background-image"] { filter: invert(1) hue-rotate(180deg); }

Conclusion

NetBird can be self-hosted in few minutes and migration is much smoother than I expected.

CLI Tools: GitHub Copilot CLI, Claude Code & Open Code

IDE: GitHub Copilot Plugin

Caveman

Reduces token usage by eliminating clutter. It doesn't affect thinking/reasoning.

Alternatives: Ponytail

These tools will help in saving more than 30% of our time to read model output and money(tokens).

Claude-mem

Claude-mem preserves context across sessions by automatically capturing tool usage observations, generating semantic summaries, and making them available to future sessions. This enables Claude to maintain continuity of knowledge about projects even after sessions end or reconnect.

This will improve developer productivity as well.

Alternatives: AgentMemory (backed by Linux Foundation)

CodeGraph

We work with multiple code bases on a daily basis and claude-code spawns Explore agents that scan files with grep, glob and read. They consume tokens on every tool call.

CodeGraph provides a pre-indexed knowledge graph to those agents, which reduces 50% tokens.

Alternatives: Graphify

rtk

CLI proxy that reduces LLM token consumption by ~75% on common dev commands like ls, cat, git, etc.

Similar tool: Headroom

Misc

andrej-karpathy-skills

ccstatusline

Custom instructions for agents in plain markdown files

A little trust goes a long way

As a senior technical person, you will have certain professional authority. But to be effective, you need to build personal trust with your team and peers. That can happen only if you are approachable & transparent.

Set up 1:1 meetings with your team members and cross-functional team leads. Go on a listening tour and take your notes.

Be specific on how people can reach you and how you will communicate with them. Setup routine 1:1 meetings if required.

Follow the money

It is important to have high level overview of the business. This will help you make informed decisions and prioritize your work effectively.

If the company is public, you can get quarterly & annual reports. If not, try to get a good sense of where the money is coming from and where the money is going.

Follow the data

Get a high level overview of product(s), infrastructure, tools, data flow. This is crucial to make informed technical decisions or architectural changes.

Start Small

For the first 30 days, you should be in "listening mode" or "absorbing mode". Try to understand the company, the team, the product, the customers, the culture, and the processes.

It is better to avoid any big changes in the first 30 days. There will be plenty of time for that later.

30-60-90 Day Plan

Note down action items for next 60 and 90 days.

It could be anything from setting up a new monitoring system, to improving the deployment process, to hiring new team members, providing simple tools for self service, etc.

Commnicate the plan with all stakeholders and avoid any surprises.

Reduce Cloud & SaaS Costs

If these are a significant part of the company's expenses, then review the costs and see if there is any room for reducing these costs.

On cloud, moving compute instances to reserved or spot can save 70-90% of costs.

That can have a big impact on the company's bottom line.

Buy or build good tools

On the other hand, if there are any tools that can help the team to be more productive, then it is worth investing in those tools.

To do that, you should already have a good toolset under your belt.

Sometimes building a simple tool which can make team self sufficient can have a big impact on the team's productivity and morale.

Conclusion

The first 30 days in a senior technical role are crucial for building trust, understanding the business, and setting the foundation for the next step.

Without much work to do, you can have a big impact on the company by following the tips mentioned above.

The best code is the code you don't have to write

Config First Tools

Any tool that provides first class support for configuration files can be considered a Config First Tool. These tools allow developers to setup/build/deploy applications by writing configuration files instead of writing code.

In DevOps world, tools like Terraform, Ansible, and Kubernetes are examples of Config First Tools. These kinds of tools are not that popular in the web development world.

In this article, lets see how we can build a full stack web application using only configuration files.

Todo - Web App

A simple backend API that allows users to manage todo lists. A simple frontend that uses the backend API. A simple script to deploy the backend and frontend applications.

Backend API

PocketBase is a backend API that provides a simple way to create and manage databases, authentication, and file storage. It is a great tool for building simple backend APIs without writing any code.

$ brew install pocketbase
$ pocketbase serve

We can create a collection called Todo with required fields and pocketbase will automatically generate the API for us.

Frontend

Lowdefy is a config first tool that allows us to build web applications using yaml config.

$ npm install -g lowdefy
$ lowdefy init
$ lowdefy dev

For basic crud apps, instead of us writing the boilerplate config, we can ask an AI agent to write the config for us.

Deployment

For deployment, we can use Ansible to deploy both the backend and frontend applications. Here also we can just AI agent to write the playbook for us.

$ pip install ansible
$ ansible-playbook deploy.yml

OliveTin

Even though we can use ansible to deploy the applications, it is not that convenient to run ansible playbooks on mobile. OliveTin is a config first tool that allows us to create web UIs for our scripts.

  - title: "Deploy ToDo App"
    popupOnStart: execution-dialog
    shell: ansible-playbook deploy.yml
    timeout: 6000
    icon: "🤖"

We can create a simple web UI for our deployment script with just 5 lines.

Conclusion

For quick prototyping and simple applications, config first tools can be a great choice as they allow us to build applications without writing any code. They also allow us to focus on the application logic rather than the implementation details.

With the rise of AI, it is much easy to maintain 500 lines of config than 5000 lines of code.

During 25th Feb 2026, a joint meetup was hosted by BangPypers & SciPy India.

There was a slot for lightning talk & I gave a talk on Kraken2 performance optimisations titled as "Classify billion base pairs per second".

Since it was a lightning talk, I didn't had time to polish the slides. During the talk, I briefly covered:

• What is metagenomics?
• Overview of open source classification tools
• Brief intro to Kraken2
• Performance optimizations in Kraken2

Few years back, I wrote a series of posts on Mastering Kraken2 where I covered all the optimizations in detail. If you want to dig deeper into the topic, you can check out the series.

In a world of complex internal tools, OliveTin bridges the gap between raw CLI and usable web UI with just yaml config.

Server Admin Panel

I used admin panels like CockPit, Ajenti, etc to provide simple web UI for non-developers to provide access to services. Developing custom widgets is time consuming and requires programming skills as well.

With OliveTin, I can provide web UI directly with just yaml config. This saves a lot of time and effort. It also provides a clean UI as it starts from scratch.

Backend Driven UI

For existing python scripts, I often use tools like Streamlit, NiceGUI, etc to create web UIs. Organizing the UI components for multiple scripts is time consuming.

OliveTin can provide web UI directly python scripts and they can be organized in groups with just yaml config.

Mobile Friendly

To do a simple deployment on mobile, I need to open an app that supports ssh, ssh into the server, navigate to a directory, run a script to deploy.

OliveTin provides a "Deploy" button on mobile browser which is way convenient.

Authentication

OliveTin provides authentication(local users, OAuth2, JWT, etc), authorization(ACLs) & accounting(logs) out of the box. With just yaml config, we can secure the web UI.

Conclusion

There are hundreds of other features provided by OliveTin like scheduling, file uploads, webhooks, etc.

If you ever want to provide a simple web UI for scripts with low code or no code, give OliveTin a try!

Introduction

We learnt how to deploy kubernetes cluster anywhere with a single k3d command. By default, k3d cluster is accessible only from the host machine.

Remote Access

Create new cluster with

$ k3d cluster create cloud-k8s \
  --api-port 6443:6443@loadbalancer \
  --k3s-arg "--tls-san=<remote-ip>@server:*"

• --api-port 6443:6443@loadbalancer maps port 6443 on the host machine to the cluster's API server load balancer. This can be changed (e.g., 8080:6443) if 6443 is taken on the host.

• --k3s-arg "--tls-san=..." adds the host's public IP to the certificate, preventing SSL errors later.

• Ensure remote server firewall allows incoming traffic on the chosen port (e.g., 6443 or 8080). To verify, run telnet <remote-ip> 6443 from local machine.

On the remote server, get kubeconfig:

$ k3d kubeconfig get cloud-k8s
---
apiVersion: v1
clusters:
- cluster:
    server: https://0.0.0.0:6443
  name: k3d-rk
   ... # truncated for brevity

Copy this kubeconfig, replace 0.0.0.0 with the remote server's public IP.

Open Free Lens, paste this config and connect to the remote k3d cluster.

Conclusion

You can use your favorite Kubernetes tools (kubectl, FreeLens, k9s, etc.) to manage the remote k8s cluster.