Jatin's Website | RSS Feed

The Wild Oasis - Making It Responsive

shimpijatin@gmail.com — Thu, 26 Feb 2026 00:00:00 GMT

why responsiveness matters

after building the custom backend and refactoring both frontends, the wild oasis worked great — on desktop. but try opening it on your phone and things got... ugly. elements overlapping, sidebar taking up the entire screen, tables completely unusable. you know the drill.

so I sat down and made both the admin dashboard and the customer website fully responsive. the interesting part? they use completely different CSS approaches — styled-components on the admin side and tailwind on the customer side. same goal, two different playbooks.

the customer website (tailwind CSS)

the customer-facing site is built with next.js and tailwind, so responsiveness here is all about mobile-first utility classes — sm:, md: prefixes that progressively enhance the layout as the screen gets bigger.

home page hero

the hero section needed to scale its typography and CTA button properly. the heading goes from text-4xl on mobile to text-8xl on desktop, and the button padding scales with sm: breakpoints.

cabin cards

the cabin cards were originally side-by-side (flex-row). on mobile they now stack vertically (flex-col sm:flex-row) with the image using aspect-video to maintain a clean ratio. the detail page also collapses to a single column.

about page

the about page used a 5-column grid for its content layout. on mobile this collapses to a single column (grid-cols-1 md:grid-cols-5), with all col-span-* classes prefixed with md:. headings scale down to text-3xl and gaps are reduced.

this was one of my favourite changes. the account sidebar with text links transforms into a horizontal icon-only tab bar on mobile. the text labels get hidden md:inline, and the nav switches to justify-around with the border moving from the right side to the bottom.

the sign out button follows the same pattern — icon only on mobile.

reservation layout

the calendar + reservation form grid changes from grid-cols-2 to grid-cols-1 md:grid-cols-2 — calendar stacks on top, form below. reservation cards also stack vertically and hide some date details on mobile.

live site: the-wild-oasis-client-jatin.netlify.app

the admin dashboard (styled-components)

the admin dashboard is a react + vite app using styled-components — so responsiveness here means writing @media queries inside template literals. different vibe, same results.

the biggest structural change. on desktop, the sidebar is always visible in a two-column grid. on mobile, it becomes a fixed-position overlay that slides in from the left when you tap the ☰ button.

I created a new SidebarContext to manage the toggle state, and added a backdrop overlay when the sidebar is open.

Desktop: [Sidebar | Main Content]  — sidebar always visible in grid
Mobile:  [Main Content] + overlay sidebar triggered by ☰ button

dashboard grid

the dashboard stats grid goes from 4 columns → 2 columns at 1024px → 1 column at 768px. the tricky part was the chart components — they had hard-coded grid spans like grid-column: 3 / span 2 which reference columns that don't exist in a 1-column layout. all charts reset to 1 / -1 (full width) on mobile.

modal forms switch from a 3-column grid layout to a single column on mobile, and the modal itself goes to 95vw width. the header hides the username text and only shows the avatar circle, with the hamburger using margin-right: auto to keep the icons right-aligned.

tables

rather than hiding columns or redesigning tables for mobile, I went with a practical approach: a min-width: 60rem on the table ensures it maintains its readable layout and scrolls horizontally inside an overflow-x: auto container.

live site: adorable-gecko-dced13.netlify.app

patterns that worked

Pattern	Where Used
Hamburger sidebar	Admin — collapsible overlay
Icon-only nav	Customer — account tab bar
Grid collapse	Both — `grid-cols-1` on mobile
Flex-wrap	Admin — Row, TableOperations, Filter
Min-width + scroll	Admin — Table component
Hidden text	Both — UserAvatar, SideNavigation
Font scaling	Both — headings and buttons reduced

bug fixes along the way

responsiveness work has this funny side effect — you end up finding bugs you never noticed on desktop.

isLoading1 undefined in DashboardLayout — missing destructuring alias
&mdash missing semicolon in BookingRow — rendered as literal text instead of an em dash
CORS blocking preflight — cors() middleware was after helmet(), had to move it first
rate limit too aggressive — 100 requests/hour was choking development, bumped to 1000 in dev mode

conclusion

making two apps responsive with two different CSS approaches was a great exercise. styled-components gives you full control but you write more code. tailwind is faster but you need to think mobile-first from the start.

the key takeaway: don't fight the grid. if your desktop layout uses a 4-column grid, plan early for how it collapses. retroactively fixing grid spans that reference non-existent columns is not fun.

Source: GitHub Repository
Customer Site: the-wild-oasis-client-jatin.netlify.app
Admin Panel: adorable-gecko-dced13.netlify.app

QLock UI Overhaul - Embracing the Pixel Art Aesthetic

shimpijatin@gmail.com — Tue, 17 Feb 2026 00:00:00 GMT

The Need for a Facelift

QLock started as a functional tool—a utility for timed MCQ practice. It did its job well, but visually, it felt a bit... utilitarian. As I continued to use it and build upon it, I realized the interface needed some personality.

old design >

new design >

Shifting the Color Scheme

The original color scheme was functional but standard and looked very ai-generated because of thr heavy use of claude 4.5. I wanted something that felt more cohesive, modern and human made, yet retained a bit of retro charm to go with the new direction I was heading. I completely overhauled the palette, moving towards high-contrast, easier-on-the-eyes tones that make long study sessions less straining.

specifically the following palette >

Goodbye Emojis, Hello Pixel Art

One of the biggest changes in this update is the removal of standard emojis. While emojis are easy to use, they often look different across devices and can feel a bit "generic."

I wanted a consistent, retro-tech vibe. That's where pixel art comes in.

To implement this, I integrated @nsmr/pixelart-react.

"dependencies": {
  "@nsmr/pixelart-react": "^2.0.0"
}

This library allowed me to replace the standard emojis with pixelated icons that perfectly match the new aesthetic.

Why Pixel Art?

Consistency: The icons look exactly the same on every device and browser.
Aesthetic: It gives the app a distinct "indie game" feel, which can make the potentially stressful task of timed practice feel a bit more engaging.

What's Next?

Adding settings modal to change the background and accent colour to few options to select from

and most importantly

With the visual foundation now solid, I'm looking to add more security measures accross all platforms.

The Scrap Mini Amp

shimpijatin@gmail.com — Mon, 16 Feb 2026 00:00:00 GMT

Introduction

On my 20th birthday my father gave me enough money to buy an old rusty electric guitar, But after asking for an amp for it i didnt get any, so i saved some money collected some scraps and hacked together a bedroom level guitar amp.

On my summer break in 2024 i was home, and I went to my uncles for something and asked him if he had a speaker lying around he said i dont have a speaker BUT an old home theatre. I was like thats even better.

I brought it to me dorm in pune and started making this, at firat i just hooked the guitar directly to the home theatre, it was very quiet but the sound was great

So i researched abput it and found out there is a signal mismatch, the amp expects a line level signal but the guitar outputs a instrument level signal

But the sound was very warm and i loved it, i found out later after i opened the amp after it got fried and found out on the main board there was a tube simulator circuit used as the preamp for all the signals coming in the. so all i needed was a overdrive circxuit to go with it and i was pretty much done but as i was going to order the parts the piece got fried.

The overdrive circuit

I found this brilliant article by Wampler Pedals that walks through designing a basic overdrive pedal circuit. I used their schematic as the starting point and made some modifications to fit the components I had lying around.

here's the original schematic I based mine on >

and here's what my actual board looks like — hand-soldered on a perfboard >

the back is a proper rat's nest of solder joints and wire bridges, but it works >

The power amp

The original plan was to use an old home theatre system for both the speakers and the power amplification. It worked for a while, but eventually the circuit got fried. So I replaced the internals with a TPA3118 PBTL Class D power amp module I had bought online.

For power, I used an old laptop charger. It outputs around 19V which is more than enough for a tiny bedroom amp.

How it sounds

It's messy, it's not that loud, but it actually sounds pretty cool for something made of trash.

Clean tone

Overdrive

What I learned

reading schematics and actually building them on a perfboard are very different skills
soldering is surprisingly meditative once you get the hang of it
constraint breeds creativity — not having money for a real amp forced me to actually understand how amps work

Conclusion

Total cost? about ₹500. I learned a lot about electronics and guitar amps while building this. It was a fun project and i would recommend it to anyone who is interested in electronics and music.

"Constraint breeds creativity"

Circuit Reference: Wampler Pedals — How to Design a Basic Overdrive Pedal Circuit

Idea: Teensy 4.1 Guitar Interface

shimpijatin@gmail.com — Mon, 16 Feb 2026 00:00:00 GMT

The Idea

I want to build a digital guitar effects processor using a Teensy 4.1 microcontroller. The idea is to write code that manipulates the audio signal in real-time — applying delay, reverb, distortion, etc. — directly on the chip.

I can also record the audio, I would have to use a powerful audio codec with it so that i can stream the data live

Why Teensy?

Teensy 4.1 is a beast for audio processing. It has a fast clock speed and great libraries for audio. Plus, coding my own effects sounds like a fun way to combine music and programming.

(More details coming when I actually start building this...)

QLock - MCQ Timer App

shimpijatin@gmail.com — Thu, 01 Jan 2026 00:00:00 GMT

How it started

one day I was talking with my roommate and i asked him hows his study going he said hes using an spp for timed questions so he can record how much time is taken for each question, he's a GATE aspirant. he was also saying that most of the apps lack basic features or the UX is painful to use when you're trying to simulate real exam conditions.

I was like — wait, I can build this.

so we sat down, brainstormed features, discussed what he actually needed vs what existing apps were giving him. and that's how QLock was born. he was basically my user 0, my first real client. we're still adding features to it honestly, the list keeps growing.

What it does

QLock is built for students appearing for JEE, NEET, GATE and other competitive exams where time management is everything. it supports MCQ, MSQ, and NAT question types — because different exams use different formats and most apps just ignore that.

you can set timers per question or for the entire session, practice under real exam pressure, and track how you're doing over time. the whole point is to make practice feel like the real thing.

The tech stack

Technology	Purpose
React	Web Frontend
React Native	Mobile App (Android)
Rust / Axum	Backend API
Expo	Mobile Tooling

The jetpack compose disaster

The first mistake i did was making the webapp first and then going on to make the mobile app

so when I decided to build the mobile app, I wanted a pixel-to-pixel clone of the web version. so naturally I asked claude — "hey I want to make an exact clone of my web app for android, what should I use?"

claude said jetpack compose.

so I blindly followed it. started building in kotlin, jetpack compose, the whole android native setup. and oh man, it was a nightmare. trying to replicate a React web UI in jetpack compose is like trying to write a novel in a language you barely speak. the paradigms are completely different, the styling system is nothing like CSS, and I was spending more time fighting the framework than actually building features.

after a few painful days I stepped back and thought — wait, why am I doing this to myself? I already know React. the web app is in React. why not just use React Native?

switched to React Native with Expo and things immediately clicked. the component structure was familiar, I could reuse a lot of the logic, and the styling was close enough to CSS that I wasn't losing my mind anymore. lesson learned — don't blindly follow AI suggestions without thinking about your own context first.

Why Rust for the backend

I could've just used express and called it a day. but I wanted to learn Rust, and building a real project is the best way to do that. Axum turned out to be a great choice — it's fast, the type system catches bugs at compile time, and honestly once you get past the borrow checker it's pretty satisfying to write.

Where we're at now

the web version is live and working. the android app is built and functional — we're holding off on publishing to the Play Store until we finish a security audit. I don't want to ship something to real users without making sure auth, data handling, and all that stuff is solid.

we still have a bunch of features on the roadmap that my roommate and I keep brainstorming. it's one of those projects that just keeps evolving because we're actually using it.

What I learned

build for a real user. having my roommate as user 0 made every feature decision easier. no guessing, just "does this actually help him practice better?"
don't blindly follow AI. claude is great but it doesn't know your context. jetpack compose was the "correct" answer technically, but react native was the right answer for me.
Rust is worth the pain. the learning curve is steep but once it clicks, you write more confident code.
cross-platform is hard but doable. porting from React to React Native isn't a copy-paste job, but the mental model transfers really well.

Source: GitHub Repository

Mini Redis - Rust

shimpijatin@gmail.com — Thu, 01 Jan 2026 00:00:00 GMT

Introduction

RivetDB is a mini Redis implementation written in Rust, built as a hands-on learning project to dive deep into systems programming concepts like memory management, concurrency, and network protocols.

Motivation

Understand how in-memory databases work under the hood
Learn Rust's ownership model and concurrency primitives in a real-world context
Explore the RESP (Redis Serialization Protocol) and TCP networking

Tech Stack

Technology	Purpose
Rust	Core Implementation
Tokio	Async Runtime
TCP	Network Protocol

Key Features

Core Data Structures

Implemented fundamental Redis data structures including strings, sorted sets, and key-value storage with expiration support.

Async Networking

Built on Tokio for high-performance asynchronous I/O, handling multiple concurrent client connections efficiently.

Command Parsing

A RESP-compatible command parser that handles standard Redis commands like GET, SET, DEL, and more.

Challenges & Learnings

Wrestling with Rust's borrow checker while implementing concurrent data structures was challenging but incredibly educational. It forces you to think about data ownership in ways other languages don't.

Conclusion

Building a Redis clone from scratch is one of the best ways to learn systems programming. This project provided deep insights into how databases manage memory, handle concurrency, and communicate over the network.

Source: GitHub Repository

The Wild Oasis - Custom Backend

shimpijatin@gmail.com — Wed, 01 Jan 2025 00:00:00 GMT

The supabase problem

so here's what happened — I had the wild oasis project running on supabase's free tier for a while. it was working fine, until one day my project just... expired. the free tier just kills your project if it's inactive for too long. classic.

at first I was annoyed, but then I thought wait — this is actually a great excuse to build something real. instead of just re-deploying on supabase or switching to another BaaS, why not build the entire backend myself? learn how stuff actually works under the hood.

and that's exactly what I did.

The inspiration — youtube-twitter backend

I had already gone through hitesh choudhary's youtube-twitter backend project, and I really liked the patterns he used there. proper industry standard stuff — structured error handling, consistent API responses, clean separation of concerns. so I took that as my base and adapted it for the wild oasis.

the core idea was simple: if I'm going to build a backend, I'm going to do it the right way. scalable, secure, and maintainable.

Project structure

here's how the project is organized:

the-wild-oasis-backend/
├── src/
│   ├── app.js              # express app setup + middleware
│   ├── index.js             # server entry point
│   ├── constants.js
│   ├── swagger.js           # API docs config
│   ├── controllers/
│   │   ├── bookings.controller.js
│   │   ├── cabins.controller.js
│   │   ├── guests.controller.js
│   │   ├── settings.controller.js
│   │   └── user.controller.js
│   ├── models/
│   │   ├── bookings.model.js
│   │   ├── cabins.model.js
│   │   ├── guest.model.js
│   │   ├── settings.model.js
│   │   └── user.model.js
│   ├── routes/
│   │   ├── bookings.routes.js
│   │   ├── cabins.routes.js
│   │   ├── guests.routes.js
│   │   ├── settings.routes.js
│   │   └── user.routes.js
│   ├── middlewares/
│   │   ├── auth.middleware.js
│   │   └── multer.middleware.js
│   ├── utils/
│   │   ├── ApiError.js
│   │   ├── ApiResponse.js
│   │   ├── asyncHandler.js
│   │   └── cloudinary.js
│   ├── db/
│   │   └── index.js
│   └── scripts/
│       └── seed.js
├── public/
└── package.json

clean MVC-ish pattern. controllers handle the logic, models define the data, routes wire everything up. nothing fancy, just solid structure that scales.

The utils — where the magic lives

this is straight from the hitesh choudhary playbook and honestly it's one of the best patterns I've picked up.

ApiError

custom error class that gives you consistent error responses across the entire app:

class ApiError extends Error {
  constructor(
    statusCode,
    message = "something went wrong",
    error = [],
    stack = "",
  ) {
    super(message);
    this.statusCode = statusCode;
    this.data = null;
    this.message = message;
    this.success = false;
    this.error = error;

    if (stack) {
      this.stcak = stack;
    } else {
      Error.captureStackTrace(this, this.constructor);
    }
  }
}

now whenever something goes wrong in any controller, I just throw new ApiError(404, "cabin not found") and the global error handler catches it. no more scattered res.status().json() calls everywhere.

ApiResponse

same idea but for success responses:

class ApiResponse {
  constructor(statusCode, data, message = "success") {
    this.statusCode = statusCode;
    this.data = data;
    this.message = message;
    this.success = statusCode < 400;
  }
}

every successful response looks the same — statusCode, data, message, and a success boolean. the frontend always knows what to expect.

asyncHandler

this tiny wrapper saved me from writing try-catch in every single controller:

const asyncHandler = (requestHandler) => {
  return (req, res, next) => {
    Promise.resolve(requestHandler(req, res, next)).catch((err) => next(err));
  };
};

wraps any async function and forwards errors to express's error handler automatically. simple but super effective.

security and middleware

I went all in on security for this one. the app.js is loaded with production-grade middleware:

// Security HTTP Headers
app.use(helmet());

// Rate limiting
const limiter = rateLimit({
  max: 100,
  windowMs: 60 * 60 * 1000,
  message: "Too many requests from this IP, please try again in an hour!",
});
app.use("/api", limiter);

// Data sanitization against NoSQL query injection
app.use(mongoSanitize());

helmet — sets a bunch of security HTTP headers
rate limiting — 100 requests per hour per IP, no one's DDoS-ing my hotel API
mongo sanitize — prevents NoSQL injection attacks
CORS — configured for both the admin dashboard (vite on 5173) and the customer website (next.js on 3000)
swagger — full API documentation at /api-docs

refactoring the frontends

this was honestly the hardest part. the original wild oasis project by jonas uses supabase directly from the frontend — no API layer at all. so when I built this custom backend, I had to refactor both the admin dashboard and the customer-facing website to talk to my API instead.

every supabase call had to be ripped out and replaced with fetch/axios calls to my express API. the data shapes were different too since I'm using mongoose models now instead of supabase's postgres tables. lots of mapping and adapting.

but it was worth it. now the frontends are properly decoupled from the database, which is how it should be in production anyway.

tech stack

technology	purpose
express.js	API framework
mongodb + mongoose	database + ODM
JWT + bcrypt	auth + password hashing
cloudinary	image/media storage
helmet	security headers
swagger	API documentation
multer	file upload handling
zod	request validation

what I learned

building this backend taught me way more than any tutorial could. some takeaways:

BaaS is convenient, but knowing how to build your own backend is invaluable. when supabase expired, I didn't panic — I just built my own.
consistent error handling patterns make everything cleaner. the ApiError/ApiResponse pattern from hitesh's project is something I now use in every backend I build.
security isn't optional. rate limiting, helmet, sanitization — these are table stakes for any production API.
refactoring is where the real learning happens. tearing out supabase and wiring up a custom API forced me to understand every data flow in the app.

conclusion

what started as a "damn, supabase killed my project" moment turned into one of the best learning experiences I've had. the project is now fully self-hosted, scalable, and doesn't depend on any third-party BaaS that could expire on me again.

if you're sitting on a project that uses supabase or firebase and you want to level up — try building the backend yourself. it's painful at first but it's worth every line of code.

Source: GitHub Repository

YouTube - Twitter Backend

shimpijatin@gmail.com — Mon, 01 Jan 2024 00:00:00 GMT

Introduction

This project is a backend implementation inspired by the architectures of YouTube and Twitter, built as a learning exercise in production-grade backend development. Guided by Hitesh Choudhary's teachings, it covers essential patterns for building scalable APIs.

Motivation

Learn production backend patterns and best practices
Understand how large-scale social platforms structure their APIs
Practice building robust authentication, file uploads, and data modeling

Tech Stack

Technology	Purpose
Node.js	Runtime
Express.js	API Framework
MongoDB	Database
Cloudinary	Media Storage

Key Features

User Authentication

Complete authentication flow with JWT tokens, refresh tokens, and secure password hashing.

Video Management

Upload, stream, and manage video content with cloud-based media storage via Cloudinary.

Tweet-like posting, likes, comments, subscriptions, and a personalized feed — modeled after real-world social platforms.

Aggregation Pipelines

Complex MongoDB aggregation pipelines for channel statistics, watch history, and subscriber analytics.

Challenges & Learnings

Understanding how to structure a backend for scale — from data modeling to middleware chains — was the most valuable takeaway from this project.

Conclusion

This project bridges the gap between tutorial-level backends and production-ready systems. It covers authentication, media handling, and complex querying patterns that are essential for any backend engineer.

Source: GitHub Repository

Jatin's Website | RSS Feed

The Wild Oasis - Making It Responsive

why responsiveness matters

the customer website (tailwind CSS)

home page hero

cabin cards

about page

account section — sidebar to tab bar

reservation layout

the admin dashboard (styled-components)

sidebar → hamburger menu

dashboard grid

forms & header

tables

patterns that worked

bug fixes along the way

conclusion

QLock UI Overhaul - Embracing the Pixel Art Aesthetic

The Need for a Facelift

Shifting the Color Scheme

Goodbye Emojis, Hello Pixel Art

Why Pixel Art?

What's Next?

The Scrap Mini Amp

Introduction

The overdrive circuit

The power amp

How it sounds

Clean tone

Overdrive

What I learned

Conclusion

Idea: Teensy 4.1 Guitar Interface

The Idea

Why Teensy?

QLock - MCQ Timer App

How it started

What it does

The tech stack

The jetpack compose disaster

Why Rust for the backend

Where we're at now

What I learned

Mini Redis - Rust

Introduction

Motivation

Tech Stack

Key Features

Core Data Structures

Async Networking

Command Parsing

Challenges & Learnings

Conclusion

The Wild Oasis - Custom Backend

The supabase problem

The inspiration — youtube-twitter backend

Project structure

The utils — where the magic lives

ApiError

ApiResponse

asyncHandler

security and middleware

refactoring the frontends

tech stack

what I learned

conclusion

YouTube - Twitter Backend

Introduction

Motivation

Tech Stack

Key Features

User Authentication

Video Management

Social Features

Aggregation Pipelines

Challenges & Learnings

Conclusion