I'm a student developer in India interested in backend engineering, Linux infrastructure, automation, and practical software products. I've worked on SaaS backends, lead-management tools, server-hosting experiments, and container-based provisioning workflows.
I enjoy debugging real deployment problems and understanding how applications, databases, networks, and infrastructure fit together.
How I work
1I describe a project by what I built and tested, and say plainly what I did not.
2When a deployment breaks, I want to know which layer failed: application, database, network or host.
3I try to turn experiments into documented, testable projects.
Focus areas
Backend and databasesBackend and database-backed applications
Linux and self-hostingLinux systems and self-hosting
Containers and deploymentContainers and deployment workflows
Automation and DiscordAutomation and Discord integrations
Early-stage productsEarly-stage product development, marketing and outreach
03·Projects
Selected work
Four projects, each labelled with what it actually is. Open one to see what I built, what it taught me, and what I am not claiming.
←→Switch between projects while one is open
01Parts built · platform not claimedParts built
Hosting and Infrastructure
A small hosting project: Linux nodes, containers and the networking between them.
Incus/LXC (Exploring)
Docker (Exploring)
Tailscale (Exploring)
Reverse proxies (Exploring)
Discord bots (Exploring)
Open
What it is
An early-stage hosting and infrastructure project involving Linux nodes, Discord workflows, container provisioning, and service operations. Experiments have included Incus/LXC, Docker, Tailscale, reverse proxies, and Minecraft hosting components.
Not claimed
A finished or production hosting platform.
Discord-driven provisioning or the dashboard. Both are planned.
Uptime, scale or usage figures of any kind.
Next
Write down what works and what is only planned, test the working parts, then decide what to build next.
Built
Experiments
Planned
Schematic. Boxes show how the parts relate, not a real screen or real figures.
What I built
Container provisioning experiments with Incus/LXC and Docker on Linux nodes.
Networking between services: Tailscale connectivity and reverse proxies.
Discord bot workflows around the service. Discord-driven provisioning is still planned.
Minecraft hosting components.
Planned, not built
Discord-driven provisioning of containers.
A dashboard for containers, node health and expiry dates.
What it taught me
Running a hosting project is more than starting containers: the networking in between and the day-to-day operation of the service need as much attention.
Saying which parts work and which are only planned keeps the project honest.
Stack
Incus/LXC (Exploring)
Docker (Exploring)
Tailscale (Exploring)
Reverse proxies (Exploring)
Discord bots (Exploring)
Topics
Linux nodes
Container provisioning
Service operations
02Built · tested in partBuilt, partly tested
Gym-focused SaaS
A SaaS for gyms, and a lesson in the gap between building software and getting it used.
Open
What it is
A SaaS project for gyms involving backend development, security measures, marketing, and cold calling. The project provided practical experience with the difference between building software and getting users to adopt it.
Not claimed
Any number of users or gyms.
That the product is finished, polished or in wide use.
A particular tech stack.
Next
Write up the product and its security decisions properly before saying more about it.
Built
Experiments
Planned
Schematic. Boxes show how the parts relate, not a real screen or real figures.
What I built
The backend of the product.
Security measures around it.
Outside the code: marketing and cold calling to reach gyms.
What it taught me
Building software and getting users to adopt it are two different jobs, and the second does not follow from the first.
Marketing and cold calling are part of the work, not something that happens after the code is done.
Topics
Backend
Security
Marketing
Cold calling
03Terminal version builtTerminal version built
Lead management tool
A lead tracker that started in the terminal, in Go, on SQLite.
Go
SQLite
CSV
Supabase (Exploring)
Open
What it is
A lead-management tool that began as a Go terminal UI backed by SQLite, with CSV export. The project later moved toward a web-based version using Supabase.
Not claimed
A finished web version.
That the tool is in use anywhere.
Any figures about leads or outcomes.
Next
Document the schema and the export so someone else can test the project, then decide whether the web version is worth finishing.
Built
Experiments
Planned
Schematic. Boxes show how the parts relate, not a real screen or real figures.
What I built
A terminal interface in Go for managing leads.
SQLite storage for the lead records.
CSV export of the data.
Moved toward a web-based version using Supabase (not claimed as finished).
What it taught me
A local SQLite file with a CSV export is a simple first shape for a lead tracker.
Moving toward a web version means thinking about hosting the data, not only storing it.
Stack
Go
SQLite
CSV
Supabase (Exploring)
Topics
Terminal UI
Lead management
Data export
04Proposed · specification onlyProposed
Proposed automation
A proposed workflow on paper: refresh records, draft e-mails, show a dashboard. A person reviews everything first.
Open
What it is
A proposed automation workflow for periodically refreshing candidate records, preparing personalized email drafts, and presenting candidate information and statistics in a dashboard.
Not claimed
That it is built, running or tested.
That any candidate data has been collected.
That any message has been sent.
Next
Settle what is specified and what is built, then split the specification into small pieces that can be built and tested one at a time.
Proposed
Schematic. Boxes show how the parts relate, not a real screen or real figures.
What is specified
Periodic refresh of candidate records.
Personalized e-mail drafts, prepared for a person to review.
A dashboard showing candidate information and statistics.
Human review before any outreach.
Respect for source permissions and privacy.
What it taught me
Respect source permissions and privacy.
Keep candidate records fresh by refreshing them periodically.
A person reviews every draft before any outreach.
Topics
Automation
Dashboard
E-mail drafts
Privacy
04·Stack
Technical focus
Tools I have used or explored in projects. A tool being listed says nothing about depth, so there are no bars or scores.
Markers
Used
Used in projects or day to day.
Exploring
Tried in experiments.
Learning
Still studying it.
Projects
Hover or focus a tool to see which projects it appears in. Click, tap or press Enter to pin the highlight; Esc clears it.Tap a tool to see which projects it appears in; tap it again to clear.
No tools are listed for this project.
Programming
Languages, with an honest level where I know it.
Systems
Operating systems and containers.
Databases and data
Small, practical data work.
Networking and web serving
Getting requests to the right place.
Other
Workflows and practice rather than products.
05Away from the editor
Beyond coding
What I do when I am not at the keyboard, and some of what I do at it.
Linux desktop customization
Configuring my own desktop until it works the way I do.
Self-hosting
Running services on my own machines to see how they behave.
Server operations
Keeping services up, and working out why they are not.
Arduino
Tinkering with microcontrollers.
Keyboard modding
Opening keyboards up to change how they feel and sound.
Karate
Away from the screen entirely.
Fitness
Exercise to balance the hours at a desk.
Cycling
Riding a bicycle: no screen, no terminal.
Ahead
Current direction
Alongside the projects: academic goals, and a look at future study paths in computing and software engineering.
Strengthening backend and systems skills by turning experiments into well-documented, testable projects while pursuing academic goals and exploring future study paths in computing and software engineering.
06Contact
Say hello.
The general e-mail is the best way in. Use the second one only for sensitive matters.
