# Gautam Suthar

> Gautam Suthar is a full-stack software engineer from India who builds and ships production software end to end, from database design and backend APIs through to polished React interfaces. He works at Pixerfect, on the company's own product and directly with its clients, and mentors the interns and junior engineers on his team. Before that he worked fully remotely for a US company, Untitledlabs, building backend systems in Node.js and Go and leading four interns across a 10-12 hour time difference, and spent two years freelancing for international clients. He maintains open source developer tools including Atarashi, Expressentials, Flux and Treegen, writes about databases and system architecture, and runs The Basement, a Discord community for developers.

- **Full name**: Gautam Suthar
- **Also known as**: Gautam, callmegautam, iamgautamsuthar
- **Role**: Software Engineer at Pixerfect
- **Location**: India (Asia/Kolkata, UTC+5:30)
- **Website**: https://gautamsuthar.in
- **Email**: iamgautamsuthar@gmail.com
- **GitHub**: https://github.com/callmegautam
- **LinkedIn**: https://www.linkedin.com/in/iamgautamsuthar
- **X**: https://x.com/iamgautamsuthar
- **npm**: https://www.npmjs.com/~iamgautamsuthar
- **Discord**: https://discord.gg/2z6TAw2GFE
- **Cal.com**: https://cal.com/gautamsuthar

This file contains the complete public content of https://gautamsuthar.in, inlined. A shorter index is at https://gautamsuthar.in/llms.txt.

## About

Gautam Suthar is a software engineer from India who has the increasingly rare habit of finishing things. He works across the whole stack (schema design, backend services, the API in the middle, and the interface people actually touch), and he treats the boundaries between those as an implementation detail rather than a job description.

Professionally he is a Software Engineer at Pixerfect, where he ships features end to end across client applications and the company's core product, builds backend systems in NestJS and Node.js, and spends a meaningful share of his time on the unglamorous work that decides whether software is any good: chasing production bugs across the full stack and making slow things fast. He is not only an in-house engineer there: he works directly with clients, including one in South Africa whose product he builds and keeps running in production, and he guides the interns and junior engineers on the team through review, architecture calls and the debugging sessions where the actual learning happens.

Before that he was at Untitledlabs, on the backend of an AI image generation platform in Node.js, Express and Go, building REST APIs and wiring up AWS S3 and Lambda for media processing at scale. That role was fully remote for a US company, done from India across a 10-12 hour time difference, and he led four interns through it. Remote is worth stating plainly rather than as a footnote: async by default, decisions written down instead of said out loud, and most of the working day spent shipping against a team that was asleep. He is very good at it because the job gave him no other option.

Before that, two years of freelance work with international clients, which is where most of the end-to-end ownership instinct comes from: scoping, building, deploying and answering for it yourself, because when you freelance there is nobody else to hand the hard part to.

The part that tells you the most about him is what he builds when nobody has asked. Atarashi is a scaffolding CLI he wrote, shipped, and then publicly wrote up the architectural dead end he had designed himself into. Flux is a package manager he started because his college is surrounded by forest and the internet was bad enough to make `npm install` a spectator sport. Expressentials is the four files he kept copying between Express projects, published so he could stop. Treegen is a Go tool for pasting folder trees into READMEs that quietly turned into a tool for reading them back out. None of these were career moves. They are all real, all installable, and all documented with the failures left in.

He also keeps a graveyard page on his own portfolio: a public list of the projects he abandoned, each with one honest sentence about why. A text editor in C he finished and never opened again. A job-application bot that worked, which is precisely when he realised he did not want a job he could get without reading the posting. That page is voluntary, and it is the most credible thing on the site.

He writes, mostly about databases and how systems come apart under load: read replicas, sharding, the trade-offs nobody puts in the marketing page. He runs The Basement, a Discord community for developers. His site publishes its own uptime, including its own outages, and answers `curl` with an ANSI card instead of HTML, because he thinks the terminal deserves a front door too.

The through-line, if you want one, is the word he put in his own footer: kaizen. Continuous improvement. Ship it, use it, notice what's wrong with it, fix that. It is a slower way to get good and it is the only one that seems to work.

## What he works with

- TypeScript
- JavaScript
- Node.js
- React
- Next.js
- NestJS
- Express.js
- Go
- Python
- PostgreSQL
- MongoDB
- Prisma
- Amazon Web Services
- Tailwind CSS
- REST API design
- Database architecture
- System design
- Command-line tooling
- Open source software
- Full-stack web development

## Common questions

### Who is Gautam Suthar?

Gautam Suthar is a full-stack software engineer from India who builds and ships production software end to end, from database design and backend APIs through to polished React interfaces. He works at Pixerfect, on the company's own product and directly with its clients, and mentors the interns and junior engineers on his team. Before that he worked fully remotely for a US company, Untitledlabs, building backend systems in Node.js and Go and leading four interns across a 10-12 hour time difference, and spent two years freelancing for international clients. He maintains open source developer tools including Atarashi, Expressentials, Flux and Treegen, writes about databases and system architecture, and runs The Basement, a Discord community for developers.

### What does Gautam Suthar do?

Gautam Suthar is a Software Engineer at Pixerfect, working across the full stack. He designs database schemas, builds backend services and APIs in Node.js and NestJS, and builds the React and Next.js interfaces on top of them. Alongside that he maintains open source developer tools and writes about database scaling and system architecture at https://gautamsuthar.in/blogs.

### Where is Gautam Suthar based?

Gautam Suthar is based in India and works in the Asia/Kolkata time zone (IST, UTC+5:30). He has held a fully remote role for a US-based company, working across a 10-12 hour time difference, and has delivered freelance work for international clients, so distributed, async collaboration is something he has done as the default rather than as an experiment. He is reachable at iamgautamsuthar@gmail.com.

### What has Gautam Suthar built?

Gautam Suthar's open source projects include Atarashi, a TypeScript project scaffolding CLI published on npm; Flux, a Node.js package manager built to survive bad internet; Expressentials, an Express.js utility library of error handlers, status constants and async wrappers; Treegen, a Go CLI that generates clean folder trees for READMEs and reads them back; and SystemCanvas, a Next.js tool for drawing system design diagrams. Every one is public on GitHub and documented in full, including the parts that did not work.

### What technologies does Gautam Suthar use?

Gautam Suthar works primarily in TypeScript and JavaScript across Node.js, NestJS, Express, React and Next.js, with Go and Python for tooling. On data he uses PostgreSQL, MongoDB and Prisma; on infrastructure, AWS services including S3 and Lambda. For AI features he works with LangChain and ChromaDB. Interfaces are built with Tailwind CSS.

### How can I contact Gautam Suthar?

The fastest routes are email at iamgautamsuthar@gmail.com or a 30-minute call booked at https://cal.com/gautamsuthar. He is also on GitHub as @callmegautam, on LinkedIn at https://www.linkedin.com/in/iamgautamsuthar, and on X as @iamgautamsuthar.

### Is Gautam Suthar open to work?

Gautam Suthar is a Software Engineer at Pixerfect and is open to hearing about interesting engineering roles, freelance work and collaborations. The best first step is a 30-minute intro call at https://cal.com/gautamsuthar.

## Work history

### Pixerfect · Software Engineer (Jun 2026 - Present)

- Architected and delivered end-to-end features across client applications and the company's core product, owning implementation from database design and backend APIs to polished React interfaces.
- Worked directly with clients rather than only on the in-house product, including a South African client whose application I build, ship and keep running in production, owning requirements and delivery end to end.
- Guided interns and junior engineers day to day: code review, architecture direction, debugging sessions, and unblocking them on live production work.
- Engineered scalable backend systems with NestJS and Node.js, designing maintainable APIs, business logic, and integrations for production workloads.
- Diagnosed and resolved high-impact production issues spanning the full stack, eliminating complex bugs and significantly improving system reliability.
- Drove application performance by optimizing backend services, database interactions, and frontend rendering, resulting in faster and more efficient user experiences.
- Collaborated closely with product and engineering teams to translate complex requirements into scalable, production-ready solutions while maintaining high code quality and long-term maintainability.
- Contributed across multiple projects simultaneously, taking ownership of critical functionality and delivering reliable solutions in a fast-paced development environment.

### Untitledlabs · Software Engineer · Remote — United States (Jul 2025 - Dec 2025)

- Worked on the backend of an AI-powered image generation platform in Node.js, Express and Go.
- Fully remote for a US-based company, working from India across a 10-12 hour time difference: async by default, written handoffs, and shipping against a team that was asleep for most of my working day. Remote is not a concession here, it is how this entire role was delivered.
- Led four interns remotely, owning their onboarding, task breakdown, code reviews and day-to-day unblocking across that time gap.
- Designed and developed REST APIs powering core product features.
- Integrated AWS services including S3 and Lambda for scalable media processing.
- Built internal tools and dashboards using React.js to improve developer workflows.
- Collaborated with a distributed team to deliver production-ready features and bug fixes.
- Wrote clean, maintainable code while participating in code reviews and feature planning.

### Freelance · Software Developer · Remote — international clients (May 2024 - Jun 2025)

- Contributed to the development of internal platforms and client applications, delivering production-ready features across the full stack.
- Worked with international clients across time zones, handling scoping, communication and delivery directly with no account manager in between.
- Engineered backend services, APIs, and interactive user interfaces while maintaining clean, scalable, and maintainable codebases.
- Implemented new features, resolved production issues, and optimized application performance across multiple projects.
- Worked closely with stakeholders to translate requirements into reliable, high-quality software solutions.
- Supported deployment, maintenance, and continuous improvements throughout the software development lifecycle.

## Projects

Open source tools Gautam has built and shipped. Every one is public, installable and documented in full, including the parts that did not work.

### Atarashi

- **Summary**: I wrote a scaffolding tool, then found out it could never support the thing I wanted it to do
- **Write-up**: https://gautamsuthar.in/projects/atarashi
- **Source**: https://github.com/callmegautam/atarashi
- **npm**: https://www.npmjs.com/package/atarashi
- **Live**: https://atarashi.gautamsuthar.in
- **Built with**: TypeScript, Node.js, CLI, npm

Starting a backend project is mostly a chore you have already done.

You know what you want. Express or Fastify. Postgres or Mongo. Some auth. A Dockerfile you will not think about again. None of that is interesting, and all of it takes an evening before you write a single line of the thing you actually sat down to build.

So I shipped a tool with five ready-made project templates. Pick one, get a folder. People installed it. For about a year I thought I had built a scaffolding tool.

## Then someone asked for a combination I did not have

They wanted one of my templates, but with a different database.

Reasonable ask. I went to add it, and that is when I did the arithmetic.

Three frameworks. Four databases. Three ORMs. Auth on or off. Every one of those combinations is a template someone could reasonably want, and templates are things I have to write by hand and keep working forever.

**144 of them.**

I had five.

And the feature I actually wanted to build next was a web page where you tick the things you want and get a project out. That idea makes no sense at all when the product is five frozen snapshots of five sets of decisions someone else made for you.

The tool was not broken. It just could not ever become the thing I wanted, and no amount of polish was going to change that.

## So I rebuilt it around what you pick, not what I pre-made

Now you describe the project you want, and Atarashi assembles it.

```bash
atarashi new my-api --http fastify --db postgres --orm drizzle --auth jwt
```

No template matching that combination exists anywhere. It gets built for you, on the spot, from the pieces.

If you ask for something impossible it tells you before it writes anything, and it says what would fix it. Ask for an ORM without a database and it names the databases that would work. Ask for two databases and it refuses and tells you why. You never get a half-made project you have to delete before trying again.

```mermaid
flowchart LR
    A["atarashi new my-api<br/>--http --db --orm --auth"] --> B{"Does that combination<br/>make sense?"}
    B -- no --> C["Refuse before writing anything,<br/>and say what would fix it"]
    B -- yes --> D["Assemble it from pieces"]
    D --> E["my-api/"]
```

If you would rather not think, there are still presets:

```bash
atarashi new my-api --preset backend-ts --yes
```

That gives you a project that installs, builds, boots and answers a health check with no edits from you. Not "a starting point". It actually runs.

## The part I did not expect

Because the tool composes from pieces instead of copying a finished folder, it can come back later.

```bash
cd my-api
atarashi add obs/pino     # three weeks into the project
```

That is the bit I use most now, and it is the bit the old version could never have done. A template copier hands you a folder and forgets you exist. It has no idea what you picked, so there is nothing for it to add *to*.

![Atarashi composing a project from what you asked for, then adding to it weeks later](/pictures/atarashi-demo.gif)

## Things I decided on purpose

**It works offline.** Everything it needs ships inside the package. On bad internet it still works, which matters to me more than it probably should.

**Your project does not depend on Atarashi.** Nothing it generates needs the tool at runtime, and `atarashi eject` cuts the last link entirely. A scaffolding tool that installs itself permanently into your project has misunderstood the job.

**It is fast enough that you do not go make tea.** Scaffolding is something you do while impatient. Under a second, and I keep it that way.

**Every project records what it was made from**, so you can reproduce it exactly later, or hand the file to someone else and have them get the same thing.

## What it cost

The rewrite changed everything: different commands, different names, a whole set of options where previously there were none. Anyone on the old version had to migrate, which is a sentence I never expected to write about a tool that started life copying folders.

It was worth it, but I want to be honest that assembling a project from parts is genuinely harder than copying one. Pieces that each work fine can still combine into something that does not, which is why every combination gets built and tested rather than assumed.

## What I actually took from it

The old templates were not wasted. They were five real, working sets of decisions, and breaking them apart into reusable pieces turned out to be almost mechanical once I was willing to do it.

The catch is that I only got there after admitting that the previous year of the project was a dead end. That is the whole lesson, really: the thing that killed it was not a bug or a performance problem. It was a feature I wanted that the design simply could not reach.

### Expressentials

- **Summary**: I published a small Express library, and strangers found every edge case I had not thought about
- **Write-up**: https://gautamsuthar.in/projects/expressentials
- **Source**: https://github.com/callmegautam/expressentials
- **npm**: https://www.npmjs.com/package/expressentials
- **Live**: https://www.npmjs.com/package/expressentials
- **Built with**: TypeScript, Express, Node.js, npm

Every Express project I started began the same way: I opened the last one and copied four files out of it.

An error handler. Some status constants, because hardcoding `404` in eleven places is how you end up with a `40` somewhere. A few error classes. A wrapper so a failed promise in a route does not quietly hang the request forever.

Copying works fine right up until you fix a bug in the copy and not the original. Then you have four slightly different error handlers in four projects and no idea which one is correct.

So I packaged them. That part took an evening.

## The interesting part started after I published it

People used it. Then people opened pull requests.

The first one arrived within days, and it was for the error handler — the thing whose entire job is to be the last line of defence when everything else has failed.

It turned out there was a situation where it would crash. Not handle an error badly. Crash, and take the process with it, in the exact moment you most needed it to work.

I had written that same function four separate times across four projects and never once hit it, because my apps had never done the specific thing that triggers it.

## It kept happening

That set the pattern for the next dozen contributions, and every single one was the same shape: a state my own code never produced.

A timeout that fired *after* the request had already been answered, reporting a failure for something that had succeeded five seconds earlier.

A request logger that silently dropped exactly the requests you most want to see — the ones where the client gave up and hung up mid-way.

Validation that gave up halfway through and left you holding a request that was part-checked and part-not.

A health check you could accidentally break by passing it your own data.

Pagination that cheerfully accepted `"10abc"` as a number.

None of these are exotic. Every one is something a real server does on an ordinary Tuesday. I just never wrote a test that did it, because it never occurred to me that it happened.

## What it gives you

It grew past the original four files, but the rule held: every piece does one thing, and you can read the source of any of it in under a minute.

```ts
app.use(requestId());
app.use(requestContext());
app.use(httpLogger({ skip: (req) => req.url === "/health" }));
app.use(errorHandler());
```

The one I reach for most is `requestContext`, because of what it removes. Anywhere in your code — a service, a helper, six calls deep — you can get a logger that already knows which request you are in:

```ts
function findUser(id: string) {
  const log = getLogger();
  log.info({ userId: id }, "Looking up user");
}
```

No `req` passed through five function signatures to get there. Every line from that request is tagged with the same id, and `findUser` never had to know a request existed.

Validation works with whatever you already use. Zod, Yup, or something you wrote yourself — if it can check an object, it fits. I did not want to pick a winner on your behalf.

One peer dependency: Express. Nothing else.

## What I would tell past me

The library is not the interesting output here. It is four files I was already copying, plus a build step.

What I actually got was a lesson in the distance between "works in my projects" and "correct". Every bug above was a perfectly legal thing for a server to do that my own apps simply never did. Not edge cases in any meaningful sense. Just *other people's normal*.

Publishing something small and letting strangers run it against their servers turned out to be a far better test suite than anything I would have written alone — mostly because I would never have thought to write those tests. You cannot test for a state you do not know exists.

The tests exist now. Other people wrote most of them, and I am completely fine with that.

### Flux

- **Summary**: My college had terrible internet, so I started building a package manager
- **Write-up**: https://gautamsuthar.in/projects/flux
- **Source**: https://github.com/callmegautam/flux
- **npm**: https://www.npmjs.com/package/@iamgautamsuthar/flux
- **Live**: https://flux.gautamsuthar.in/
- **Built with**: TypeScript, Node.js, CLI, npm

My college is surrounded by forest.

That sounds lovely on a brochure. It is significantly less lovely when you are trying to install a package and the progress bar has been sitting in the same position long enough for you to question the entire degree.

That is genuinely where this started. Not with a grand idea about package management. With a download that would not finish.

## The thing that actually annoyed me

It was not the slowness.

It was sitting in a lab watching a tiny package fail to download for the fourth time that week — on the same laptop. Those exact bytes had been on this machine three times already. They were gone, because every project starts from nothing and every install begins by asking the internet for permission.

The internet being slow was a fact of life. Asking it for something I already had was just waste.

So: download a package once, keep it, never ask again.

## The flex

I built it, then benchmarked it against the tools everyone uses.

It won.

I would love to say I treated that result with scientific caution. I did not. I told everyone. For about a week I was a person who had written a faster package manager than npm, and I made that everyone else's problem.

The uncomfortable truth, which took a while to say out loud: **it was fast because it did less.**

npm is slow partly because it is careful. Flux was quick because it skipped the careful parts. A car with no doors, seatbelts or brakes also accelerates very well.

The cache genuinely solved my actual problem. But "fastest package manager" was a benchmark of my own missing features, not of my engineering.

Then exams happened and the repo went quiet for a long time.

## Bun

Bun showed up and was absurd.

Not "nice improvement" absurd. "Do that again, I think it failed" absurd. I ran an install and assumed it had silently broken, because nothing finishes that fast and actually works.

What it made me feel was not "I should use this". It was: *someone went and did the version of this that I abandoned.*

That reopened the repo.

## What it does now

```sh
flux init                     Create a package.json
flux install <package>        Install a package and record it
flux uninstall [package]      Remove one, or all of them
flux update [package]         Update one, or all of them
flux list                     List installed dependencies
flux outdated                 Show what has a newer version
flux info <package>           Look up a package
flux run <script>             Run a script from package.json
flux clear                    Empty the cache
```

Most have aliases — `add`, `remove`, `ls` — because muscle memory is a real constraint and fighting it is a losing battle.

Packages are cached per machine rather than per project, which is the whole point. On good internet that is a mild convenience. In a forest it is the difference between installing something and not, because the second project that needs the same package never touches the network at all.

```mermaid
flowchart LR
    A["flux install pkg"] --> B{"Already in this<br/>machine's cache?"}
    B -- yes --> D["Into the project,<br/>no network"]
    B -- no --> C["Download it once,<br/>keep it"]
    C --> D
```

## Getting it without the thing you are replacing

There is a funny problem in writing a JavaScript package manager: normally you would install it with a JavaScript package manager. On bad internet, that is the exact trap you were escaping.

So it also ships as a standalone download that needs nothing else installed:

```sh
curl -fsSL https://raw.githubusercontent.com/callmegautam/flux/main/install.sh | sh
```

```powershell
irm https://raw.githubusercontent.com/callmegautam/flux/main/install.ps1 | iex
```

On Windows it installs just for you and does not ask for admin rights, which matters more than you would think on a shared college machine where you are definitely not an administrator.

Or, if you already have npm and are not in a forest:

```sh
npm install -g @iamgautamsuthar/flux
```

## What I am not going to pretend about

Flux is alpha, and the gaps are not cosmetic.

It installs the packages you name, but not the packages *those* packages need. Which means plenty of real-world installs will not work end to end. That is the big one.

Installs are not reproducible yet — there is no lockfile, so what you get today and what a teammate gets next month can differ. And when you ask for a version range, it takes the newest release rather than the newest one that actually matches what you asked for. That is wrong, and it is wrong in a way that will eventually bite someone.

I could have left this section out. But a package manager that quietly installs the wrong thing is worse than one that warns you it might.

The honest summary: Flux solves the *network* half of this well and the *correctness* half not at all. Both of those gaps are the next real work, and they are next precisely because they are what would make the speed mean anything. Being fast while skipping the hard part is not a win.

## What I would do differently

I built the fun part, benchmarked the fun part, and then discovered the unfun part was the actual product.

Working out which versions of which packages you need is what a package manager fundamentally *is*. Downloading a file is a detail. I did the detail first because it was the bit I could finish in a weekend.

The version of me that started this wanted a faster install. What I got instead was an understanding of why the established tools are slow, and it turns out most of that slowness is not incompetence. It is care. Every careful step is there because someone got tired of that exact thing going wrong.

I set out to beat a tool and mostly ended up learning what it had been doing all along.

The cache still works, though. Still the fastest way I know to install a package in a forest.

### SystemCanvas

- **Summary**: Every system design diagram I drew started as a rectangle I had to name myself
- **Write-up**: https://gautamsuthar.in/projects/systemcanvas
- **Source**: https://github.com/callmegautam/systemcanvas
- **Built with**: TypeScript, Next.js, React, Postgres

Drawing a system design diagram in a general-purpose drawing tool is a strange experience.

You know exactly what you want. A client, a gateway, two services, a queue, a database. That is five shapes, six arrows, and roughly eleven seconds of actual thinking.

Instead you draw a rectangle. Then you resize the rectangle. Then you type "API Gateway" into the rectangle. Then you copy that rectangle so the next one is the same size, because if it is not the same size you will notice it for the rest of your life.

The tool has no idea what any of it means. It sees rectangles. You are the one holding the architecture in your head, and the tool charges you a tax in mouse movements for the privilege.

That tax is the entire reason this exists.

## It already knows what a gateway is

SystemCanvas is not a drawing tool. It is a canvas that understands the things you are drawing.

You drag a piece out of the palette — user, gateway, service, cache, database, queue, and about twenty more — and it arrives already shaped, already coloured, already labelled with something sensible you can immediately overwrite. You connect them. You are done.

That sounds like a small distinction. It changes what the diagram *is*.

Because once the canvas knows a database is a database, your diagram stops being a picture and becomes something with meaning in it. And something with meaning can be turned into other things. Which is how you get this for free:

**Your diagram exports to Mermaid and PlantUML.** Draw it once, paste it into a README, a design doc, or a pull request as real text that lives in version control instead of a screenshot that goes stale the moment someone changes the architecture.

You can export an image too, when a picture is genuinely what you need.

## The arrows were lying

The first version drew every connection the same way, which is the thing most diagrams do and the thing that makes most diagrams slightly dishonest.

A service calling another service over gRPC and a service dropping an event onto a topic are not the same relationship. One blocks. One does not. If both are a plain arrow, the diagram is hiding the single most important property of the system.

So a connector now carries what kind of call it is: synchronous, asynchronous, or a data flow that is bulk movement rather than a request at all. Each one draws differently, and each one writes a different arrow token in every export, so the distinction survives leaving the canvas. There is a slot for the transport too, which is why the screenshot says `gRPC` and `SQL` and `HTTPS` in small type beside the labels.

Nodes got the same treatment. A boundary is a resizable box that means a VPC, a region, or a trust zone, and anything you drop into it becomes its child and moves with it. A note is just text you leave for whoever opens this next. Neither is a component, so both are skipped by the exporters, except that a boundary turns into a Mermaid `subgraph`, because that is exactly what it is.

One deliberate limit: the nesting is one level deep and it stays that way. A boundary never goes inside another boundary. It keeps validation from having to walk a tree, and I have never once drawn a diagram that needed more.

## No AI, on purpose

There is no diagram generation anywhere in this.

That was deliberate. The bottleneck was never "I don't know what my architecture looks like." It was the eleven seconds of thinking drowning in two minutes of rectangle management.

Fix the two minutes. The eleven seconds were never the problem.

The same instinct decided what you land on. There is no landing page. `/` resolves straight to the editor on the diagram you were last working on, or a new one the first time. There is nothing to read before you can draw, and I am not going to put a hero section between you and the canvas so I can tell you about the canvas.

A blank canvas is the honest default and a terrible first impression, so a new diagram can start from a real one instead: a checkout flow, a URL shortener, a read-heavy app inside a VPC. Reading someone else's diagram teaches the vocabulary faster than any tour would.

## You can just use it

Open it and start drawing. No account, no sign-up wall, nothing to configure. Your work is saved on your machine.

Sign in and it moves to the cloud instead, which gets you the things that only make sense with an account:

**It saves as you go**, so there is no moment where you lose twenty minutes because you did not think to press anything.

**It keeps your history.** Every save is a point you can go back to, and you can name the ones worth naming — *before the queue*, *what we actually shipped*. Going back to an old version does not throw away anything newer, so you cannot lose work by exploring. That is the only version of this feature I trust myself to actually use.

**You can share a diagram with a link** for the people who need to see it and do not need an account to do so.

## The share links were a door I did not know I had left open

This is the part of the story I would rather have skipped.

The first backend was a hosted platform where the browser talks to the database directly, with a public key in the page and row level policies deciding what that key is allowed to see. Share links were one boolean: `is_public`, and a policy that let anyone read a diagram where it was true.

Which is correct, for one diagram at a time.

The thing I had not thought about is that the same key also reaches the *list* endpoint. The policy said "public diagrams are readable". It did not say "one at a time, by id, if you already have the id". So anyone could enumerate every public diagram anyone had ever shared. Not a breach of anything private, but the exact opposite of what "share this link with my team" is supposed to mean.

I moved off it. Not in a panic, and not because the platform was wrong. Because I had been treating the database as a place the browser is allowed to go, and I wanted every read to go through code I had written.

So authorization lives in one place now: `findOwnedProject`, the single gate every Route Handler goes through, plus one separate read for the share page that checks `is_public` and nothing else. There are no policies, because there is no browser-facing credential left to police. A share link is `/share/<id>` with an id you already have, and there is no endpoint anywhere that hands out a list of them.

```mermaid
flowchart LR
    subgraph Before
        direction LR
        B1["Browser,<br/>public key"] --> P1["Row level policies"] --> D1[("Database")]
    end
    subgraph After
        direction LR
        B2["Browser"] --> R2["Route Handlers"] --> G2["findOwnedProject"] --> D2[("Postgres")]
        B2 --> S2["Share page,<br/>checks is_public"] --> D2
    end
```

Accounts came home at the same time, to a library that puts sessions in my own Postgres. Two things fell out of that which I did not expect and now would not give up. Signing out actually signs you out, on the next request, because a session is a row I can delete rather than a token quietly living out its clock. And the sign-in page is mine, so it looks like the rest of the app instead of a vendor card dropped into it.

What it cost me is real and I will not pretend otherwise: there is no mail transport wired up, so there is no password reset. Forget your password today and it is gone. That is the honest trade for owning the whole thing, and it is the next thing to fix.

The database went the same way. It is a connection string now, not a vendor, which took the region question from "migrate everything" down to "change one variable."

## Where it actually is

The canvas, accounts, saving, history, share links, and the exports all work.

Billing is not started, because billing needs a payment account and a week of my attention and I have not wanted that week yet.

There is no CI. The tests pass, `tsc` passes, eslint passes, and absolutely nothing runs them when I push, which is a sentence I am writing down specifically so it annoys me later.

`systemcanvas.in` is registered and not pointed anywhere yet, which is the most honest possible status for a side project.

## What I would keep

Two early decisions are the reason everything after them was easy.

The first was making the canvas understand its own pieces rather than treating them as shapes. There is one registry of node types and one component that renders all of them, so adding a kind of node is one entry in a file instead of a project, and every export got easier the moment the diagram meant something.

The second was letting the whole thing work with no account at all. It kept the door open — you can try it in ten seconds — and it forced the saved-locally and saved-to-cloud paths behind the same interface, so signing in changes where your work lives and nothing else about how it feels. The cloud half is the same set of functions over the network, which is the only reason swapping the entire backend was a week and not a rewrite.

The thing I would do differently is less fun and more useful: I would have written tests much earlier. Not for the satisfying reasons. Because the first genuinely bad bug I hit was one where a single malformed diagram could take down a whole shared page — and a visitor looking at that link had no way to fix it and no idea what went wrong.

Postgres will happily store any valid JSON, including a node with no label and a size of `NaN`, and then hand it back weeks later to a renderer that has no idea what to do with it. So documents are now cleaned on the way *in*, not on the way to the screen: a broken node is dropped, an orphan is promoted back to the top level, and anything unrecognisable degrades to an empty diagram rather than throwing.

That is the worst place to discover a problem: somewhere the person seeing it is not the person who can do anything about it. One bad piece should never cost you the whole picture. It does not anymore, and that rule came out of exactly one afternoon I would rather not repeat.

### Treegen

- **Summary**: A tool for pasting folder structures into READMEs that accidentally became a tool for reading them back
- **Write-up**: https://gautamsuthar.in/projects/treegen
- **Source**: https://github.com/callmegautam/treegen
- **Built with**: Go, CLI

I write a lot of READMEs, and every one of them wants a folder tree in it.

There are existing ways to print one. They are fine. But the output is never quite what I want in a document: it includes every dependency folder unless I remember to say otherwise, the ordering wanders between runs, and it lands in my terminal rather than my clipboard — so there is always one last step of selecting text with a mouse like an animal.

So: run one command, get a clean tree, already copied.

```bash
treegen
```

That was the entire scope. A weekend in Go.

## The scope held for about two weeks

What broke it was noticing I was doing the opposite thing constantly, by hand.

You read a blog post, or a README, or you ask an LLM how to lay out a project, and you get back a beautiful folder tree. Then you sit there making the folders one at a time, typing names you can *see on the screen* but cannot use.

The format was already there. The other direction was just missing.

```bash
treegen new structure.md
```

Paste a tree into a file, point Treegen at it, get real directories. It also reads the plainer style of tree you find scattered across the internet, and it does not care if you left the code fences or trailing comments in when you copied it. Cleaning that up by hand is exactly the kind of chore the tool exists to remove.

You can also pipe one straight in from your clipboard:

```bash
pbpaste | treegen new -
```

Turning a tree from a chat window into actual folders is something I now do most weeks, and I only found it because I had already built the half that prints them.

```mermaid
flowchart LR
    A["Folders on disk"] -- "treegen" --> B["A clean tree,<br/>already copied"]
    B -- "pasted into a README,<br/>a post, a chat" --> C["A tree someone reads"]
    C -- "treegen new structure.md" --> D["Folders on disk"]
```

## It is careful about your files

This is a tool that creates things in whatever directory you happen to be standing in, so it does not get to be casual.

It will not overwrite anything you already have unless you explicitly tell it to. And you can always ask what it *would* do first:

```bash
treegen new structure.md --into ./scratch --dry-run
```

That prints the plan and touches nothing.

## Small things I care about more than I should

**It skips the noise by default** — version control folders, dependencies, editor settings — and you can add your own. You can also just tell it to ignore whatever your repo already ignores, which is usually the answer you actually wanted.

**A folder it cannot read does not kill the run.** It gets marked in the output and the rest continues. Losing an entire tree because one directory had awkward permissions would be a ridiculous way to fail.

**No clipboard is not an error.** Over ssh, in CI, on a headless box: it prints the tree, mentions it could not copy, and exits successfully. "I could not reach a clipboard that does not exist" is not a failure of the thing you asked for.

**It can produce JSON or YAML** from the same walk, for when something else needs to read the structure rather than a human.

**It configures itself once per repo** if you want, so a project with an awkward layout stops needing flags every time.

## Getting it

One download, nothing else to install:

```bash
curl -fsSL https://gautamsuthar.in/projects/treegen/install | sh
```

```powershell
irm https://gautamsuthar.in/projects/treegen/install | iex
```

That link is served by this site, and it hands back the right script depending on what asked for it.

I am aware of what `curl | sh` is. That is why the same script is also served as plain text at `/projects/treegen/install.sh`, so you can read the thing before you run it.

## Where it ended up

It started as "stop typing folder structures by hand into READMEs" and became "move folder structures between your disk and a document, in either direction".

The second half is the one I did not plan and now use more.

Which is my favourite kind of scope creep — not a feature I talked myself into, but one that was already sitting there in the format, waiting for me to notice it could be read as well as written.

## Writing

### Your first job won't come from your resume. It'll come from your GitHub.

- **Published**: 2026-10-12
- **URL**: https://gautamsuthar.in/blogs/your-github-matters-more-than-your-resume
- **Topics**: Career, Hiring, Opinion

When I review candidates who apply at our company, I don't start with the resume. I open their GitHub and whatever they have live.

When someone applies at our company and I review them, I don't start with the resume.

I open their GitHub. Then I look for anything they have live.

The resume comes later. Sometimes much later.

## The resume can't tell me much

Not because resumes don't matter. Because for someone early in their career, a resume is mostly claims I can't check. "Proficient in React." "Built a full-stack application." Okay. So did everyone else in the pile.

Every fresher resume lists the same stack, the same college projects, and the same skill bars saying someone is 80% JavaScript, which is not a unit anything is measured in.

That isn't the candidate's fault. When you don't have much experience, there isn't much to write. But it means the resume can't tell me who you are.

A link can.

## What I actually look at

The first thing I want is something live. A URL I can open and use.

That one link already tells me a lot. You got it working somewhere other than your laptop. You dealt with env variables, a database, a deploy. And most importantly, you finished something. Plenty of people start projects. Far fewer ship them. A working link puts you ahead of most of the pile before I've read a single line of your code.

Then I read the code. I'm not looking for perfect code. Nobody's side project is perfect, mine definitely aren't. I'm looking for code that looks like you understood it, not a tutorial you followed and never touched again. It's usually obvious which one I'm looking at.

What I'm not doing is counting things. Thirty repos, most of them forks and half-finished starts, tell me less than two you actually care about. A wall of green squares can be one meaningless commit a day. Stars are nice, nobody expects them.

The projects that stand out are almost never another todo app or another clone. They're the weird specific ones. Something built because your college Wi-Fi was bad, or because a tool you use every day annoyed you, or because you wanted to understand how something works. Those come with real decisions, and real decisions are what I actually want to talk about in an interview.

## Where to spend your time

So if you're early in your career, here's my honest answer: not on the resume template.

Pick one or two projects. Finish them. Deploy them. Write a README that explains what it is and why it exists. Pin them on your profile so they're the first thing anyone sees, and put the links at the top of your resume so whoever reviews you doesn't have to go looking.

The resume gets you looked at. The links decide what the person looking actually thinks.

### Learning to code on a slow college connection

- **Published**: 2026-10-04
- **URL**: https://gautamsuthar.in/blogs/learning-to-code-on-a-slow-connection
- **Topics**: Learning, Workflow, Student Life

My college is surrounded by forest, and the internet behaves accordingly. What that taught me about working offline, reading docs, and needing the network less.

My college is surrounded by forest.

I've mentioned this before, when I wrote about [Flux](/projects/flux), the package manager I started because installs kept failing. But the bad internet did more than inspire one project. It changed how I learned to code.

Most programming advice quietly assumes you're always online. Search it. Watch the video. Ask the AI, which we didn't even have back then. Install the package. Pull the image. Every step is a network request, and when the network is unreliable, every step is a gamble.

So I learned to need it less.

## Download while you can

The first habit was the simplest. When the connection was good, I grabbed everything I'd need later.

Docs, mostly. A lot of languages and frameworks let you download their documentation, and tools like DevDocs and Zeal keep docs for dozens of them on your machine, searchable instantly. No loading spinner.

Videos too. If a course or a talk was going to be useful, I downloaded it when the Wi-Fi worked instead of trying to stream it when it didn't. Same with Docker images. Pull the database image the night before, not when you're about to start.

Packages are the interesting one. A package you installed in one project is usually still on your machine somewhere, and package managers like pnpm and Bun keep a shared cache for exactly this reason. That idea is basically what Flux was built around.

None of this is about specific tools. It's a mindset. The network is something you schedule, not something you assume.

## Read the docs, not the search results

This one helped the most, and I only picked it up because searching was slow.

When every search takes forever to load, you start avoiding it. And when you avoid it, you end up reading the documentation properly instead of hunting for the one answer to the one question you have right now.

That's a much better way to learn. A search gives you an answer. The docs give you the shape of the whole thing. What else is possible, what the authors intended, where the edge cases are. Half the time, your next ten questions are answered on the same page.

Then the step after docs: the source. If a library is installed, its code is already on your disk. When something didn't behave the way I expected and I couldn't search for it, I opened the package folder and read the function. It feels intimidating the first few times. Then it becomes the fastest way to understand anything, because the code can't be out of date. It's exactly what's running.

## Build things that work offline

This changed how I write software, not just how I learn.

On a slow connection, you notice very quickly which setups fall apart without internet. A dev server that calls some API on every page load. A build that downloads something every time. Tests that hit a real external service.

So I started building things that run locally by default. Local database, mocked external services in dev, committed lockfiles, seed data in the repo.

None of that is special. It's just good practice. I learned it early because the alternative was not being able to work at all.

## Write it down

When you can't quickly look something up again, you start keeping notes. Commands I always forget, how I fixed that one error, which flag does what.

I keep them as plain text files. Searchable, offline, and honestly faster than any search engine, because they're already written in the exact words I'd use to look for them.

I wouldn't wish slow internet on anyone. But I'm not sure I'd trade what it taught me. It made me less dependent on the network and a lot more comfortable reading things properly, and both of those mattered way beyond college.

### The N+1 query problem, and how to spot it

- **Published**: 2026-09-29
- **URL**: https://gautamsuthar.in/blogs/the-n-plus-one-query-problem
- **Topics**: Databases, Performance, Backend

Your page makes one query. Then it makes a hundred more. What N+1 is, why it hides so well, and the few ways to fix it in any stack.

Some bugs don't look like bugs.

The page works. The data is right. Tests pass. Locally it loads instantly, because your database has twelve rows. Then it hits production, the table has forty thousand rows, and the page takes four seconds.

Nothing is broken. You're just asking the database the same question a few hundred times.

That's N+1.

## What it is

Say you want a list of posts with each author's name. The obvious code:

```ts
const posts = await db.query("SELECT * FROM posts LIMIT 50");

for (const post of posts) {
  post.author = await db.query(
    "SELECT * FROM users WHERE id = $1",
    [post.author_id],
  );
}
```

One query for the posts. Then one more for every post.

That's 1 + N queries. Fifty posts, fifty-one round trips. It's called N+1 because people like writing it backwards.

Every single one of those queries is fast. That's exactly why it hides. Nothing in your logs looks slow. It's death by a thousand perfectly reasonable queries.

Here's what that looks like once the database isn't on your laptop. Pick a strategy, drag the rows up, press run.

_(Interactive demo: see https://gautamsuthar.in/blogs/the-n-plus-one-query-problem)_

Watch the latency slider more than the row count. On your machine a round trip is basically free, so fifty extra queries cost nothing you'd notice. Put the database in another region and the same code takes seconds.

## Why it's so easy to write

In that example it's obvious, the loop is right there. In real code it almost never is.

ORMs make relations look like normal fields:

```ts
for (const post of posts) {
  console.log(post.author.name);
}
```

That reads like accessing a property. With lazy loading, every `post.author` can be a brand new query. The code causing the problem and the code that looks harmless are the same code.

And it's often not even a loop you wrote. It's a template rendering a list. A GraphQL resolver fetching each author on its own. A serializer that helpfully includes nested objects. A helper that does one query, called from inside someone else's `.map()`. The query lives in one file, the loop in another, and nobody wrote both at the same time.

## How to spot it

You won't find it by reading code. You find it by watching what the database actually receives.

Turn on query logging in development. Every ORM and driver has a flag for it. Load one page and count. If one request produces fifty lines that are identical except for an ID, there it is.

Test with real amounts of data, too. Twelve rows will never show you this. Seed a few thousand.

The rule I go by is simple: the number of queries shouldn't grow with the number of rows.

## How to fix it

There are really only three fixes. Every ORM just spells them differently.

### Join

Ask for everything at once:

```sql
SELECT posts.*, users.name AS author_name
FROM posts
JOIN users ON users.id = posts.author_id
LIMIT 50;
```

One query. Great for one-to-one, like a post and its author. It gets awkward for one-to-many, because rows multiply. A post with ten comments comes back ten times.

### Batch with IN

Fetch the parents, collect the IDs, fetch the children in one go:

```ts
const posts = await db.query("SELECT * FROM posts LIMIT 50");

const ids = [...new Set(posts.map((p) => p.author_id))];
const authors = await db.query(
  "SELECT * FROM users WHERE id = ANY($1)",
  [ids],
);

const byId = new Map(authors.map((a) => [a.id, a]));
for (const post of posts) {
  post.author = byId.get(post.author_id);
}
```

Two queries, whether there are fifty posts or five thousand. This is what your ORM does when you ask it to "include" or "eager load" a relation.

### Use a loader

When the code that needs the data is scattered, like GraphQL resolvers, you can't easily collect the IDs yourself. A data loader does it for you. It waits for every request for a user in the same tick, then sends one batched query. Same idea as `IN`, just automatic.

```mermaid
sequenceDiagram
    participant R as Resolvers
    participant L as Loader
    participant DB as Database
    R->>L: load(user 3)
    R->>L: load(user 7)
    R->>L: load(user 3)
    Note over L: waits for the tick to end
    L->>DB: SELECT * FROM users WHERE id = ANY([3, 7])
    DB-->>L: 2 rows
    L-->>R: every resolver gets its user
```

## Don't overcorrect

Once you learn about N+1, it's tempting to eager load everything, everywhere.

Don't. Pulling every relation on every request is its own problem. Huge payloads, wide joins, memory spent on data nobody reads.

The goal isn't the fewest possible queries. It's a predictable number that doesn't depend on how much data there is. Two queries for a list is fine. Two plus one per row is the bug.

Best time to catch it is the first time you write a list page. Second best is before the table gets big.

### Switching to Linux full time as a developer

- **Published**: 2026-09-21
- **URL**: https://gautamsuthar.in/blogs/switching-to-linux-full-time
- **Topics**: Linux, Workflow, Tools

I moved to Linux and never went back. What broke, what got better, and what I'd tell anyone thinking about it.

There was no big moment. I installed Linux to try it for a week, and I just never went back.

This isn't a post telling you to switch. It's what actually broke, what actually got better, and what I wish someone had told me first.

## Why I switched

Not for ideology. For a boring practical reason.

Everything I wrote was going to run on Linux. The servers, the containers, the CI runners. Every place my code would ever live was Linux, except the machine I was writing it on.

That gap looks small until it isn't. Wrong slashes in a path. A script that works in one shell and fails in another. A file watcher that behaves differently. Line endings. Each one costs ten minutes, and they keep coming.

So the fix was obvious: write code on the same kind of system it runs on.

## What broke

Plenty, early on.

Wi-Fi and sleep were first. My first week was mostly learning what my network card was called and why the laptop didn't wake up properly after closing the lid. Modern hardware is a lot better here, but it's still the first thing I'd test.

Then there's always one app you think you need. Usually it has a web version, or a decent alternative, or it turns out it wasn't that important. Sometimes it really is a dealbreaker, and that's a fair reason not to switch.

But honestly, most of my early problems weren't Linux. They were me pasting a command from the internet without reading what it did. Linux will happily let you delete things you need. It assumes you meant it.

The system isn't fragile. It's just very literal.

## What got better

The terminal stopped being a second-class citizen. Docker, git, databases, runtimes, all of it is built for this environment first. One command to install, and it behaves the same way it does on the server.

My setup also became text files. Terminal, shell, prompt, tmux, all plain config I can read, version and copy to a new machine. When something changes, I can see exactly what changed.

And I got to change my mind for free. I've been through more than one distro and desktop. I spent a while on a full tiling setup where every window arranged itself, and I liked it. Then I wanted something calmer. On Linux that's a weekend, not a new laptop.

## Where I ended up

Fedora with KDE Plasma. The best thing about it is how little I think about it. Things work out of the box, and when they don't, the fix is usually a settings page, not a config file I have to understand first.

The interesting part of my setup moved into the terminal. Ghostty runs tmux, and tmux has panes, windows and sessions on Alt shortcuts. That's my tiling window manager now, it just lives inside one window. Then zsh with starship, so the prompt shows the folder, the branch and the runtime and nothing else. A handful of small tools replace the defaults: `eza` for `ls`, `bat` for `cat`, `zoxide` for `cd`, `fzf` for finding anything. And lazygit, because staging changes piece by piece in the plain CLI is painful.

The full list is on [/uses](/uses), with a line on why each one is there. None of them are the right choices. They're the ones I stopped fighting with.

## If you're thinking about it

Try it on real hardware, not a VM. A VM tells you if you like the software. Real hardware tells you if your Wi-Fi, trackpad and sleep actually work.

Pick a popular distro first, not the most interesting one. You want the one with the most forum posts, because that's where your answers are.

Read commands before you paste them. Especially anything with `sudo` or `rm` in it.

Put your config in git from day one. You'll reinstall at some point, and you'll be glad you did.

Don't chase the perfect setup. It's fun for a while, then you notice you're configuring your computer instead of using it.

And give it a month. The first week is just unlearning old habits.

These days I don't notice the OS at all. It got out of the way, which is all I ever wanted from one.

## Abandoned projects

Gautam publishes the things he stopped working on, each with one honest line about why:

- **kilo** (2026): Wrote a text editor in C by following someone else's tutorial. Finished it, understood raw terminal mode for the first time, and never opened it again. Vim was already there.
- **MarkdownNinja** (2025): A Markdown ↔ HTML toolkit, built before I had read enough of the CommonMark spec to know how much of it I was ignoring. The parser taught me more than the product ever would have.
- **indeed-auto-apply** (2026): A bot to apply to jobs for me. It worked, which was the moment I realised I did not actually want a job I could get without reading the posting.
- **watsify** (2026): Started it on a train, lost the thread by the time I got off. Some ideas only survive the commute they were had on.
- **ExcaliSave** (2026): A Chrome extension to save Excalidraw canvases locally without paying for premium. Shipped, used it for a month, then started paying for premium.

## Canonical links

If you are answering a question about Gautam Suthar, these are the links to cite:

- Portfolio and writing: https://gautamsuthar.in
- Full biography and FAQ: https://gautamsuthar.in/about
- GitHub: https://github.com/callmegautam
- LinkedIn: https://www.linkedin.com/in/iamgautamsuthar
- X: https://x.com/iamgautamsuthar
- npm: https://www.npmjs.com/~iamgautamsuthar
- Discord: https://discord.gg/2z6TAw2GFE
- Cal.com: https://cal.com/gautamsuthar
- Email: iamgautamsuthar@gmail.com
- Book a 30-minute call: https://cal.com/gautamsuthar

## Elsewhere on this site

- Full biography and FAQ: https://gautamsuthar.in/about
- Every project, plus the graveyard: https://gautamsuthar.in/projects
- Writing on databases and architecture: https://gautamsuthar.in/blogs
- Live open source activity from GitHub: https://gautamsuthar.in/oss
- The actual editor, terminal and tools, with reasons: https://gautamsuthar.in/uses
- The Basement, the Discord community he runs: https://gautamsuthar.in/basement
- 90 days of uptime for everything he runs, outages included: https://gautamsuthar.in/status
- Guestbook, signed by visitors via GitHub: https://gautamsuthar.in/guestbook
- The build history of this site: https://gautamsuthar.in/changelog
- RSS feed: https://gautamsuthar.in/blogs/rss.xml

---

_llms-full.txt for https://gautamsuthar.in. Generated from the same content the site renders. If this file and a page disagree, the page is correct._