DEV Community: SURAJ NANDAN

Team projects: what I try to do, from building GigShield with two teammates

SURAJ NANDAN — Sun, 25 Oct 2026 03:30:00 +0000

GigShield is a parametric income-insurance platform for delivery riders. It was a team of three, built with Rishabh and Abhinav, so the credit isn't mine alone. I'll say that every time I talk about it.

This post is about what the project is, which pieces I built, and what I try to do on team projects. Some of those lessons are things I did; some are things I now try to do. I'll be clear about which is which.

The problem

Delivery riders in India are paid weekly and live on thin cash buffers. One day of heavy rain, a hazardous air-quality reading or a platform outage can wipe out a day or two of income. Traditional insurance, with its paperwork, adjusters and reimbursement weeks later, doesn't fit a loss that small and that sudden.

Our answer was parametric cover: instead of reimbursing a loss after someone proves it, it pays a fixed amount automatically when an objective, external signal crosses a threshold.

We priced it the way riders think about money, weekly:

Plan	Weekly price
Basic	₹79
Standard	₹129
Pro	₹179

Each plan has its own daily payout cap and covered hours. The product deliberately covers lost earning hours only: no health, life, accident or vehicle cover.

My part

The role line from the case study, for accuracy: I built the trigger engine, the payout lifecycle and receipts, the rider dashboard, the admin and fraud-review screens, role-based routing and the 3D landing page. The liveness check was built together with Rishabh. Rishabh and Abhinav built most of the authentication, the Express server and the help chat.

The trigger engine

It watches for seven kinds of disruption: heavy rain, heatwave, AQI spikes, platform outages, curfews, local strikes and zone closures. Rather than a bare yes/no, each trigger gets a confidence score, built from:

a base value per trigger type,
how reliable the weather data source was,
and the rider's risk profile (higher risk lowers confidence).

The score maps to a label: Strong, Normal or Weak. In sketch form:

function triggerConfidence(base: number, sourceReliability: number, riderRisk: number) {
  const score = base * sourceReliability * (1 - riderRisk * 0.3);
  if (score > 0.75) return 'Strong';
  if (score > 0.5)  return 'Normal';
  return 'Weak';
}

(That's illustrative. The real thresholds are in the repo. They're reasonable guesses, and I'll explain why that matters below.)

Weather comes from Open-Meteo, with a 2.5-second timeout and an automatic fallback to wttr.in. That way one flaky API can't quietly stop the engine. Cooldown and de-duplication windows stop a single storm from firing again and again, and every trigger is written to an audit trail that syncs to the backend.

Payouts and fraud

A claim moves through a visible lifecycle, pending verification → verified → processing → settled, and riders get a downloadable PDF receipt. In this build payouts are simulated; there's no real payment rail connected.

For fraud, we built a liveness check on risky sessions: the app asks for a random hand gesture, and MediaPipe's hand-landmark model classifies it right in the browser.

What I try to do on team projects

These are practices I'm working towards, informed by this project. I'm not claiming a perfect record.

Split by interface, not by file

Agree the contract between the pieces first (what data crosses the boundary, in what shape), then build each side independently. "You do the frontend, I'll do the backend" fails when nobody has defined what the frontend sends.

Write the contract down

Even a messy README beats arguing in chat. A written contract can be pointed at; a remembered one gets reinterpreted.

Merge small, merge often

Integration pain arrives all at once if you wait. Small merges turn one big collision into many tiny ones.

Agree what "done" means

"Works on my machine" can mean three different things to three people. Agree upfront: does it mean deployed? Tested? Reviewed?

A trap I watch for

Taking over the hard part because it's faster than explaining it. It's a short-term win and a long-term loss for the team. The teammate who never gets to struggle with the hard part never learns it.

What I'd flag as limits

The case study lists these honestly, and they apply here too:

Trigger cooldown and de-duplication state lives in the browser's storage, which is fine for a demo but belongs on the server in anything real.
Payouts and parts of the fraud workflow are simulated.
The thresholds are reasonable guesses. Calibrating them properly would need historical weather and earnings data we didn't have.

If you're starting a team project

Agree the contract.
Merge small, merge often.
Write down who owns what.
Credit everyone, publicly, by name.

A one-page team contract

Fill this in at the start of any team project. It takes ten minutes and prevents hours of argument.

PROJECT:           ______________________
GOAL (one line):   ______________________
DEADLINE:          ______________________

OWNERS
  Frontend:        ______   Backend:    ______
  Data / schema:   ______   Deploy:     ______
  Docs / demo:     ______

CONTRACTS
  API shape agreed in: ______ (file / doc link)
  Branch strategy:     main + short-lived feature branches
  Merge rule:          at least one review, merge daily

DEFINITION OF DONE
  [ ] works on the deployed URL  [ ] reviewed  [ ] README updated

IF WE DISAGREE
  Each side writes 3 lines. Pick the option that is easiest to reverse.

A tiny API contract example

Agree on the exact shape before building either side:

// POST /api/claims
// request
{ "riderId": "r_123", "triggerType": "heavy_rain", "triggeredAt": "2026-06-01T08:00:00Z" }

// response 201
{ "claimId": "c_456", "status": "pending_verification" }

// response 409 (duplicate within cooldown)
{ "error": "duplicate_trigger", "retryAfterMinutes": 180 }

(This is an illustration of the format, not GigShield's actual API.) Once both sides agree, the frontend can mock it and the backend can implement it in parallel.

Handling disagreements

Disagreements are normal. Some approaches that help:

Separate the decision from the person. Argue about options, not people.
Prefer reversible decisions. If it's easy to undo, just try it.
Time-box debates. Fifteen minutes, then decide.
Write down the decision and the reason, so it isn't re-litigated next week.

Teaching while you build

The trap I mentioned, taking over the hard part, has a better alternative:

Pair on the first one. Do the hard task together, once.
Let them drive. You narrate; they type.
Review rather than rewrite. Comment on their version instead of replacing it.
Celebrate the learning, not just the result.

It's slower for a day and faster for a month.

Crediting people

On a portfolio or a post, a good credit line states the team size, the names, and which part you built. For GigShield, that's a team of three with Rishabh and Abhinav, and the case study says exactly which parts I built. It's accurate, and it makes your own claims more believable.

What's your best tip for team projects that don't implode?

Tutorial hell is real, and the way out is boring

SURAJ NANDAN — Sat, 24 Oct 2026 03:30:00 +0000

Tutorial hell is a trap most learners fall into at some point. You may know it: a folder of half-finished follow-alongs and the feeling of progress without any actual skill.

The good news is that the way out isn't clever. The bad news is that it's boring. This post lays out why tutorials trap people, a concrete way out, and a one-week experiment you can run starting tomorrow.

What keeps people stuck

Tutorials remove the hardest part of programming: deciding what to do next.

When you follow along, you always know the next step, because someone is telling you. The tutorial author already made every design decision, hit every dead end, and edited the video so it looks smooth. You experience the result of those decisions without experiencing the decision-making.

That's pleasant, and it feels like learning. But the skill you actually need on a real project is the one the tutorial hid from you:

Which of the ten possible approaches should I try first?
What do I do when the error message makes no sense?
How do I know whether this design will hurt me in a week?

You can't learn those by watching someone else answer them.

What helps

Not a clever trick. A project slightly too big for you, and a deadline you made up.

Step 1: Pick something you want to use

Not a todo app. Not a weather clone because every tutorial has one. Something that solves a small problem you actually have. Motivation is the fuel, and borrowed motivation runs out around the second hard bug.

Step 2: Write the smallest version that works

Write down, in one sentence, what the smallest useful version does. Then build only that. If the sentence has the word "and" in it more than once, it's too big.

Step 3: Get stuck. Search the exact error. Fix it. Repeat.

This is the actual curriculum. It's slow, uncomfortable, and where nearly all the learning happens. Copy the error message exactly, read the top few answers, and try one fix at a time.

What "slightly too big" looks like

My college RAG helpdesk, Internal GPT, stretched me in exactly this way. To be useful at all, retrieval, embeddings and chunking all had to work. A helpdesk with no retrieval isn't a helpdesk, so each piece had to be learned, because the project wouldn't work otherwise.

Notice that the project didn't teach me by being impressive. It taught me by being blocked until I understood things. That's the property to look for: a project where the next step isn't handed to you.

A realistic weekly plan

If you're stuck right now, here's a plan that fits around other commitments:

Day	Task
Mon	Write a one-sentence spec for the smallest version. List 3 unknowns.
Tue	Research only the first unknown. Build the thinnest slice that touches it.
Wed	Get it running end to end, however ugly.
Thu	Break it on purpose. Fix what breaks.
Fri	Deploy it somewhere with a real URL.
Sat	Write down what you learned in 10 lines.
Sun	Rest. Seriously.

Two things in that plan are non-negotiable. First, ship something ugly by Wednesday. Second, deploy by Friday. A live URL changes how seriously you take a project.

A caveat: tutorials aren't evil

I'm not saying tutorials are useless. They're great for a new tool, when you need to learn its vocabulary and shape quickly. Documentation quick-starts do the same job.

The trap is using them as a substitute for decisions. A good rule of thumb: use a tutorial to learn the tool, then close it and make your own decisions with it.

One-week experiment

Here's the exercise I'd actually recommend.

Finish a tutorial you've been meaning to finish.
Close it.
Build the same thing again from memory, with one change (a different data source, a new feature, a different layout).
Notice exactly where you freeze.

Those freezes are the real curriculum. Write each one down as a question. That list is your study plan, and it's far more useful than the next tutorial.

Signs you're making progress

Progress feels different from watching:

You get stuck more often, but you get unstuck faster.
You start recognising error messages.
You can estimate roughly how long something will take.
You have opinions about how to structure a project.
You've deleted code you wrote because you found a better way.

If those are happening, you're out of the hell, whatever your folder of unfinished tutorials says.

A project ladder

If you're not sure what to build, climb a ladder. Each rung is slightly too big for the previous one.

Rung	Project	The new thing it forces
1	A command-line tool that renames files by pattern	Reading input, handling errors
2	A small web page that reads and writes to local storage	State, the DOM, persistence
3	A tiny API plus a page that uses it	Requests, validation, deployment
4	The same app with real accounts and a database	Auth, permissions, schema design
5	A collaborative or real-time feature	Concurrency, sync, failure modes

Notice that nothing on the ladder is a tutorial clone. Each rung is something a real person might use.

How to choose when you're stuck choosing

Write down three annoyances from your own week.
For each, ask: could a small program help?
Pick the one you'd actually use tomorrow.
Write the one-sentence spec.

If you can't think of anything, ask a friend or family member what repetitive thing they do. Real users produce better projects than invented ones.

A "freeze log"

When you rebuild something from memory, keep a log of where you stalled:

Freeze 1: couldn't remember how to debounce the search input.
  -> Question: what is debouncing and when is it needed?
Freeze 2: didn't know how to handle a failed fetch.
  -> Question: how do I show an error state?
Freeze 3: unsure where to store the auth token.
  -> Question: cookies vs local storage, trade-offs?

Each freeze is a learning target, so study those, not the next generic course.

Questions people ask

"Isn't it inefficient to struggle?" Short struggles are the efficient part. The rule of thumb: if you're stuck for more than 30–45 minutes with no new idea, ask for help or read the docs. Struggle with a time limit.

"What if I don't know enough to start?" You never will. Start with the smallest slice and learn as the next block appears.

"Should I stop watching tutorials entirely?" No. Use them like a dictionary: look up what you need, then go back to building.

"How do I know the project is 'big enough'?" If you can finish it in a weekend without learning anything new, it's too small.

When you finish

A finished project has three artifacts: the code, a live URL and a short write-up. The write-up is the part that turns a project into evidence of learning. Say what it does, what you struggled with, and what you'd change.

What's the biggest thing you've built that you weren't "ready" for? What forced you to learn?

Why my portfolio looks like a newspaper (and what that taught me about design systems)

SURAJ NANDAN — Fri, 23 Oct 2026 03:30:00 +0000

Most developer portfolios are a dark gradient with a glowing card. I wanted something people would remember, so mine is a newspaper: The Nandan Review.

Underneath it is a small design system I call The Press. This post is about how it works, why the newspaper idea held together, and what it taught me about design systems in general. If you've ever stared at a blank stylesheet wondering what shade of grey to use, this is for you.

The idea: ink on paper

A newspaper press is mechanical, precise and industrial. It stamps ink onto paper with force and intention. I wanted every interaction on the site to feel the same way: deliberate and a little permanent.

That gave me a first principle that I could test every decision against:

Everything should feel printed.

What does that rule out?

Glowing or fluorescent colours. Print is muted and natural.
Rounded, soft borders. Rules in print are hard and sharp.
Floaty blurred shadows. Print shadows, if they exist, are sharp and dark, cast by a light that never moves.

Once I had that single sentence, dozens of tiny decisions stopped being decisions.

Three fonts, three jobs

The second principle is typographic hierarchy: every font serves one purpose and never overlaps.

Archivo (variable) for display headlines. Heavy weight, tight letter-spacing, commands attention.
Newsreader (variable) for body text. Elegant serifs and a comfortable reading rhythm.
Space Mono for metadata, labels and code. Its monospaced precision tells you "this is a technical detail, not narrative."

The enforcement matters more than the choice. Because each font has exactly one role, the typography becomes invisible. Readers absorb content without ever thinking about the typeface, which is the goal.

Colour: paper, ink, oxblood

The palette is deliberately tiny: a warm paper tone, a near-black ink, and an oxblood accent. That's it.

Here's the practical effect. When I add a new component, I never ask "what shade should this be?" The answer is already decided: it's paper, ink or oxblood. In a design system, that's what "tokens" are for. Instead of hard-coding colours, I name them:

:root {
  --paper:    /* warm off-white */;
  --ink:      /* near-black */;
  --oxblood:  /* the one accent colour */;
}

.press-card {
  background: var(--paper);
  color: var(--ink);
  border: 2px solid var(--ink);
  box-shadow: 4px 4px 0 var(--ink);   /* hard shadow, no blur */
}

.press-tag {
  font-family: 'Space Mono', monospace;
  color: var(--oxblood);
}

Notice there's no blur radius on that shadow. A hard, offset shadow is the whole "printed" look in one line.

The grid is law, but not a prison

Layouts follow a strict column grid that gives the page a visual rhythm. But it flexes at breakpoints, like a newspaper reformatting for different editions:

Desktop: a multi-column layout that mirrors a broadsheet.
Mobile: a single column that reads like a pocket edition.

Because everything snaps to the same underlying grid, elements align vertically across the page, which creates the quiet order that print designers perfected over centuries.

A tiny component library

A design system isn't only tokens. It's a set of reusable pieces that carry those tokens everywhere. The Press has a handful of primitives:

PressSection: the paper background with a subtle noise texture overlay.
SectionMasthead: section headers with an animated rule that draws across the page, like a press stamping down the title.
PressTag and PressButton: consistent interactive elements with hard borders and monospaced labels.

Each one is small, but because every section uses them, the whole site feels like one publication instead of a collage.

Motion that has a reason

My motion rule: animation must explain something. It isn't decoration.

Content reveals with a gentle stagger and slight upward motion, like sheets of paper being fed through a press. It guides attention from one thing to the next.
Section rules draw horizontally, simulating the mechanical action of a press.

If an animation doesn't help someone understand order or structure, it doesn't ship.

Why a newspaper for a portfolio?

A developer portfolio is fundamentally a record of work. A newspaper is a format people already know how to scan:

Projects become front-page stories.
Certifications become archive entries.
Skills become classified listings.

The metaphor gives structure to content that would otherwise be a pile of cards. It also makes the page feel intentional, because a theme that's applied consistently reads as craft.

What I'd warn you about

I'm not going to pretend a strong theme is free.

A strong theme can become a cage. Some content just doesn't fit a newspaper layout, and you end up bending it or leaving it out.
Accessibility needs deliberate checking. Beige paper plus grey text is an easy way to fail contrast requirements. Muted palettes need extra attention, not less.
Themes age. If you make the metaphor the whole identity, changing it later is a rebuild.
It's not for everyone. Many visitors just want the facts fast, and a distinctive layout adds a tiny cost to that.

What it taught me about design systems

Three lessons I'm confident about:

A design system isn't a component library. It's a list of decisions you refuse to remake. The components are just where the decisions live.
Fewer options means faster shipping. Three colours and three fonts removed more work than any plugin could.
Write the rules in a sentence. "Everything should feel printed" settled arguments I hadn't even had yet.

If you're building your own system, start with the sentence, not the Figma file.

Build a mini "Press" system in 15 minutes

Here's a tiny version you can paste into a page to feel the approach. The colour values are examples for this demo, so choose your own.

:root {
  --paper:    #f4efe6;
  --ink:      #1c1c1c;
  --oxblood:  #7a1f1f;
}

body {
  background: var(--paper);
  color: var(--ink);
  font-family: 'Newsreader', Georgia, serif;
  line-height: 1.6;
}

h1, h2 { font-family: 'Archivo', system-ui, sans-serif; letter-spacing: -0.02em; }

.label { font-family: 'Space Mono', monospace; font-size: .8rem; color: var(--oxblood); text-transform: uppercase; }

.card  { border: 2px solid var(--ink); box-shadow: 4px 4px 0 var(--ink); padding: 1rem; background: var(--paper); }

.rule  { border: 0; border-top: 3px double var(--ink); }

<p class="label">Front page</p>
<h1>Local developer ships honest portfolio</h1>
<hr class="rule" />
<div class="card"><h2>Project</h2><p>A one-paragraph story.</p></div>

That's about all the "style" it takes: three colours, three fonts, a hard shadow and a double rule.

Check your contrast

A muted palette needs a deliberate accessibility check. WCAG asks for a contrast ratio of at least 4.5:1 for normal body text. For the example colours above:

Pair	Contrast ratio	Passes body-text minimum?
Ink on paper	about 14.9 : 1	Yes
Oxblood on paper	about 9.0 : 1	Yes
Mid-grey (#8a8a8a) on paper	about 3.0 : 1	No

The last row is the classic trap: a soft grey that looks elegant but fails. You can calculate the ratio yourself from relative luminance, or use any browser dev-tools contrast checker.

A design-system starter checklist

[ ] A one-sentence principle ("everything should feel printed")
[ ] 3–5 colour tokens, named by role, not by hue
[ ] Fonts with one job each
[ ] A spacing scale (4, 8, 16, 24, 32…)
[ ] 4–6 primitive components
[ ] A motion rule ("animation must explain something")
[ ] A contrast check on every colour pair
[ ] A mobile layout

Common questions

"Won't a strict theme limit me?" Yes, deliberately. The limit is the feature.

"How do I pick the principle?" Look at something physical whose feel you admire (paper, signage, a machine) and describe it in one sentence.

"How many tokens is too many?" If you can't remember them, there are too many.

"Dark mode?" A themed system needs a second palette designed, not just inverted. For a print theme, a dark variant can be "newsprint at night", muted rather than neon.

If you want to see it in action, the site is at surajnandan.in. What's the single sentence that defines your design taste?

How I use AI coding tools without letting them think for me

SURAJ NANDAN — Thu, 22 Oct 2026 03:30:00 +0000

I use AI tools a lot. I'm not going to pretend otherwise. My Whiteboard.ai project, for example, was built with Claude Code under written engineering rules and a plan-then-approve loop, and that's stated plainly in its case study.

But I've had to set rules for myself, because I noticed a specific failure mode: I can ship something I don't understand. That's the real risk of AI tools, and it isn't about quality of output. It's about what happens to me if the tool does all the thinking.

Here are the rules, where AI helps, where it quietly hurts, and one lesson from a different angle: building products on top of models.

The failure mode

Without AI, if I don't understand something, I can't write it. The gap between "I need this" and "I have this" forces learning.

With AI, that gap can vanish. The tool writes the code; it compiles; it passes a quick manual check; I move on. The code is in my repo, but the understanding isn't in my head. Weeks later something breaks and I'm debugging code that's effectively someone else's, in a codebase I'm supposed to own.

So I set rules.

My rules

1. Explain it back

If I can't explain a block of generated code in my own words, I don't commit it. "It works" isn't enough. I need to be able to say why it works and what would break it.

2. I choose the architecture

The assistant fills in; it doesn't decide where logic lives. The decision to put CardBridge's rules in Postgres (Day 2) was mine, with reasons I could defend. That's the kind of decision I don't hand over, because the consequences last the whole life of the project.

3. Read the diff. Always.

Generated changes can touch files I didn't expect. Reading the diff before accepting is the cheapest quality control there is. If a change surprises me, that's a signal to stop and ask why.

4. Verify in the running app

"It compiles" isn't "it works". Type checks and unit tests are necessary, not sufficient. For anything user-facing, I run the actual app and use the feature.

5. Write the rules down

For Whiteboard.ai, I wrote engineering rules in a file and had the assistant plan first, with me approving the plan before code. A written rule survives a long session in a way that a mental intention doesn't.

Where AI genuinely helps me

Boilerplate and repetitive refactors. Renaming across forty files, adapting a pattern to a new case.
Rubber-ducking a bug when nobody's awake to ask. Explaining the problem clearly is half the fix, and a responsive duck helps.
Unfamiliar APIs, where I need a starting example to adapt rather than a blank page.
Test scaffolding, once I know what to test.

Where it quietly hurts

It makes the first draft so easy that I skip the thinking. The first design is rarely the best one. When drafting is free, it's tempting to stop at draft one.
Confident wrong answers. A fluent explanation isn't evidence that it's right. I've learned to treat fluency as zero information about correctness.
Silent scope creep. Assistants happily "improve" things you didn't ask about.

A lesson from building on top of models

AI coding tools are one side. The other is building products that call models. My Knot.ai project, a spoken interview-practice app, taught me something I now think of as a rule of thumb:

Instruction is not control.

In early testing, I handed the whole interview to an LLM and asked it nicely to follow rules: adjust difficulty by one level, cover three topic areas. Against a simulated candidate, the interviewer model tunnel-visioned on one topic and escalated difficulty freely. It ignored "adjust by one level" and "cover three areas" the moment they competed with its own instincts.

The fix was to split the job. The model does what only a model can: understand an answer, judge it, phrase the next question. Everything countable became a state machine on the server: difficulty is a streak-based ladder clamped to 1–5, topic coverage rotates on a counter. The model supplies judgement and phrasing; the server decides what happens.

That's the same principle as my AI-tool rules, from the opposite direction. Don't rely on a prompt to enforce what code can enforce. And don't rely on an assistant to enforce good judgement that only you can supply.

The test I use

Before I commit anything an AI wrote, I ask:

Could I rebuild this from scratch if the tool vanished tomorrow?

If yes, I'm using it as a power tool. If no, I'm renting understanding, and the rent comes due at the worst time.

What I'm still figuring out

I don't have this solved. A few open questions I wrestle with:

How much unfamiliar code is "okay to accept" while I'm learning versus building something to ship?
When does reviewing a diff become a rubber stamp because I'm tired?
How do I keep my own coding muscles in shape when the tool is always there?

If you have answers, I genuinely want them.

A review checklist for AI-generated changes

Run through this before accepting a diff.

Scope. Does it touch only files related to the request?
Surprises. Anything deleted, renamed or reformatted that I didn't ask for?
Understanding. Can I explain each hunk aloud?
Edge cases. What happens on empty input, errors, concurrency?
Security. Any secrets, unsafe string-building, permissive access?
Dependencies. Did it add a package? Is it needed and trustworthy?
Tests. Does a test fail without this change and pass with it?
Running app. Did I actually use the feature?

Prompts that help me understand, not just copy

How you ask changes what you learn.

"Explain this function line by line as if I'm a second-year student."
"What are three ways this could fail in production?"
"Give me two alternative designs and the trade-offs of each. Don't pick one."
"What would you check before trusting this?"
"Write the failing test first, then the minimal fix."

Notice the pattern: these ask the tool to expose reasoning, which keeps me in the loop.

A before/after example

Weak request: "Add rate limiting to my API."

Better request: "I have a Vercel function at api/chat.ts. I want to limit each IP to 20 requests per minute. List two approaches that fit a serverless host, explain the trade-offs, and wait for me to choose before writing code."

The second one keeps the architecture decision with me and gives me something to learn from.

The plan-then-approve loop

For bigger tasks, I use a loop with written rules:

State the goal and constraints.
The assistant proposes a plan, with no code yet.
I read it, push back, and approve or change it.
It implements one step at a time.
I review each diff before moving on.

Written engineering rules (naming, testing, "don't change files outside the plan") make the loop reliable, because rules written once apply to the whole session.

A mini-exercise

Pick a function you wrote with AI help last month. Without looking at the code, write down what it does, what inputs it can't handle and how you'd test it. Then compare with the code. The gaps you find are exactly the "understanding debt" this post is about.

Signs I'm over-relying on it

I accept changes without opening the files.
I can't remember how a feature I "built" works.
I ask the tool what to build, not how to build it.
Debugging starts with pasting the error rather than reading it.

If two or more are true, I slow down for a few days and write something from scratch.

How do you draw the line between using AI as a tool and letting it replace understanding?

I tried to figure out how a student earns online. Here's what I ruled out and why

SURAJ NANDAN — Wed, 21 Oct 2026 03:30:00 +0000

I'm a student and I'd like income from skills I already have. Not a get-rich-quick plan, just something real that helps cover costs and might grow.

I went through the usual list. This post is my reasoning, written out honestly, including the parts that aren't finished. It's not advice, it's a worked example of how I weighed things. Your answers could be completely different.

The constraints I'm working with

Before the options, the limits:

I'm mid-degree. I graduate in 2027, so full-time work isn't realistic yet.
Time is the scarce resource. Classes, projects and life already fill the week.
I'd rather build something once than sell hours repeatedly.
Starting capital is close to zero.

Any option has to fit inside those four lines.

The options I weighed

1. Teaching or tutoring

For: Real value to people, and teaching deepens your own understanding.
Against: It trades hours for money directly. I'm also still learning myself, and I don't want to sell certainty I don't have yet.
Verdict: Good later, not now.

2. Job hunting

For: It's the best long-term path to steady income and learning from experienced engineers.
Against: I'm mid-degree, so most roles aren't a fit yet, and a lot of effort goes into applications.
Verdict: The right move eventually. I'm building evidence for it (this series is part of that).

3. Fiverr

For: A marketplace with built-in demand.
Against: It's competitive, and a new profile has no reviews. I set up gigs only recently, so it's genuinely too early to judge.
Verdict: Running quietly in the background. I'm not counting on it.

4. Content creation

For: Compounds over time and builds an audience.
Against: It takes a long time before it pays, if it ever does, and it competes for the same hours as building.
Verdict: I'm writing this series anyway, but for learning and visibility, not as an income plan.

5. Selling a template

For: The work already exists. I'd built a design system, The Press, for my own portfolio. Packaging it as a template costs far less than starting from scratch, and it's something other students need: a portfolio that doesn't look like everyone else's.
Against: Digital product sales are uncertain, and a template needs support and polish.
Verdict: The best fit for my constraints.

The deciding factor

The deciding factor wasn't "this will make money." I don't know that. It was this question:

What do I already have that other people need, which I can offer without spending months building something new?

That question filters hard. Most "side hustle" ideas fail it because they require learning a new skill, finding customers and doing the work. The template only required packaging.

What I actually did

I built a separate copy of the portfolio as a template, kept the live site untouched, and priced it low at $19. Low enough that the decision to buy is easy, high enough that it isn't a giveaway. I'm treating the outcome as an experiment. If it sells, I'll learn something about what people want; if it doesn't, I'll learn that too, and the cost was mostly time I'd have spent anyway.

I'll write about the packaging work itself on Day 27, because it was more unglamorous than I expected.

What I haven't solved

Here's the honest status: my Gumroad listing is drafted but not published, because payouts need bank details that I haven't connected yet. So as of today:

The template is built. ✅
Screenshots and listing copy are ready. ✅
The listing is not live. ❌

That's the real state of things: built, not shipped. A lot of projects die in exactly that gap, so I'm naming it publicly to make it harder to ignore.

A simple decision framework you can reuse

If you're choosing, try this table. Score each option from 1 to 5 on each column, then compare totals.

Option	Uses what I already have	Fits my free hours	Doesn't trade time 1:1	Low upfront cost
Option A
Option B

The point isn't the numbers. It's that writing the criteria down stops you from choosing the option that merely sounds exciting.

Takeaway

Picking by "what already exists that I can offer" beats picking by "what's trending." If you've been stuck choosing, list what you've already built first. You may be closer than you think.

How I think about pricing a first product

I don't have sales data, so I won't pretend to. What I can share is the reasoning that led me to a low price.

Anchor on the buyer's alternative. What would a student do otherwise? Build their own (days of work) or use a generic template.
A low price lowers the decision cost. If it's cheaper than a lunch, buying doesn't need deliberation.
Price is also a signal. Too low can suggest low quality; a clear, specific listing offsets that.
You can raise it later. You can't easily un-raise it.

I priced it at $19 and consider it an experiment. If you sell something, decide in advance what result would make you change the price, so you aren't tempted to react to one data point.

A one-evening validation test

Before building anything big, try to learn whether anyone wants it:

Write the listing page text first: who it's for, what's included, what isn't.
Show it to five people who fit the audience. Ask: "Would you pay for this? What's missing?"
Count how many ask when they can get it, not whether it's nice.
If fewer than a couple lean in, rethink before building.

It's not statistically rigorous. It's cheap, and it catches the worst surprises.

Mistakes to avoid

Setting up payouts last. My listing is blocked on exactly that. Set up payments and identity verification first, since they can take days.
Building for an imaginary buyer. Name a real person who'd use it.
Counting hours as value. Buyers pay for outcomes, not effort.
Promising support you can't give. State what's included.
Skipping the licence. Be explicit about what buyers may and may not do.

A comparison of the five options

Option	Upfront effort	Ongoing effort	Income ceiling	Fit right now
Tutoring	Low	High (hours)	Limited by hours	Later
Job	High (search)	Full time	High	After graduation
Fiverr	Medium	Medium	Medium	Running quietly
Content	Low	High	Uncertain	Doing for learning
Template	Medium (done)	Low	Uncertain	Best fit

A caution about "passive income"

Be wary of anything marketed as effortless. A product still needs a listing, an audience, support and updates. "Passive" usually means "the effort comes in a different shape". I'd rather describe it as leveraged effort: work done once that can be sold more than once.

What did you try first, and did it work? If you've sold a digital product, I'd love to hear what surprised you.

My site's deploys silently failed for two weeks. I didn't notice

SURAJ NANDAN — Tue, 20 Oct 2026 03:30:00 +0000

This one is embarrassing, which is exactly why it's worth writing.

My portfolio is hosted on Vercel. For roughly two weeks, from about September 10 to September 24, every deploy failed, and the live site just kept serving an older version. I kept pushing changes. I kept wondering why nothing showed up. The site looked fine, because the old site looked fine.

Here's the full post-mortem: what broke, why I didn't notice, how I fixed it, and the one rule I took away.

What a "silent" failure looks like

Nothing screamed at me. My local build passed. My git push succeeded. The live URL loaded without errors. The only thing wrong was that none of my newer commits were live, and that's a hard thing to notice when you're the only person looking at the site and you're not comparing versions.

That's the nasty thing about a frozen deploy: the failure mode looks exactly like success until you specifically check.

The root cause

My build runs a prerender step after the main build. It uses Puppeteer to render pages to static HTML so they're quick to load and easy for crawlers to read. On my laptop, Puppeteer downloads a copy of Chrome when you install it.

On Vercel, npm enforces an allow-scripts policy: dependency postinstall scripts are skipped unless explicitly allowed. Puppeteer's Chrome download is a postinstall script. So on Vercel:

npm install ran, but skipped the Chrome download.
The prerender step tried to launch a browser that didn't exist.
It crashed.
The crash returned a non-zero exit code.
A non-zero exit code from the build command failed the entire deploy.

So a nice-to-have optimization step was able to block the thing that actually matters: shipping.

The fix, in two parts

Part 1: a browser that works on Vercel. On Linux (which is what Vercel runs), the prerender script falls back to @sparticuz/chromium, a build of Chromium made for serverless environments.

Part 2: never let the optimisation break the build. If no browser launches at all, the script now skips prerendering and exits 0. The deploy ships; the pages just aren't pre-rendered.

In pseudo-code the shape is:

// scripts/prerender.mjs (simplified)
async function main() {
  let browser;
  try {
    browser = await launchBrowser();   // tries puppeteer, then @sparticuz/chromium
  } catch (err) {
    console.warn('No browser available, skipping prerender:', err.message);
    process.exit(0);                   // IMPORTANT: do not fail the deploy
  }
  // ...render pages...
}

The rule I wrote at the top of that file afterwards: a post-build nicety must never be able to block a deploy.

Why I didn't notice for two weeks

Being honest about my own process:

I treated a successful git push as proof the site was updated. It isn't. A push proves the code reached GitHub, nothing more.
I didn't look at the deployment dashboard, which would have shown a red "Failed" next to every recent commit.
I had no automated check comparing "what I think is live" with "what is live".

None of these are clever failures. They're habit failures. The bug was small; the blind spot was mine.

What I do now

After a deploy, I verify the live site directly instead of trusting the pipeline. A few quick checks with curl against the production domain:

# 1. Is the chat API alive? (returns ready: true)
curl -s https://www.surajnandan.in/api/chat

# 2. Is the RSS feed being served?
curl -sI https://www.surajnandan.in/rss.xml | head -n 1

# 3. Are generated social images being served?
curl -sI https://www.surajnandan.in/og/blog/<slug>.png | head -n 1

None of these take more than a few seconds, and between them they confirm that the new build is serving, not the old one.

A checklist you can steal

If you deploy anything to a hosted platform, ask these questions:

Which of my build steps are essential and which are optional? Optional steps should fail soft.
Does my build rely on a postinstall script? Hosted platforms may skip them. Check the install logs.
How do I know a deploy actually went out? Have an answer that isn't "the push worked."
Do I get notified when a deploy fails? If not, turn it on today. Email or Slack, anything.
Does the live site expose a version? Even a build timestamp in the footer lets you spot a frozen deploy at a glance.

The honest lesson

The bug wasn't clever. The failure was that I trusted a green git push as proof of a live site, and I didn't build a habit of checking.

Two weeks is a long time for a site to quietly freeze. It happened to a portfolio, where the cost was a few unseen updates. If the same blind spot existed on something a business depended on, the cost would be much higher. I'd rather learn this lesson on my own site.

Reproduce the failure on your machine

You can simulate the Vercel environment locally. The key is to install dependencies without running postinstall scripts:

rm -rf node_modules
npm ci --ignore-scripts      # skips scripts like Puppeteer's Chrome download
npm run build                # watch the prerender step fail
echo "exit code: $?"

If your build prints a non-zero exit code here, a hosted platform would have failed the deploy for the same reason. Fix it, re-run the same three commands, and confirm exit code: 0.

A rough timeline

When	What I believed	What was true
About Sep 10	"Deploys are working"	Builds had started failing
Sep 10 to 24	"My changes are live"	The live site was frozen on an older build
About Sep 24	n/a	The fallback and fail-soft rule landed, and deploys resumed

The questions I asked afterwards

A post-mortem is only useful if it produces better questions. These are the ones I now ask about any pipeline:

What's the cheapest signal that would have told me this broke? A deploy-failed email would have cost nothing.
Which steps are essential, which are cosmetic? Mark them in the script.
What's different between my machine and the host? Node version, installed browsers, environment variables, install policies, filesystem permissions.
If this step fails, what's the safe default? For prerendering, the safe default is "ship without it".

Turn on failure notifications today

Most hosts can notify you on a failed deploy. It takes a minute, and it removes the need to remember to check. Look for deployment notification settings in your project dashboard and route them to email or chat.

A tiny fail-soft pattern for any optional step

# in package.json scripts
"build": "vite build && npm run postbuild || echo 'postbuild failed (non-fatal)'"

The || means the build still exits 0 if the optional step fails, while printing a clear warning. Use it only for steps that are genuinely optional, and make sure the warning is visible in logs.

What this taught me about "green" signals

A green tick answers one narrow question: "did this command succeed?" It does not answer "is the thing I care about true?" The more important the outcome, the more it deserves a direct check of the outcome itself (the live site) instead of an indirect signal (the pipeline).

What's the dumbest reason a deploy has failed for you? Mine is above. Tell me yours in the comments.

I put my business rules in the database instead of React, here's what it bought me

SURAJ NANDAN — Mon, 19 Oct 2026 03:30:00 +0000

When I built CardBridge, the scary question was simple: what stops a user from skipping a step in the escrow flow?

If the rules live in React, the honest answer is "nothing, if they open the network tab." Anyone can call your API directly. Anyone can replay a request. The frontend is a suggestion, not a guard.

This post is about the decision that shaped the whole project: moving the rules into Postgres. Here's how it works, what it bought me, and what it cost.

The problem CardBridge solves

You find a great discount on something, but it only applies to a card you don't own. Someone else owns that card and would buy it for you for a small fee. The idea is easy. The hard part is trust:

The requester needs to know the product will actually arrive.
The cardholder needs to know they'll be paid.
The platform needs an auditable record of every step.

That makes it a trust problem far more than a UI problem. And trust problems are exactly where "the frontend checks it" falls apart.

The decision: the database is the referee

A transaction moves through these states:

MATCHED → FUNDED → PURCHASED → SHIPPED → DELIVERED → RELEASED

plus three exits: CANCELLED, DISPUTED and REFUNDED.

Instead of letting the client update a status column, every change goes through one function, transition_transaction. A BEFORE UPDATE trigger validates the change against three things: a map of legal transitions, the caller's role, and the transaction's invariants. If anything is off, Postgres refuses.

Here's the idea in simplified form. This is a sketch, not the production schema:

-- Which (from -> to) moves are legal, and who may make them
create table legal_transitions (
  from_status text,
  to_status   text,
  allowed_role text,
  primary key (from_status, to_status, allowed_role)
);

create function guard_transition() returns trigger as $$
begin
  if old.status = new.status then
    return new;                      -- not a status change
  end if;

  if not exists (
    select 1 from legal_transitions
    where from_status = old.status
      and to_status   = new.status
      and allowed_role = current_caller_role(new)
  ) then
    raise exception 'illegal transition % -> % for this caller',
      old.status, new.status;
  end if;

  return new;
end $$ language plpgsql;

create trigger transactions_guard
before update on transactions
for each row execute function guard_transition();

An AFTER UPDATE trigger then does the bookkeeping: it writes an immutable event log row for the transition, keeps the original request's status in sync, and credits the user's tier.

The result: a buggy or malicious client simply cannot skip a step. It's not that the client is asked not to. The database says no.

Row Level Security on every table

The second half of the story is access control. Only Supabase's public anon key ships to the browser. That key is not a secret, so safety can't come from hiding it. It has to come from Row Level Security (RLS) on every table, so each user can only read and change the transactions they're part of.

A few extra guards sit on top:

A trigger stops people from promoting their own profile privileges.
Public-safe views expose only what the browse feed needs.
Matching has database-level guards: you can't accept your own request, and the escrow amount is computed on insert instead of trusted from the client.

That last one matters. If the client sends the amount, the client controls the amount. If the database computes it, nobody can lie about it.

Timeouts on two clocks

Abandoned transactions shouldn't sit in limbo forever. A configurable timeout policy runs in two places: when a transaction page loads, and on a scheduled Edge Function (escrow-timeout-sweep). Disputed transactions are skipped by every automatic action, so a dispute genuinely freezes escrow.

What it bought me

The frontend can be wrong and nothing breaks. I can ship a UI bug without shipping a money bug.
Every state change is auditable. The event log is written by a trigger, not by code someone has to remember to call.
I stopped worrying about "what if someone calls the API directly". They can. The database still decides.

What it cost

I want to be as honest about the costs as the benefits.

Debugging triggers is slower than debugging a function in the same language as the rest of the app. There's no breakpoint to set; there's an error string to interpret.
Postgres has sharp edges. You can't use a new enum value in the same transaction that adds it. So adding MATCHED and SHIPPED needed its own migration that has to commit before the state machine's migration runs.
RLS policies can recurse. The SELECT and UPDATE policies on requests and transactions referenced each other and looped. I broke the cycle with SECURITY DEFINER helper functions. (More on RLS in a later post.)
The whole thing ended up as fourteen ordered migrations, including the fixes. Versioned SQL is good discipline, but it's also more ceremony than editing a file.
There is no automated test suite yet. I'll come back to this on Day 20 with a concrete plan, because it's the biggest gap in the project.

A note on what's real

To be clear about the prototype: the escrow and KYC providers are stubbed. The lifecycle, the limits and the state machine are real; the money and identity checks don't touch a live payment or identity provider yet. I'd rather say that here than let the word "escrow" imply more than it does.

My takeaway

Put rules where they can't be bypassed. Put presentation where it's cheap to change.

That sounds obvious written down, but it took building a project where money moves for me to feel it. The frontend is for the user's convenience. The database is for everybody's protection.

Try it yourself: a 20-minute version

You don't need my whole project to feel the idea. Here's a tiny, runnable version with orders instead of escrow. Paste it into any Postgres database.

create table orders (
  id     serial primary key,
  status text not null default 'PENDING'
);

-- The only legal moves
create table legal_moves (from_status text, to_status text, primary key (from_status, to_status));
insert into legal_moves values
  ('PENDING','PAID'), ('PAID','SHIPPED'), ('SHIPPED','DELIVERED');

create function guard_order() returns trigger as $
begin
  if new.status is distinct from old.status
     and not exists (select 1 from legal_moves
                     where from_status = old.status and to_status = new.status) then
    raise exception 'illegal move % -> %', old.status, new.status;
  end if;
  return new;
end $ language plpgsql;

create trigger orders_guard before update on orders
for each row execute function guard_order();

insert into orders default values;                 -- PENDING
update orders set status = 'PAID' where id = 1;    -- ok
update orders set status = 'DELIVERED' where id = 1;  -- ERROR: illegal move PAID -> DELIVERED

Run the last line and watch the database refuse. That refusal is the whole idea. Now imagine that every client, in every language, in every future version of your app, hits the same wall.

Exercises

Add a CANCELLED state reachable from PENDING and PAID only.
Add an order_events table and an AFTER UPDATE trigger that logs every change.
Make order_events append-only by revoking UPDATE and DELETE on it.
Add a role check: only an admin may move an order to CANCELLED after PAID.

When not to put logic in the database

I don't want to oversell this. It isn't always the right call.

Rules that change weekly. Business rules that product teams tweak constantly are painful to ship as migrations.
Heavy computation. The database is a shared, scarce resource. Don't make it do work an app server can.
Teams without SQL skill. If nobody can read the triggers, nobody can maintain them.
Logic that needs outside calls. Calling payment providers or email services from inside a trigger is a recipe for pain.
Prototypes you'll throw away. The ceremony costs more than it saves.

A good compromise: put the invariants (things that must never be violated) in the database, and keep the policies (things that may change) in application code.

Questions I get asked

"Isn't that vendor lock-in?" Triggers and RLS are standard PostgreSQL, not a vendor feature. Supabase makes them convenient, but the logic would move with the database.

"How do you version it?" As ordered migrations. CardBridge's schema is fourteen of them, including the fixes, so the database can be rebuilt from scratch.

"What about the UX when Postgres rejects something?" Catch the error in the RPC layer and translate it into a friendly message. The database refuses; the frontend explains.

Have you moved logic into the database before? Did you regret it, or would you do it again? I'd especially like to hear from anyone who's tested trigger-based logic well, because that's my next problem.

I'm a B.Tech student in a small Indian city, and I'm going to write honestly for 30 days

SURAJ NANDAN — Sun, 18 Oct 2026 03:30:00 +0000

Most developer blogs I read sound like their authors have it all figured out. I don't, so I'm not going to write like that.

This is Day 1 of a 30-day series. One post a day, every day, for the next month. Before the first technical post lands tomorrow, I owe you an introduction, a list of the rules I'm holding myself to, and a map of where this is going.

Who I am

I'm Suraj. I live in Kishanganj, India, and I'm studying B.Tech in Computer Science at SRM (2023–2027). I build full-stack and AI projects, mostly on my own, sometimes in a team. Here's what's actually in my portfolio right now, with no rounding up:

CardBridge, a card-discount marketplace where the escrow rules live inside Postgres instead of the frontend. Built solo over about two months.
Whiteboard.ai, a real-time collaborative system-design whiteboard where an AI reviews your architecture diagram. It runs locally against a dev database. It is not deployed, and I'll say that every time it comes up.
Knot.ai, a spoken interview-practice app with five AI interviewer personas, built for a hackathon.
Hospitality.ai, an insurance-aware care navigator, built for a healthcare challenge.
Job Scheduler, a distributed background-job platform built on Postgres alone.
GigShield, parametric income insurance for delivery riders. This one was a team of three, so the credit is shared, and I'll name my teammates when I write about it.
This portfolio, which looks like a newspaper (The Nandan Review) and has its own design system.

That list looks impressive written down. Reading it back, I notice it doesn't say how many times each project broke, how many decisions I'd reverse, or which ones have no tests. That's the part I want to write about.

Why 30 days of this

Three honest reasons.

1. Writing exposes what I only half-understand. I can build a Postgres state machine, but explaining why it beats checks in the frontend, in plain words, forces a clarity that building alone doesn't.

2. A public record of how I think is a better résumé than a list of buzzwords. Anyone can write "Postgres, React, Node" on a page. Fewer people can show a decision, the alternatives they rejected, and the thing that went wrong.

3. I'd like to meet other people who write in public. Wherever you are, if you're learning in the open too, I'd like to read your work.

The rules I'm setting for myself

I'm writing these down on Day 1 so you can hold me to them on Day 30.

Only write what I actually did or actually believe. No invented metrics. No "I 10x'd my productivity" claims. If a number appears in a post, it comes from something I can point to in a repo.
Say what didn't work. My case studies each end with a "limits" section. Whiteboard.ai's AI review eval is written but has never been run against a real API key, so its catch rate is unmeasured. I'd rather you read that sentence from me than discover it yourself.
Keep every post readable in one sitting. Most will take somewhere between 4 and 9 minutes.
Credit teammates. Team projects will say so, with names.
Opinions are labelled as opinions. When I'm giving advice rather than reporting what I did, I'll say so.

What's coming

Here's the rough shape of the month, so you know what you're signing up for.

Weeks 1–2: the building side. Putting business rules in the database. The deploy that silently failed for two weeks. How I decide between a rewrite and a refactor. What a design system actually is.

Weeks 2–3: AI and systems. How a RAG helpdesk answers only from documents. How I use AI coding tools without outsourcing my thinking. What went wrong building Whiteboard.ai and Knot.ai. Six data structures I implemented by hand for a job scheduler.

Weeks 3–4: the human side. Money, motivation, impostor syndrome, writing, reading other people's code, and what I'm honestly not good at yet.

Not every post will be a tutorial. Some will be about decisions, some about doubt. If you only want code, you'll find plenty. If you want to know what a student actually thinks halfway through a CS degree, there's some of that too.

A small ask

If you're a student or early developer working from somewhere that isn't a tech hub, say hi in the comments. Tell me one thing you're stuck on this week. It can be technical ("my RLS policy returns nothing") or not ("I don't know what to build next"). I'll read every comment, and the best questions will turn into posts later in the series.

A small glossary for the series

Some terms will come up repeatedly. If any are new, here's the plain-English version.

State machine: a model where something can be in exactly one state at a time (say, FUNDED), with a fixed list of allowed moves between states.
Row Level Security (RLS): a database feature where the database itself decides which rows a given user can read or change.
RAG (Retrieval-Augmented Generation): give an AI model the relevant pieces of your own documents at question time, so it answers from them instead of from memory.
Embedding: a list of numbers that represents the meaning of a piece of text, so similar meanings sit close together.
Parametric insurance: cover that pays automatically when a measurable event (like heavy rain) crosses a threshold, with no claim to argue over.
Idempotent: safe to run twice. Doing it again has the same effect as doing it once.
Write-ahead log (WAL): write the change to durable storage first, then treat it as done.
Serverless function: a small piece of code the host runs on demand, so you don't manage a server.

How to follow along

You don't have to read in order. Each post stands alone, and later posts link back to earlier ones where it helps. A few ways to use the series:

Binge it in a weekend using the reading map on Day 29.
Pick by interest: database and security (Days 2, 17, 20), AI (Days 5, 11, 12), career and mindset (Days 4, 9, 14, 26).
Skim the takeaways card at the end of each post first, then decide whether to read the whole thing.

What I'd love your help with

I'm learning in public, which means I'll get things wrong. The most useful comments are:

Corrections. If a claim is off, tell me and I'll fix the post and note what changed.
Counter-examples. "That didn't work for me because…" is gold.
Questions. If something wasn't clear, it's my writing's fault, not yours.

Also, a quick disclosure about how these were made: the posts are written from my own project notes and case studies, and I use AI tools in my workflow (more on that on Day 5). Every technical claim is something I can point to in a repository.

Tomorrow: why I put my escrow rules in the database instead of in React, and what it cost me.

See you then.

How I built a live halftone portrait in React with just Canvas 2D

SURAJ NANDAN — Sat, 17 Oct 2026 04:12:03 +0000

My portfolio is set like a newspaper, so my photo couldn't just be a photo. I wanted it to look like a printed halftone: a grid of dots, bigger where the picture is dark and smaller where it's light. And I wanted it to be alive, so the dots swell and get pushed away when you move the cursor over them.

It turned out to be about 150 lines of React and plain Canvas 2D, with no dependencies. Here's how it works.

Step 1: turn the image into a grid of samples

A halftone is just a low-resolution version of the picture drawn with dots. So the first job is to shrink the image to roughly one pixel per dot and read the pixels back.

I draw the image onto a tiny offscreen canvas (84 columns wide by default, with the rows worked out from the aspect ratio), and then call getImageData:

const cols = columns;
const rows = Math.max(1, Math.round(cols * (height / width)));

const off = document.createElement('canvas');
off.width = cols;
off.height = rows;
const octx = off.getContext('2d', { willReadFrequently: true });

// cover-fit the image into the sample grid
const scale = Math.max(cols / image.width, rows / image.height);
octx.drawImage(image, (cols - image.width * scale) / 2, (rows - image.height * scale) / 2,
               image.width * scale, image.height * scale);

const data = octx.getImageData(0, 0, cols, rows).data;

Letting the browser do the downscaling is the trick: drawImage averages the source pixels for me, so each sample is already the average colour of its patch of the photo.

For every pixel I store its position (normalised 0 to 1), its colour, and its darkness, which I get from luminance:

const lum = (0.2126 * r + 0.7152 * g + 0.0722 * b) / 255;
samples.push({ nx: (x + 0.5) / cols, ny: (y + 0.5) / rows, darkness: 1 - lum, color: `rgb(${r},${g},${b})` });

I only build this once per resize, not every frame.

Step 2: draw a dot per sample

Each frame I clear the canvas and draw one circle per sample. The radius is what makes it look like a halftone: darker samples get a bigger dot.

const cell = width / columns;
let r = Math.pow(s.darkness, 0.85) * cell * 0.62;

The 0.85 exponent is a small tone curve. Without it the midtones came out too light. cell * 0.62 stops neighbouring dots from touching in the darkest areas.

To make the portrait fade into the page instead of ending in a hard rectangle, I multiply the radius by an elliptical vignette and use smoothstep so the edge falls off gently:

const smoothstep = (t: number) => t * t * (3 - 2 * t);
const mask = smoothstep(Math.min(1, Math.max(0, (1 - eDist) / 0.42)));

Here eDist is the sample's distance from the centre of an ellipse, where 1 is the edge.

Step 3: make it breathe

Even with no cursor I wanted a little life in it. A tiny sine wave, offset by each dot's position, nudges the radius by about 5%, so it ripples slowly:

r *= 1 + 0.05 * Math.sin(t + s.nx * 7 + s.ny * 9);

Step 4: react to the cursor

This is the part people notice. I keep a target position for the pointer and ease the "real" position toward it, so the effect trails the cursor with a bit of weight:

mouse.x += (mouse.tx - mouse.x) * 0.14;
mouse.y += (mouse.ty - mouse.y) * 0.14;

For each dot inside an influence radius, two things happen: the dot grows, and it gets pushed away from the cursor, both scaled by a smooth falloff:

if (d < influenceRadius) {
  const f = smoothstep(1 - d / influenceRadius);
  r *= 1 + 1.05 * f;                     // swell
  const push = (f * cell * 1.4) / d;     // shove away from the cursor
  ox = dx * push;
  oy = dy * push;
}

Using smoothstep rather than a linear falloff is what makes it feel like ink spreading rather than a hard circle.

Making it behave

A canvas animation that runs forever is rude. Three small guards keep this one polite:

Pause when off-screen. An IntersectionObserver stops the animation loop when the canvas isn't visible and restarts it when it is.
Respect reduced motion. If prefers-reduced-motion is set, it draws a single static frame and never starts the loop.
Cap the pixel ratio. devicePixelRatio is clamped to 2, so very dense screens don't draw four times the pixels for no visible gain.

I also resize with a ResizeObserver and rebuild the samples then, and I decode the image with img.decode() before drawing so there's no half-loaded flash.

Finally, the canvas is aria-hidden, since it's decoration. The page's real heading carries the meaning.

What I'd improve

It draws one arc per dot. For about 7,000 dots that's fine, but a much denser grid would be better as a single batched path or a WebGL shader. I draw dots individually because each one has its own colour.
Large photos cost something at load. The sampling step reads back image data once, which is quick for a small grid, but it's worth resizing the source photo to something sensible first.

Want the whole thing?

The halftone portrait is one part of a bigger project: a newspaper-style portfolio with a typewriter intro, a command palette, case studies and a blog. I turned it into a template, with a live demo you can poke at:

Demo: https://newspaper-template-zeta.vercel.app
Template (paid): https://surajnandan.gumroad.com/l/press-portfolio

The halftone component above is self-contained, so you're welcome to copy the ideas straight into your own project.

Building GigShield: Instant Protection for Gig Workers with a First Risk Engine

SURAJ NANDAN — Fri, 03 Apr 2026 12:15:06 +0000

Gig workers lose income for reasons they cannot control: heavy rain, platform outages, curfews, poor air quality, and local disruptions. Most traditional claim systems are slow, manual, and stressful at the exact moment people need help.

I built GigShield to explore a different approach: parametric protection that can trigger payouts automatically when predefined external conditions are met, with fraud controls and verification built into the flow.

The product idea

GigShield is designed around one simple promise: if covered disruption conditions happen, workers should know quickly whether they are eligible and how much they will receive.

The app includes:

Tiered weekly plans with clear coverage limits
Trigger-based payout logic (weather, platform, and social disruptions)
A transparent decision flow with explicit reason codes
Fraud checks before settlement for risky claims
A full payout lifecycle from event detection to receipt

Why this was interesting to build

Most demos stop at UI. I wanted this one to model real decision mechanics:

Policy domains and exclusions
Coverage-hour checks
Daily caps by plan
Trigger confidence and cooldown windows
Verification gates for high-risk claims

This made the project less like a landing page and more like a small rules-driven system.

Architecture in practice

The stack is React + Vite + Tailwind, with utility modules that isolate policy, payout, fraud, observability, and integrations concerns. Routes are separated by persona and workflow: onboarding, dashboard, payout, history, fraud explainability, and admin operations.

A key design choice was frontend-first state with local persistence. That made iteration fast and let me simulate full flows end-to-end without waiting on backend dependencies. Supabase auth and schema scaffolding are present, but most operational logic currently runs client-side for demo velocity.

Trade-off: speed of development vs tamper resistance and production-grade trust boundaries.

Fraud and trust layer

The most important part was preventing blind auto-payouts. GigShield includes several controls:

Risk scoring that classifies users into low, medium, high risk
Conditional verification for high-risk payout attempts
Device fingerprinting for repeated-attempt detection
Velocity limits to block rapid abuse loops
Geo-consistency checks against expected service location
Liveness challenge flow with selfie + gesture prompts
Even in a demo environment, this created realistic friction only where needed.

Payout lifecycle design

Instead of a single “success/fail” event, payouts move through explicit states:

Pending verification
Verified
Processing
Settled or failed

That state machine made it easier to debug behavior, generate history views, and provide clear UI feedback. It also allowed reason-code driven outcomes such as coverage inactive, cap reached, policy excluded, or verification required.

What I tested

I added tests around the pieces most likely to break business trust:

Risk score to risk level mapping
Plan cap and payout capping behavior
Security checks like velocity and geo guardrails
End-to-end payout flow transitions under different scenarios
This gave me confidence that “looks correct” in UI also means “behaves correctly” in logic.