Forem: Sudhanshu

Expense Buddy: Local-first expense tracking with GitHub sync

Sudhanshu — Sun, 18 Jan 2026 03:37:22 +0000

I’ve tried a bunch of expense trackers over the years, and I kept running into the same problems: slow flows, cluttered screens, and a nagging feeling that I was handing over more data than I should. So I built my own.

Expense Buddy is a privacy‑first, local‑first expense tracker that stays out of your way. It’s built with React Native (Expo), keeps everything on‑device by default, and gives you optional GitHub sync if you want a personal backup you control.

Why Expense Buddy exists

Most expense trackers either felt slow, intrusive, or vague about where my data lived. I wanted something simple enough to open daily, fast enough to never frustrate me, and honest about storage. Expense Buddy is the result—focused on clarity, speed, and ownership:

Local-first by default (your data stays on-device)
Private by design (no analytics, ads, or data selling)
Fast on large datasets with a lightweight UI
In your control with optional GitHub sync to your own repo

Feature highlights

Daily expense tracking with category and payment method tags
Edit expenses anytime with a full history view to revisit and update past entries
Smart GitHub sync with incremental, differential, and batched commits
Analytics that go deeper: category and payment method breakdowns, instrument‑level splits, plus a spending trend chart
Custom categories with colors and icons
Saved payment instruments (cards and UPI IDs)
In‑app update notes with a “What’s New” sheet after updates
Issue reporting directly from Settings
Light and dark mode with theme‑aware styling

Dashboard

The dashboard is my “daily check‑in” screen. It gives me a quick view of recent spending and a simple 7‑day trend. I made the graph tappable because I kept wanting to jump straight into that day’s entries.

Add expense

Adding an expense should be boring—in a good way. It’s a one‑screen flow with quick category and payment method picks so I can log something in a few seconds and move on.

Analytics you can trust

I wanted answers, not charts for the sake of charts. The analytics tab helps me see where money goes by category, payment method, and saved instrument, then zoom out with a spending trend view. I also added multiple time windows so I can compare “this week” vs. “the last 3 months” without leaving the screen.

History and edits

I mess up entries all the time. The history view lets me browse past entries, open any expense, and fix it in place—no weird edit mode, no hunting.

Settings that stay out of your way

Settings are intentionally boring. You can set a default payment method, add custom categories (the app ships with 8 defaults you can edit), manage saved payment instruments for deeper analytics, and enable GitHub sync to keep everything in sync across devices. Auto‑sync can run on change or on app launch.

How GitHub sync works (optional)

I designed GitHub sync to be safe, predictable, and fully optional. Your data stays local unless you explicitly turn this on.

Daily CSV files: expenses are stored as expenses-YYYY-MM-DD.csv in your repo
Merge‑first workflow: fetch → merge → push, to avoid accidental data loss
Conflict handling: timestamp‑based resolution, with true conflict prompts only when needed
Differential uploads: only changed files are uploaded, and changes are batched into a single commit
Settings sync (optional): categories and saved instruments can be synced via settings.json

Built for speed

I’m allergic to janky lists, so performance was a first‑class goal. Virtualized lists, memoized components, and a lightweight state layer keep things snappy even with long histories. The UI stays minimal so logging an expense takes seconds, not minutes.

Privacy notes

No required external accounts to use the app
GitHub sync is opt‑in and stores files in your own repository (daily CSVs)
No selling of data

If you want to dig deeper, here are the relevant links:

Get involved

Expense Buddy is available on Google Play Store. Give it a try and let me know what you think!

Originally posted on my blog:https://sudh.online/blog/expense-buddy
Expense buddy is open-sourced
Feel free to reach me out on my socials/email

The beginner's guide to Open Source contribution

Sudhanshu — Sun, 14 Mar 2021 09:10:28 +0000

While in college, I had heard about this amazing month long celebration for open-source called hacktoberfest where if you make a certain number of contributions to any open-source repository(ies) and your changes are accepted (via pull-requests), you could get swags like T-shirts, stickers and other things. This was interesting for me as:

it gave a T-shirt, and I don't know about you but in college days, that was something I could flex in front of others.

Years later, being a developer by profession, I wanted to contribute to Open-source but didn't know how. This is a story of how I have started contributing to open-source projects.

If you, irrespective of being a student, a professional or just someone who wants to contribute to open-source, find it difficult and do not know where/how to start, continue reading.

Background knowledge

I suppose you are familiar with some of the terms that are being used in this post, i.e.:

repository
open-source
issues
pull-request

and know how to use git and github.
If not, I have linked some resources at the end which may be helpful.

How to contribute

If you are a new contributor, there are a few things you should look for:

Repository accepting contributions usually have CONTRIBUTING.md or something similar which provides the guide and template of how you can add your contributions
Issues which are comparatively easy have the label of good first issue on them
You can choose from the list of issues and if you have the solution for them, make a pull request for one issue at a time

The Barrier:

The problem generally faced when it comes to making a contribution are:

how to find a repository to contribute to
not feeling confident enough to contribute

People often can't find a repository which are accepting contributions or there are too many people wanting to contribute to a repository that they, as a beginner, feel lost and not confident enough to contribute. Popular libraries like react, material-ui have a lot of contributors.

Another aspect is that many good open source repos are matured and their codebase is too big...that it is kind of overwhelming for beginners when they don't have a proper plan to navigate through the codebase and know what must exactly be done to accomplish the task they have in mind.

The way:

I have been part of Open Source Raid Guild and you can look at the tutorial-quest to know what they do and how they do it, but here's the TL;DR:

OSRG is the effort to gamify the open-source world and help lower the barrier for the would-be contributors
You aren't alone: following the concept of "raiding", a guild of people will always be with you

This solves the above two barriers. You don't have to personally look for a repository and you can always seek help from the guild whenever you get stuck.

My experience:

Here's what I have gained while being a part of OSRG:

Code-reviews: You have a bunch of people from different time-zones with varying expertise available to review your code, which surely you can't find anywhere else. Code-reviews help you grow along with the community.
Part of a community: Being a part of community provides you with a sense of belongingness
Exposure to tools: Working together in an open group exposes you to many tools that can be difficult to explore on your own or in a closed group

Conclusion:

You will not be getting a T-shirt by contributing to open-source (at least if it's not October), but giving back to the community which we, as developers, regularly exploit feels good. Communities like OSRG help lower the entry barrier and can help in your personal/professional growth.

Resources:

Disclaimer:

OSRG is a JavaScript/TypeScript focused community, but you can extend the idea that they represent and build your own.

Credits:

Cover photo: Photo by Yancy Min on Unsplash
Proof reading and providing valuable suggestions: @poi_sray

Getting more from your portfolio

Sudhanshu — Mon, 01 Mar 2021 11:56:21 +0000

You can skip my ramblings and jump straight to the problem.

Premise:

You're a developer and you want to show your skills to the world.
You painstakingly improved your design skills to design yourself a website (or asked a friend to do it for you, or, as in my case, decided to go with someone's open-sourced design, with permission of course.)

Now the world can see what you do, your past works, your skill sets and what not. Thanks to your friend, your website has smooth animations and it is really a nice-looking, good UX-oriented page that you are really happy about.

Now, the person visiting your home-on-the-internet is pretty impressed with your portfolio and wants to contact you regarding a work opportunity, or just wants to get in touch. You have your social-links embedded in the portfolio website: twitter, linkedin and all those other sites. But having to go to yet another site just to contact you is discouraging for your visitor.

However, you have thought of this already and have provided a contact-form in your website from where the visitor can contact you directly, without going anywhere else. Smart!

That's where the trouble begins:

The problem: Managing the infrastructure to accept form-data

Here are the bare-minimum things you have to manage:

An instance (probably on a cloud provider)
API to connect to the website
A database to store the records
Certificates to secure the exposed endpoints

Now, if you want to get a little fancy, don't forget the overhead of managing the following:

Bot protection
Spam protection
Exporting data in other formats, such as CSV
Webhooks
Email notifications

And don't even get me started on the database migration needed if you decide to add/remove/modify the form fields.

So, now you may ask, "Okay Sudhanshu, tell me, what's the alternative?"

Glad you asked.

The solution:

Give all this management overhead to someone else.
Enter rake.red:

Forms for Static Pages
Collect info from users without a server or back-end code. Receive submissions in rake.red, direct and secure.

Let me tell you their features first:

No backend architecture required
You add/edit/remove as many fields in the contact form as and when required
Spam protection
Export the records as CSV
Webhooks to integrate it with custom-services
If you prefer email notification, you can also turn them on

You may ask me, "What's so special about rake.red? There must be other similar services out there."
There are. Even I used to use another service (pageclip) for this.
What's so awesome about rake.red is:

Direct integration to Discord and Slack using webhooks to get all your stuff on the platform of your choice
Fight the bots with inbuilt honeypot field

I don't know about you, but these two features are what I was searching for in the other similar service. I even had to spin a server-instance just to connect to discord (Yeah, I get the irony. I chose this so that I would not have to manage a server but ended up managing a server).

Conclusion:

If you want a hassle-free, plug and play way to collect info from the visitors and get all the amazing features mentioned above, go check out rake.red. All the documentation required can be found there and the app is pretty intuitive.

P.S. This post was not in any way sponsored by rake.red. These are all my personal opinions.

Credits:

cover image by Joanna Kosinska

CI/CD pipeline with Docker, Github actions, Dockerhub and Watchtower

Sudhanshu — Thu, 13 Aug 2020 05:21:49 +0000

A CI/CD pipeline for the development phase.

I wanted to setup a CI/CD pipeline where my application would finally be deployed on my local machine while also using the sweet stuff that github provided with github-actions, local-machine being the key here.

There can be many situations where you want the deployment to be local, particularly during the development phase, to:

prevent network traffic
non-transmission of sensitive data
accommodate frequent changes in the code-base

Note: This article requires you to have the atleast some prior knowledge of docker and github-actions, and docker installed on your local machine.

1. Dockerizing your application

"Docker is an open platform for developing, shipping, and running applications"
Docker is like a VM but with only the parts necessary to run your applications. Docker provides a comprehensive guide on developing with docker in their documentation, which can be found here.

To "dockerize" an app, you write a Dockerfile. Here's an example of a dockerfile.

2. Setting up github actions for testing and CI

Once you have the dockerfile, you can build a docker image. A Docker image is a file, comprised of multiple layers, that is used to execute code in a Docker container. A docker image is basically a packaged application that can be executed as docker containers. A docker container is just a running docker image.

Github actions provides an environment for executing "actions", which can perform various tasks. These actions are written as yaml files, which then execute based on github triggers like pushing to a branch, initiating a pull-request etc. Check out the features of github actions here.

Dockerhub is an online registry where you can keep your docker images. You do require a dockerhub account to docker images up the registry. If you prefer, you can also make you own registry instead. More on this here.

Below is an example actions.yml file to build an image and push the image to the Dockerhub.

The example above uses a custom script ci:docker to build the docker-image, login into the dockerhub and push the image to the dockerhub using cli. The example is for a node app, but a similar approach can be used for any application.

3. Watchtower

The center part of this entire pipeline is watchtower.

"With watchtower you can update the running version of your containerized app simply by pushing a new image to the Docker Hub or your own image registry."
Check out their repo for more information.

containrrr / watchtower

A process for automating Docker container base image updates.

Basically, with watchtower, whenever the image updates in the registry (like Dockerhub), the container is updated with the latest changes.

Doing these, you have successfully made your CI/CD pipeline which gets updated whenever changes are pushed to the github repo.
The local container takes some time to update once the updated image is pushed to the registry, but setting these whole workflow is simple and works beautifully, at least for the development environment.

Role based access control in React-Redux apps

Sudhanshu — Thu, 18 Jun 2020 02:07:06 +0000

This assumes you have a basic knowledge of react, react-router, redux and redux-middlewares. Also, you have already implemented authentication in the react-redux app.

Note: I have used redux but the same can be done without relying on redux. So, while some knowledge of redux may help you understand what I have tried to convey, redux isn't a necessity.

While working in a project, the requirement arose to give the functionality of Role based access control (RBAC) in a client-side-rendered react-app.

Basically, the application was going to have multiple tiers of users with flexible permissions and depending on the permission granted to any particular user, a component or a part of the application may/may not become accessible to that user.

Implementing RBAC at the client-side can be divided into:

Conditional rendering of the components
Updating the conditions when permissions change

Conditional Rendering of the components:

There are many approaches that can be used for this. One of my initial approach was to wrap the component (say CheckedComponent) with a component (say CheckPermissions) which would conditionally render them based on the permissions given to the current user. This looks something like this:

The user-permissions were stored in the redux-store route-wise.

The above approach does the job but fails if the <CheckedComponent /> also requires permission checking, basically making the whole process nested. Also, I didn’t know before-hand the depth of nesting.

I could also have used HoCs, but they too suffered from the same issue, in my case.

So, I decided to go with the hooks approach, which looks something like this:

the useAuthorization hook returns the list of permissions the user has for the given route. This may seem repetitive as this could directly have been taken from the redux-store, but this hook provided a level of abstraction. Also, if the permission-retrieval logic for the user is changed, only this needed to be changed and everything would still work.
each component is conditionally rendered based on the user permissions.

In this approach, I need to do the same thing again and again, but looks neat for now.

Updating the conditions when permissions change:

In my case, whenever a user logged in, the server responded with a set of permissions associated with that user. I wrote a middleware which on login-success read the permissions and updated the redux-store. I am also using redux-persist to save authorization and authentication information about the user in the local storage.

Now, when the permissions are changed for any user, the user’s authorization-token is expired. This is very important or the user-permissions won’t be updated in the redux-store and no change will be visible. The changes with the new permissions are reflected when the user logins again.

This approach of RBAC may not be what’s ideal, but this works for me. A few important steps I have skipped over, as they are subjective to an application, viz.,

Agreeing on the structure of the permissions. In my case, I arranged the permissions route-wise , but you can use any other structure.
The redux-middleware part. This basically takes the server-response and transforms that into the structure mentioned in the first point.

This post is also availabe as a medium post and can be found here :

Forem: Sudhanshu

Expense Buddy: Local-first expense tracking with GitHub sync

Why Expense Buddy exists

Feature highlights

Dashboard

Add expense

Analytics you can trust

History and edits

Settings that stay out of your way

How GitHub sync works (optional)

Built for speed

Privacy notes

Get involved

The beginner's guide to Open Source contribution

Background knowledge

How to contribute

The Barrier:

The way:

My experience:

Conclusion:

Resources:

Disclaimer:

Credits:

Getting more from your portfolio

Premise:

That's where the trouble begins:

The problem: Managing the infrastructure to accept form-data

The solution:

Conclusion:

CI/CD pipeline with Docker, Github actions, Dockerhub and Watchtower

Note: This article requires you to have the atleast some prior knowledge of docker and github-actions, and docker installed on your local machine.

1. Dockerizing your application

2. Setting up github actions for testing and CI

3. Watchtower

containrrr / watchtower

A process for automating Docker container base image updates.

Role based access control in React-Redux apps

Conditional Rendering of the components:

Updating the conditions when permissions change:

Role based access control in React-Redux apps | by Sudhanshu Ranjan | Medium

Sudhanshu Ranjan ・ Jun 18, 2020 ・ Medium

Sudhanshu Ranjan ・ Jun 18, 2020 ・
Medium