DEV Community: Hardik Gupta

Inside the Engineering of Linkit

Hardik Gupta — Thu, 30 Jul 2026 18:56:09 +0000

I built Linkit - a link-in-bio SaaS for creators, freelancers, and small businesses. It started as a simple link manager and grew into profiles, forms, a lightweight shop, social caching, audience messaging, and an AI assistant (Lynki).

This post is about the main React app and Express API only. I'll walk through how the system works, the mistakes that hurt me in production, and what I'd change if I started again.

Stack in one line: Vite + React + Tailwind/shadcn on the frontend, Express on Node for secrets/AI/OAuth, Firebase Auth + Firestore + Storage as the data plane, deployed on Vercel.

Why I built it

Most link-in-bio tools are either too shallow (a list of buttons) or too expensive. I wanted one product where a creator could:

share a public page (/:username)
manage links and design from a dashboard
collect leads with forms
take simple catalog orders
talk to visitors (and get AI help)

I chose Firebase so I could ship Auth + DB + Storage fast. I added an Express backend the moment I needed API keys, OAuth exchanges, scrapers, or rate-limited public AI - those never belong in VITE_* env vars.

Overall architecture

Linkit is a dual-path system:

Browser → Firebase for user-owned CRUD (profiles, links, forms, orders), enforced by security rules
Browser → Express for secrets, AI, OAuth, crawling, and anything I can't safely do on the client

┌─────────────┐     axios + ID token      ┌─────────────────┐
│  React SPA  │ ─────────────────────────►│  Express API    │
│  (Vite)     │                           │  api.linkitapp  │
└──────┬──────┘                           └────────┬────────┘
       │                                           │
       │ Firebase client SDK                       │ Firebase Admin
       ▼                                           ▼
┌──────────────────────────────────────────────────────────┐
│           Firebase Auth · Firestore · Storage            │
└──────────────────────────────────────────────────────────┘
       ▲
       │ PostHog (analytics)

Surface	URL
Frontend	`https://linkitapp.in`
API	`https://api.linkitapp.in`
Local	`:8080` (app) + `:5001` (API)

Frontend

Layer	Choice
Framework	React 18 + TypeScript
Build	Vite
UI	Tailwind + shadcn/Radix
HTTP	axios (`src/lib/api.ts`) - attaches Firebase ID token
Icons	Phosphor (+ SVGL for social brands)
State	React Context - no Redux/Zustand

Provider order in App.tsx:

QueryClient → Auth → Profile → Currency → UI → Cart → Router → App

Important routing rule: the public profile catch-all /:username must stay near the end of the route table. Put a new route after it and you break every public profile.

How I read Firestore (and why I don't use onSnapshot everywhere)

Early on I used live onSnapshot listeners like everyone does. On Firebase Spark, that burned quota and multiplied listener churn.

So I built a shared poll helper (sharedFirestorePoll.ts): one interval, many React subscribers.

Data	Interval	Why
Links	~90s	Dashboard lists don't need live updates
Forms	~120s	Same
Profile doc	~300s	Changes rarely
Audience messages	live snapshot	Chat felt broken under polling

Real-time is a product choice, not a default.

Backend

Express ESM app. Thin routes, logic in services/, auth in middleware.

/auth          token helpers, student domains
/forms         share, submit, integrations
/ai            Lynki + public chat + helpers
/social        OAuth, refresh, metrics
/cloudinary    authenticated upload/delete
/payment       → HTTP 410 (removed)
/order-payment → HTTP 410 (removed)

Auth middleware is simple:

const token = authHeader.split('Bearer ')[1];
const decoded = await admin.auth().verifyIdToken(token);
req.uid = decoded.uid;

I also use:

optionalVerifyToken for guest-friendly routes
requireAdmin (custom claim or allowlisted UID)
budgetGuard IP rate limits for public/AI endpoints

Social refresh can run inline in the API process (serverless-friendly) or as a BullMQ worker when Redis is available.

Database

Firestore is the primary DB. Rules are default deny, then explicit allows.

users ──► profiles ──► links
                │
                ├── forms ──► form_submissions
                ├── catalogs ──► products
                ├── orders
                ├── audience_threads ──► messages
                └── social_* / public_profile_cache

usernames          (unique handle reservation)
user_integrations  (OAuth tokens - server-oriented)
analytics          (owner-only writes - see quota story)
lynki_*            (usage + BYOK settings)
app_config         (maintenance mode, testers)

Why Firestore: fast to ship with Auth/Storage.

Cost: Spark quotas are unforgiving, and it's a bad public event bus (I learned that the hard way).

I almost used Supabase early - the dependency is still in package.json as a fossil. It was never wired.

Authentication flow

User signs in (email / Google / GitHub)
        │
        ▼
Firebase Auth session
        │
        ├── ProtectedRoute → dashboard
        └── api.ts interceptor → Authorization: Bearer <idToken>
                                        │
                                        ▼
                              Express verifyIdToken
                                        │
                                        ▼
                                   req.uid set

I harden redirects with buildAuthHref() so a ?redirect= query can't become an open redirect.

Files and media

Firebase Storage for user/profile/form assets, path-scoped in storage.rules (~15MB caps)
Cloudinary for backgrounds/transforms; backend upload proxy keeps secrets server-side

Early storage rules were too broad (any authenticated user could touch too much). I scoped them to users/, profiles/, and forms/ after a production audit.

AI (Lynki)

Two modes:

Mode	Endpoint	Guard
Visitor chat on public profiles	`POST /ai/public-chat`	Optional auth + IP rate limit + feature flag
Dashboard agent	`POST /ai/lynki/chat`	Required auth + usage caps or BYOK

A provider router falls back across OpenRouter / Groq / GitHub Models. The model can propose actions; the client executes drafts. I don't give the model raw Firestore write access.

Payments (or: how I deleted them)

All features are free today. Prices in shared/linkitPricingDefaults.js are 0. Payment routes return 410 Gone.

I still keep plan enums (free, max, badge, student) and an entitlements module - but they currently unlock everything. That makes re-monetization possible without rewriting the UI.

I had previously built Cashfree flows, shop gates, and payment settings. Then the product decision flipped. Monetization reversed faster than the architecture - so I tombstoned APIs and cleaned dead CTAs/tours in an audit pass instead of leaving ghosts.

Deploy and ops

Git push
   ├── Vercel frontend (SPA → index.html)
   ├── Vercel backend (serverless Express)
   └── Firebase (rules + indexes + storage rules)

Optional: Redis + social worker on a small VPS

Secrets live only in backend/.env. Anything VITE_* is public in the browser bundle.

I smoke-test with:

npm run smoke:stabilization
npm run lint

Caching (really: quota defense)

I don't have a fancy multi-layer CDN cache story. Most "caching" is about not dying on Spark:

Layer	What I do
Dashboard reads	Shared polls (90–300s)
Quota spike	Pause polls until next UTC day
Social	Materialized `public_profile_cache` + queued refresh
Analytics	Prefer PostHog; Firestore increments behind a kill switch

Security (the non-negotiables)

Default-deny Firestore/Storage rules
Firebase ID tokens on protected APIs
CORS allowlist + Helmet
Sanitize user HTML (DOMPurify)
Rate-limit public AI/forms/uploads
Safe auth redirects
No secrets in VITE_*

Still imperfect: public profile docs can expose more fields than a minimal DTO. I'd split owner-private fields into a subcollection if I rebuilt.

Request lifecycle (happy path)

Dashboard API call

UI → api.get('/…') → attach ID token → Express → verifyToken → service → JSON

Public profile

/:username → query profile by username → load links/products
          → PostHog view event
          → optional /ai/public-chat

Social refresh

trigger → enqueue job → crawler → write cache/crawl state
        (never scrape live on the hot request path)

Folder structure

src/                 # React app
  pages/             # routes
  components/        # features + ui/
  contexts/          # Auth, Profile, Currency, UI, Cart
  hooks/             # polling hooks
  lib/               # api, poll, authFlow, lynki, errors
backend/
  routes/            # HTTP
  services/          # business logic
  middleware/        # auth, budgetGuard
  workers/           # social refresh
shared/              # pricing defaults (FE + BE)
firestore.rules
storage.rules
AGENTS.md            # living engineering handbook

The engineering journey (what actually happened)

1. Ship fast on Firebase

Vite + React + shadcn + Firebase. Link Manager first. Express when secrets appeared. That bet was right for speed.

2. Features exploded

Forms, shop, social, Lynki, admin, maintenance mode. The app stopped being "a link list."

3. I turned payments on… then off

I integrated Cashfree, gated shops behind payment settings, and used live listeners on orders. Later I made everything free. The painful part wasn't deleting payment code - it was finding every tour, CTA, and gate that still pointed at a dead flow.

Lesson: if monetization can flip, put it behind flags and ship 410 tombstones when you remove it.

4. The Firestore quota crisis

Public profile pages called analytics writes from the browser. Rules allowed essentially anyone to update analytics/{userId}. Profiles are crawlable. Bots don't care about your DAU.

I saw a write spike on the order of ~20k that looked like traffic, but was mostly crawlers.

Fixes that became architecture:

Analytics writes → owner-only in rules
VITE_ENABLE_FIRESTORE_ANALYTICS=false by default
Prefer PostHog for public metrics
Replace most onSnapshot with shared polling
Quota circuit breaker in the poll layer

Lesson: never use your primary user database as a public counter store.

5. Polling broke chat - so I brought snapshots back (narrowly)

After the quota scare I tried to keep audience messaging on polls. Send/receive felt unreliable. Chat is latency-sensitive.

I fixed it with batch writes + Messages-tab-scoped live listeners. Real-time returned - but only where the product needs it.

6. Social scraping on the request path failed

Live browser scrapes melted small hosts. I moved to cache-first orchestration, queued refresh, differential crawl, and default-off expensive flags.

7. Production audit (July 2026)

I cleaned payment ghosts, scoped storage rules, centralized error mapping, and fixed audience reliability. Bundle size and unfinished design-token migration are still debt.

Mistakes I'd warn my past self about

Public client writes to Firestore - bots will find them
onSnapshot as default - pay for real-time only when UX requires it
Removing payments without an audit checklist - dead CTAs linger
Broad storage rules - scope by owner path
Leaving unused deps (Supabase) - they lie to every future reader
Half-finished design migrations - finish or delete
Putting routes after /:username - instant public-profile breakage

What I'd build differently

Keep product analytics outside Firestore from day one
Ship a public profile DTO - don't serve the whole owner document
Make a worker service first-class (don't pretend serverless HTTP is a crawler host)
Put payments behind a feature flag before writing UI gates
Code-split heavy pages (Profile, Forms, Link Manager) immediately
Finish one design system before feature explosion
Use Redis/edge rate limits before going multi-instance
Write the incident notes while they're hot - and don't delete them

Closing

Linkit taught me that architecture isn't just boxes on a diagram. On a Firebase Spark + Vercel budget, rules, quotas, and abuse paths shape the product as much as React components do.

If you're building a similar dual-path Firebase + Express app: steal the dual-path clarity, the poll-by-default habit, and the 410 tombstone idea. Try not to steal the analytics-write mistake.

Quick reference

Item	Choice
Frontend	React + Vite (`src/`)
Backend	Express (`backend/`)
Auth	Firebase ID tokens
DB	Firestore (default deny)
Files	Storage + Cloudinary
Payments	Removed (410); everything free
Analytics	PostHog preferred
Polling	`sharedFirestorePoll.ts`
Handbook	`AGENTS.md`

How SigNoz Helped Me Debug Linkit Before 200+ Creators Noticed the Problem

Hardik Gupta — Thu, 16 Jul 2026 08:00:29 +0000

When you're building a product that's actually being used, debugging changes completely.

Console logs work when you're the only user.

They don't work when hundreds of people are creating pages, scanning QR codes, uploading products, and opening links from different devices at the same time.

I ran into exactly that while building Linkit, a creator platform that lets creators, cafés, and businesses build customizable link-in-bio pages with product catalogs, digital menus, forms, and AI-powered tools.

Today, Linkit powers:

500+ creators and businesses
35,000+ public profile visits
120,000+ link clicks
18,000+ QR code scans
4,000+ form submissions
Users from 15+ countries

As usage grew, I started noticing an annoying issue.

Some users said their pages opened instantly.

Others reported that the exact same page sometimes took 4–5 seconds to load.

The worst part?

I couldn't reproduce it consistently.

Everything looked normal on my machine.

This is where I stopped relying on logs and started using OpenTelemetry with SigNoz.

Architecture

Linkit isn't just a React frontend.

Every request goes through multiple services before the final page is rendered.

Current stack:

React + Vite
Node.js + Express
PostgreSQL
Redis
Cloudinary
OpenTelemetry
SigNoz

A single request for a public profile may involve:

Authentication
Fetching profile data
Loading products
Fetching analytics
Loading custom theme
Resolving images
Returning the final response

Without distributed tracing, figuring out which step is slow is mostly guessing.

Adding OpenTelemetry

Getting started was surprisingly simple.

Install the packages:

npm install @opentelemetry/sdk-node \
@opentelemetry/auto-instrumentations-node \
@opentelemetry/exporter-trace-otlp-http

Create an instrumentation file:

const { NodeSDK } = require("@opentelemetry/sdk-node");
const { getNodeAutoInstrumentations } = require("@opentelemetry/auto-instrumentations-node");
const { OTLPTraceExporter } = require("@opentelemetry/exporter-trace-otlp-http");

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: "http://localhost:4318/v1/traces",
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Run the server:

node --require ./instrumentation.js server.js

Within minutes, traces started appearing inside SigNoz.

The First Discovery

Initially, I assumed PostgreSQL was causing the slowdown.

The traces immediately proved me wrong.

Typical request:

Incoming Request
        │
        ▼
Authentication (12 ms)
        │
        ▼
Database Query (24 ms)
        │
        ▼
Generate Components (430 ms)
        │
        ▼
Cloudinary Lookup (280 ms)
        │
        ▼
Response

The database wasn't the problem.

It only accounted for around 24 milliseconds.

Most of the request time was being spent generating page components and fetching media.

Without tracing, I would've spent hours optimizing SQL queries that were already fast.

Finding Duplicate Work

Every Linkit page can contain:

Social links
Products
Forms
Digital menus
Embedded videos
Analytics widgets
AI-generated sections

SigNoz traces showed that some profile layouts were requesting identical resources multiple times.

For one page, the same API endpoint was called four times during a single request.

That wasn't obvious from logs.

Adding a small Redis cache reduced page generation time from:

920 ms → 310 ms

No frontend changes.

No database optimization.

Just removing unnecessary work.

Monitoring Traffic

As Linkit grew, I stopped opening terminal logs altogether.

Instead, I kept a SigNoz dashboard open.

It answered questions instantly:

Which endpoint is slow today?
Are uploads failing?
How many requests are arriving every minute?
Is Redis healthy?
Did the latest deployment increase latency?
Is memory usage stable?

Having all of that in one place made debugging dramatically faster.

One Bug That Would've Taken Hours

A creator reported that image uploads occasionally failed.

The frontend simply displayed:

Upload Failed

Not exactly useful.

The trace showed something completely different.

Frontend

↓

Authentication

↓

Generate Upload Signature

↓

Cloudinary API

↓

Timeout

↓

Retry

↓

Success

The backend wasn't failing.

Cloudinary occasionally timed out, triggering the retry mechanism.

Instead of rewriting upload code, I adjusted timeout settings and improved retry logic.

Problem solved.

Error Monitoring

One endpoint consistently had a higher failure rate.

POST /api/forms/submit

Opening the traces revealed the issue immediately.

Some users were uploading files larger than the backend allowed.

Instead of returning generic 500 errors, I added proper validation and descriptive error messages.

Support requests dropped almost immediately.

Business Metrics Matter Too

Technical metrics are useful.

Business metrics are even better.

Besides the default dashboards, I created custom metrics for Linkit.

These included:

New creator registrations
Published pages
QR scans
Link clicks
Product purchases
Form submissions
AI content generations
Payment events

Being able to correlate product activity with infrastructure metrics helped answer questions like:

Did increased traffic actually slow the application?
Did yesterday's deployment reduce conversion?
Which features receive the most usage?

Instead of only monitoring servers, I was monitoring the product itself.

Deployments Became Less Stressful

Before using SigNoz, deploying meant:

Push code.
Refresh the app.
Hope everything works.

Now every deployment is followed by watching:

Error rate
Request latency
Memory usage
CPU utilization
Slow traces
Database performance

If anything spikes, it's visible within minutes.

That confidence alone makes observability worth adding.

Lessons Learned

The biggest lesson wasn't finding bugs.

It was learning where the bugs weren't.

Several times I blamed PostgreSQL.

The traces showed perfectly healthy queries.

Other times I suspected Redis.

The real issue was duplicate API requests.

Without observability, I would've optimized the wrong parts of the application.

With traces and metrics, every optimization was backed by evidence instead of assumptions.

Conclusion

Adding OpenTelemetry and SigNoz changed how I debug Linkit.

Instead of relying on console logs and intuition, I now have visibility into every request, every database query, every external API call, and every performance bottleneck.

As Linkit continues to grow, observability has become just as important as testing.

Building features gets users.

Keeping those features fast, reliable, and measurable keeps them coming back.

Bloom Filters for AI Agents: The Small Cache Trick That Saved My Retrieval Pipeline

Hardik Gupta — Fri, 17 Apr 2026 18:07:16 +0000

Bloom filters felt like a purely academic data structure - until an agent pipeline started repeating work. At that point, they became immediately practical.

Problem

The system needed a fast, low-cost way to check whether something had probably been seen before.

Not certainty. A strong enough signal to avoid redundant work.

Failure Mode

The agent repeatedly:

revisited identical document IDs
re-triggered the same tool calls
reprocessed items already handled minutes earlier

This created:

unnecessary latency
increased compute cost
degraded pipeline efficiency

A lightweight pre-check layer was required.

Approach

Introduce a Bloom filter as a front-line gate:

If definitely new → process
If possibly seen → verify via authoritative store

Properties leveraged:

No false negatives
Acceptable false positives

Mental Model

A Bloom filter consists of:

a fixed-size bit array
multiple hash functions
a probabilistic membership check

Insert

hash value multiple times
set corresponding bits to 1

Query

if any bit is 0 → definitely not present
if all bits are 1 → possibly present

Implementation

class BloomFilter {
  private bits = new Uint8Array(2048);
  private readonly seeds = [17, 31, 53, 73];

  private hash(value: string, seed: number) {
    let hash = seed;
    for (let i = 0; i < value.length; i++) {
      hash = (hash * 33 + value.charCodeAt(i)) % this.bits.length;
    }
    return hash;
  }

  add(value: string) {
    for (const seed of this.seeds) {
      this.bits[this.hash(value, seed)] = 1;
    }
  }

  has(value: string) {
    return this.seeds.every(
      (seed) => this.bits[this.hash(value, seed)] === 1
    );
  }
}

Where It Fit in My Agent Stack

I ended up using Bloom filters in three key places:

1. Event Deduplication

Before the agent processes anything, I filter out repeated inputs. This alone removed a lot of noise.

2. Retrieval Optimization

While scanning candidate documents, I skip anything that has likely been seen before. This reduced unnecessary lookups.

3. Tool Call Short-Circuiting

This was the biggest win.

Agents tend to repeat tool calls when context becomes messy. A Bloom filter doesn’t fix reasoning, but it stops the system from wasting cycles on the same targets again and again.

The Tradeoff I Respect

I don’t use Bloom filters when I need certainty.

I use them when I need:

speed
low memory usage
a fast first-pass filter

They are not a source of truth.

They are a guardrail.

Final Take

Bloom filters work best as a front-line defense against wasted effort.

They don’t fix reasoning.

They don’t improve intelligence.

What they do is enforce discipline in the system - quietly, efficiently, and at scale.

In agent pipelines, that’s often exactly what is missing.

Discussion

How do you handle deduplication in your AI workflows?

Redis / Postgres with exact checks?
Probabilistic structures like Bloom or Cuckoo filters?
Something hybrid?