DEV Community: Suresh

I Built a Recommendation Engine That Suggests Products to Users — No Login Needed

Suresh — Mon, 13 Jul 2026 04:40:47 +0000

Every product website can personalize easily once someone logs in — you know who they are, what they've bought before, and you can build them a profile worth targeting. That part's basically solved.

The real challenge is the visitor who never logs in at all. Most people don't sign up before they've even decided to buy anything, so if personalization only switches on after account creation, you miss the exact moment it matters most — their very first visit. That first-time, anonymous visit is also most of a site's traffic, and exactly the segment a marketing team is working hardest to convert.

That's the gap I wanted to close: could a homepage still personalize itself for someone with zero login, zero profile, and only a handful of page views to go on? Not a discount popup or an exit-intent banner — an actual recommendation that adapts to what they've shown interest in, from click one.

This Recommendation site is built with Next.js, GraphQL, and MongoDB — a storefront where the homepage learns from real browsing behavior, no account required.

🎥 Live Demo: https://recommendation-engine-sand.vercel.app/

📂 Source Code: https://github.com/Suresh4405/recommendation-engine

What It Does

Shows a personalized "Recommended for you" strip that changes based on real browsing behavior
First-time visitors see admin-curated "default" picks instead of an empty page
Recognizes returning visitors without any login — just a cookie
Ranks by how often you view something, not just the last thing you clicked
Falls back gracefully — if you've only looked at 2 products in a category, it fills the rest of the row instead of showing 3 empty cards
Full admin panel: add/edit products, reorder them by typing a position number, star specific ones as default picks
Cursor-based pagination on the main grid (no page numbers, just "Load more")
A dummy cart (localStorage-backed) so the flow feels complete end to end

The Tech Stack

Frontend: Next.js 14 (App Router), Tailwind CSS

API layer: GraphQL via Apollo Server, mounted as a Next.js route handler

Database: MongoDB + Mongoose

The "no login" trick: a single anonymous cookie, set in middleware

How It Works

Step 1: Recognizing a visitor without asking them to sign in

The whole system hangs off one idea — you don't need to know who someone is to remember that they've been here before. Middleware runs before every request and drops a random ID in a cookie if one doesn't already exist:

// middleware.js
export function middleware(request) {
  const response = NextResponse.next();
  const existing = request.cookies.get("guestId");

  if (!existing) {
    response.cookies.set("guestId", uuidv4(), {
      maxAge: 60 * 60 * 24 * 365,
      httpOnly: false,
      sameSite: "lax",
      path: "/",
    });
  }

  return response;
}

That's it. No user table, no password, no session store. Just a UUID sitting in the browser for a year. httpOnly is deliberately false here — it's not sensitive, and client components need to read it to attach it to GraphQL calls.

Step 2: Logging what people actually look at

Every time a product page loads, a tiny client component fires a mutation and does nothing else — no UI, no loading state, just a side effect:

// components/ViewTracker.jsx
export default function ViewTracker({ productId }) {
  useEffect(() => {
    const guestId = getGuestId();
    if (!guestId) return;
    gqlFetch(TRACK_VIEW_MUTATION, { guestId, productId }).catch(() => {});
  }, [productId]);

  return null;
}

That mutation just writes one row to a separate interactions collection — it never touches the products collection itself:

async trackView(_parent, { guestId, productId }) {
  await connectToDatabase();
  const product = await Product.findById(productId).lean();
  if (!product) return false;

  await Interaction.create({
    guestId,
    productId,
    category: product.category,
    brand: product.brand,
    action: "viewed",
  });
  return true;
}

Over time this collection becomes a plain log: this guestId looked at these categories, this often, this recently. Nothing fancier than that — no embeddings, no ML model, just a count.

Step 3: Turning that log into an actual recommendation

This is the part I rewrote the most. My first version weighted the most recent view the heaviest, on the theory that recent interest should matter more. In practice this backfired constantly — someone would browse mobiles twice, glance at a laptop once out of curiosity, and the whole homepage would flip to laptops. One click undoing two real signals felt wrong.

So I flipped the model: frequency is the primary signal, recency only breaks a tie.

const scoreByCategory = {};
const viewCountByProduct = {};

recentViews.forEach((view, idx) => {
  // tiny recency bonus - max +0.01, only matters when categories are tied
  const recencyBonus = (recentViews.length - idx) / recentViews.length / 100;
  scoreByCategory[view.category] =
    (scoreByCategory[view.category] || 0) + 1 + recencyBonus;

  const pid = view.productId.toString();
  viewCountByProduct[pid] = (viewCountByProduct[pid] || 0) + 1;
});

Then, within the winning category, individual products get re-ranked by how many times that specific product was viewed — not just newest or most discounted:

categoryProducts.sort((a, b) => {
  const aViews = viewCountByProduct[a._id.toString()] || 0;
  const bViews = viewCountByProduct[b._id.toString()] || 0;
  if (bViews !== aViews) return bViews - aViews;
  if (b.discountPercent !== a.discountPercent)
    return b.discountPercent - a.discountPercent;
  return new Date(b.createdAt) - new Date(a.createdAt);
});

If someone's never visited before, there's nothing to score — so it falls back to a curated default row:

const fallback = async () => {
  const docs = await Product.find({})
    .sort({ featured: -1, sortOrder: 1, createdAt: -1 })
    .limit(count)
    .lean();
  return {
    title: "New arrivals for you",
    reason: "new_arrival",
    products: docs.map(serializeProduct),
  };
};

featured and sortOrder are both admin-controlled — more on that below.

Step 4: Letting admin actually curate this, not just watch it happen automatically

I also didn't want the admin to be stuck just watching this happen automatically with no way to guide it. So I added two simple controls:

A position number per product (type 1, hit enter, it jumps there) — controls default order everywhere.
A featured star — marks a product as a guaranteed pick for first-time visitors, independent of its position.

async setProductPosition(_parent, { id, position }) {
  await connectToDatabase();
  const docs = await Product.find({})
    .sort({ sortOrder: 1, createdAt: -1, _id: -1 })
    .lean();

  const index = docs.findIndex((d) => d._id.toString() === id);
  if (index === -1) return false;

  const [moved] = docs.splice(index, 1);
  const targetIndex = Math.max(0, Math.min(position - 1, docs.length));
  docs.splice(targetIndex, 0, moved);

  await Promise.all(
    docs.map((doc, i) => Product.updateOne({ _id: doc._id }, { sortOrder: i }))
  );
  return true;
}

Every reorder fully resequences the collection (0, 1, 2, ...) instead of trying to patch just two records — simpler to reason about, and it self-heals any products that never had an explicit order set.

What Broke First

Pagination started repeating products. Once I added manual ordering, the main grid's sort became 3 fields deep (sortOrder, createdAt, _id), but "Load more" was still only checking _id to know where to continue. That meant page 2 could re-fetch stuff already shown on page 1. Fixed by encoding all 3 sort values into the cursor itself:

export function encodeCursor(fields) {
  return Buffer.from(JSON.stringify(fields)).toString("base64");
}

and building the "after" filter to match the sort exactly:

filter.$or = [
  { sortOrder: { $gt: so } },
  { sortOrder: so, createdAt: { $lt: crDate } },
  { sortOrder: so, createdAt: crDate, _id: { $lt: id } },
];

Schema and resolver drift. GraphQL will happily let you define a resolver for a field that doesn't exist in your schema, and it fails loudly and unhelpfully at server startup (Query.similarProducts defined in resolvers, but not in schema). Lesson learned: change the schema and the resolver in the same commit, every time, no exceptions.

Recency dominating frequency, covered above — took actually using the thing for a day to notice it felt wrong, not something I'd have caught from just reading the code.

Why I Log Interactions Separately Instead of Bolting Fields Onto Products

I could've just added a viewCount field directly on each product document and incremented it. Tempting, but:

You lose who viewed it and when — which is the entire input to personalization
You can't tell "5 different people viewed this once" from "1 person viewed it 5 times" — very different signals

Visit / for the storefront, /admin for the product panel (password-gated). Click into a couple of products, go back to the homepage, and the top strip should already reflect what you looked at.

🚀 Live Demo: https://sureshcodes.vercel.app/recommendation-engine

📂 Source Code: https://github.com/Suresh4405/recommendation-engine

A Website Can Be Fast and Still Be Bad

Suresh — Fri, 03 Jul 2026 06:05:34 +0000

I have a personal rule: never ship anything I haven't checked against my own list first.

It didn't start as a list. It started as a bunch of sticky notes and half-forgotten Slack messages to myself, every time something went wrong in production — a query that crawled once real traffic hit, a token that got stolen because I stored it in the wrong place, a "fast" page that still lost users because nobody bothered asking who it was for. Over the years, working across React, Node, MongoDB, MySQL, SQL Server, and AWS, those notes turned into an actual set of do's and don'ts I run through on every project, no matter how small.

Lately AI tools have made a lot of the "fast website" checklist feel automatic — compress the image, cache the query, lazy-load the asset, done. And that part genuinely works. But a fast site and a good site aren't the same thing, and most of these AI-speed guides quietly skip the parts that actually decide whether people stick around.

So here's my list, properly written out for once — frontend, backend, security, and the one step before all of it that most people forget to do at all.

Let's start where the user actually meets your work — the frontend.

Part 1: Making the Frontend Actually Fast

Speed here comes down to three things: how much you're sending down the wire, how long the server takes to respond, and how smart the browser is about loading what it receives.

Do:

Compress images and serve modern formats. Drop the PNGs and JPEGs where you can and switch to WebP or AVIF — same visual quality, a fraction of the file size.
Lazy-load anything below the fold. Images, iframes, heavy components — don't make the browser fetch what the user hasn't scrolled to yet.
Put a CDN in front of your static assets. Cloudflare (or CloudFront if you're already on AWS) serves content from a node physically closer to the visitor, which shaves off real, measurable latency.
Ship less JavaScript on first load. Code-split your React bundles by route so people aren't downloading your entire app just to read a landing page.

Don't:

Don't lazy-load your hero image or anything visible on first paint — that just delays the thing people see first.
Don't rely on a single CDN region if your audience is global. Check where your traffic is actually coming from before you assume Cloudflare's defaults have you covered.

Making People Actually Like Using the Site

This is the part that gets skipped once the Lighthouse score looks good. A fast site that's confusing to use just lets people leave faster.

Do:

Keep navigation dead simple. If someone has to think about where to click, you've already lost a few seconds of their patience.
Make search actually work. Not a search bar that exists for decoration — one that returns relevant results fast.
Design mobile-first. More of your traffic is on a phone than you think, and retrofitting desktop layouts down to mobile always shows.
Get the technical basics flawless — no layout shift, no broken states, no spinner that never resolves.

Don't:

Don't bury the primary action three menus deep because it looked cleaner in Figma.
Don't assume "visually delightful" means "add more animation." Delight usually means the thing worked the way the user expected, instantly.

The Part Everyone Skips: Who Are You Even Building This For?

Here's the uncomfortable truth. You can nail every performance metric above and still lose, because none of it matters if you're fast for the wrong audience.

Before you touch another optimization, do this:

Identify your top competitors and actually read how they talk to people — their blog tone, their ad copy, their social captions. Then go read their customer reviews. The complaints in those reviews are basically a free list of what your audience wants that isn't being delivered.
Segment your audience properly, not just by age and location:
- Demographics — age, gender identity, income, profession
- Geographics — location, language, climate if it's relevant to what you sell
- Psychographics — values, hobbies, lifestyle, daily habits
- Behaviors — how they discover brands, how they use tech, what actually triggers them to buy
Build 2–3 real buyer personas out of that research. Give them names, a goal, and a specific frustration. Then run every new feature or article through one question: would this specific person find value in this?

This is the piece an AI performance tool can't do for you. A model can compress your images. It can't tell you that your 45-year-old B2B buyer persona doesn't care about your Instagram-style micro-animations — they care about finding pricing information in under 10 seconds.

Speed, UX, and audience targeting aren't three separate projects. They're the same project, approached from three angles: your architecture, your user's psychology, and how you deliver resources to match both.

Part 2: Backend Performance — Without Touching a Single Line of App Code

I’ve seen apps feel slow because of one missing database index. Before rewriting a component, I check the query plan first.

Cache the right things, the right way

Put an in-memory store like Redis in front of your primary database for frequent read queries, and cache entire JSON responses on your read-heavy REST or GraphQL endpoints.

But — do NOT use Redis for highly dynamic, personalized pricing. If a price changes every few seconds based on location, demand, or account tier, caching every price variation will chew through your server RAM fast. Calculate that kind of price live, straight from an indexed DB lookup.

If you still want caching on something like a product catalog page, use the cache-aside pattern with eviction:

Admin updates the price in MySQL.
Backend deletes that product's key from Redis.
Next customer request hits Redis, gets a miss, fetches from MySQL, and repopulates Redis.

Fix your indexes — this is the #1 speed win, full stop

SQL (MySQL / SQL Server):
Run EXPLAIN on your slow queries. Anywhere you see type: ALL, that's a full table scan. Add B-Tree indexes on your WHERE, JOIN, and ORDER BY columns. If you're filtering on multiple columns at once, use a composite index and order the fields most-specific first.

MongoDB:
Run .explain("executionStats") and look for COLLSCAN — that's your collection scan warning sign. Create single or compound indexes with db.collection.createIndex().

Part 3: The Security Rules Nobody Reads Until Something Breaks

Everyone's rushing to ship faster with AI-generated boilerplate, and a lot of that boilerplate quietly skips security defaults that used to be common sense. Here's what to actually avoid, stack by stack.

OAuth 2.0 / OIDC (Authentication)

Don't use the Implicit Flow for your React SPA. It returns access tokens directly in the browser's URL hash, which leaves them exposed in browser history and to malicious extensions. Use Authorization Code Flow with PKCE instead.
Don't store long-lived JWTs or refresh tokens in localStorage. They're wide open to XSS attacks. Store them in HttpOnly, Secure, SameSite=Strict cookies instead.

WebSockets (Real-time features)

Don't skip authentication on the handshake. If anyone can open a socket connection without proving who they are during the initial HTTP upgrade, you've handed attackers an easy way to DoS your event loop.
Don't trust the payload just because the user is authenticated. Authenticated doesn't mean safe — validate the schema and check permissions before you broadcast any incoming socket message to other users.

Node.js Event Loop (Performance under load)

Don't run heavy CPU work on the main thread. Blocking crypto operations, huge array loops, JSON.parse() on a 50MB file — any of these freeze your single-threaded event loop and every other incoming request stalls with it. Offload to Worker Threads.
Don't mix async/await with sync file methods. fs.readFileSync() or fs.writeFileSync() inside a route handler blocks execution for everyone. Use the promises API — fs.promises.readFile() — instead.

Amazon S3 (Storage)

Don't disable "Block Public Access" unless you're deliberately hosting a public static site. Turning it off is how sensitive files end up getting picked up by automated scanners.
Don't use S3 as your query database. Repeatedly fetching and parsing large JSON/CSV files from S3 on every request will hit you with API limits and latency. Ingest that data into MySQL or MongoDB instead, and query it properly.

The Actual Point

None of this is complicated in isolation — cache the hot paths, index the slow queries, don't leave tokens in localStorage, don't skip your buyer personas. What's easy to miss is that speed and security fixes get all the attention right now because AI tools make them fast to apply, while the audience research step — the one that decides whether any of it even matters — still takes real, slow, human thinking.

Ship the fast site. Just make sure you know who it's fast for first.

This is the list I wish someone had handed me years ago instead of letting me learn each rule the hard way. If you've got your own "don't do this" rule from experience, drop it in the comments — always curious what other people's war stories add to the list.

Every Dev Re-Tests the Whole App Before Release. Here's the One-Time Setup That Ends That.

Suresh — Wed, 24 Jun 2026 10:47:09 +0000

I'd used Jest for years. Great for unit tests and React components, but it doesn't run a real browser. The moment I hit a Safari-specific bug that never appeared in Chrome, I realized I needed something different.

That's the gap Playwright is built for. It drives an actual browser - Chrome, Firefox, WebKit — and runs the same test in each one. The bug that only shows up in Safari shows up in the test run too, before it ships.

The project.
Secure Share is a file-sharing app I built — small enough to put together quickly, but complex enough to cover authentication, uploads, downloads, protected routes, and share-link generation.

User (Browser)
   ↓
React.js — Dashboard UI
   ↓
Node.js API — JWT Auth
   ↓
MongoDB — Users & Files
   ↓
Storage — Documents

Secure sharing workflow:


Login →  Upload File →  Generate Link →  Set Expiry →  Share URL → Protected Download

Every one of those six steps used to mean a manual click-through across two or three browsers before a release. That's what got automated.

Testing across browsers. Playwright defines browsers as projects in config. One test file, run once per browser listed:

// playwright.config.js
export default defineConfig({
  testDir: './tests',
  reporter: 'html',
  use: { baseURL: 'http://localhost:5173' },

  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox',  use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit',   use: { ...devices['Desktop Safari'] } },
  ],
});

npx playwright test                    # all three browsers
npx playwright test --project=webkit   # just Safari's engine

What this caught: a Safari click-handler bug. Chrome passed, WebKit failed on the same spec, and the report named the exact line. That's the kind of bug that lives entirely in the browser layer — invisible to anything running in Node.

Validating login.

test('user can login', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'test@gmail.com');
  await page.fill('#password', 'Password123');
  await page.click('button[type="submit"]');

  const token = await page.evaluate(() => localStorage.getItem('token'));
  expect(token).not.toBeNull();
});

Not just "did the page redirect" — checking the JWT actually landed in storage. A redirect can fire before the token write finishes; checking the token is what catches that.

Validating the rest, briefly.

// wrong password → correct error
await page.fill('#email', 'wrong@test.com');
await page.fill('#password', 'WrongPassword');
await page.click('button[type="submit"]');
await expect(page.getByText('Invalid email or password')).toBeVisible();

// upload → confirmation
await page.locator('input[type="file"]').setInputFiles('tests/files/sample.pdf');
await expect(page.getByText(/uploaded successfully/i)).toBeVisible({ timeout: 20000 });

// share link → copy confirmation
await page.click('text=Generate URL');
await page.click('text=Generate & Copy Link');
await expect(page.getByText(/link copied/i)).toBeVisible();

// download → real file, not a broken stream
const downloadPromise = page.waitForEvent('download');
await page.click('text=Download');
const download = await downloadPromise;
expect(download.suggestedFilename()).toBeTruthy();

Each test is small on purpose — one user action, one thing it should be true after. Stacked together, they cover the same path the manual checklist used to.

The HTML report.

reporter: 'html' generates a report after every run that shows pass/fail per browser, per test, with a trace of exactly where it broke. It's caught more than one selector that Safari resolves differently — something that would never show up in a Jest test.

One-time setup, then it's just a command.

git clone <repo>
cd e2e
npm install
npx playwright install

Before Playwright: 15–20 minutes of clicking through the app before every release. After Playwright: one command (npx playwright test) and a report in under a minute.

The report tells you — before a user does — whether login, upload, sharing, and download still work everywhere they need to.

I still use Jest for unit tests. Playwright didn't replace it. It solved a different problem: validating that the entire application works the way a real user expects. For this project, that meant fewer repetitive checks, faster releases, and more confidence that a change in one area didn't quietly break another.

Code and live demo:

GitHub: github.com/Suresh4405/encrypted-file-share
Live app: sureshcodes.vercel.app/secure-share

Everyone Wants AI. Nobody is Doing the Math.

Suresh — Thu, 11 Jun 2026 09:15:21 +0000

I've been job hunting recently.

Almost every job post mentions AI. Not because the company has a real plan for it. Not because they've figured out where it actually fits. Just because it's 2026 and it feels embarrassing not to say you're using AI.

That's the first problem. But it goes deeper than hiring trends.

The chatbot nobody asked for

Every company wants AI to do their daily work twice as fast. For example, some companies I came across had already replaced their entire support team with a chatbot.

On paper: cheaper, always available, scales easily.

In practice? It hallucinates. Gives wrong answers confidently. The user asks something slightly outside what it knows and gets a response that makes no sense. No fallback. No human. Just a confused user who closes the tab and never comes back.

The problem wasn't the AI. It was bad design. Nobody thought about what
happens when the model doesn't know. Nobody built a way out to a real person.

They just shipped it because it felt modern.

And every one of those dead-end interactions spent real tokens. API calls aren't free. Burning money on confusion isn't efficiency - it's just expensive failure.

Nobody is doing the math

A company AI setup - Copilot, ChatGPT Enterprise, Claude API, internal tooling - adds up quietly. And it still needs someone experienced to review everything it generates, guide it, and fix what it breaks.

You didn't save a salary. You just moved the cost somewhere less visible.

Data centers have always used water. AI just made it worse.

Every server needs cooling. Cooling needs water. Emails, YouTube, Google
Search - all of it has always had a water cost. That's not new.

What changed is the scale. An AI response loads a massive model, runs billions of calculations, generates every word one token at a time - millions of times a day.

Email is a bicycle. Google Search is a scooter. An AI chatbot is a car.
Training a new model is a flight. All burn fuel. Just at completely different levels.

A UC Riverside study found that a simple 100-word ChatGPT response consumes roughly 500ml of water - about a full drinking bottle. That includes the water used to cool the servers and the water burned to generate the electricity powering them. 10 to 50 queries? Around 2 litres gone.

Training GPT-3 alone consumed an estimated 5.4 million liters of freshwater. GPT-4 is bigger. And every company rushing to build their own model, fine-tune it, redeploy it - they're all adding to that number. We're not talking about a leaking tap. We're talking about a river being quietly redirected.

What's happening right now

In March 2026, residents of Hanover County, Virginia protested a 427-acre data center project. Not activists - regular people who saw the impact coming.

Meanwhile in Visakhapatnam, Andhra Pradesh, Google and Reliance are both
planning major AI data centers. People here are excited. Jobs, investment, development. I understand why.

But Vizag already has low groundwater availability. These aren't small server rooms. When groundwater levels drop, farmers in the surrounding region face higher irrigation costs, lower yields, and direct competition with a data center for the same water. That conversation isn't happening loudly enough in India.

Why is a developer writing this

Because we're the ones building these systems. Most technical conversations stay inside the system boundary - performance, latency, cost per query. But we're building inside a physical world that has actual limits.

This isn't against AI. I use it. I write about it. I think it genuinely
changes what's possible.

But there's a real difference between using something thoughtfully and
slapping it onto your product because a job post told you to.

Between 2026 and 2040, most workflows will probably run on AI agents. Every company will monetize it. That's likely going to happen.

Just plan before you build. Ask what it actually costs - not just in tokens and API bills, but in the things that don't show up on a dashboard.

Food comes from agriculture. Agriculture runs on water. No amount of compute
fixes a drought.

If this made you think, drop a 🧡

You Shipped a Great Product. Nobody Found It. Here's Why

Suresh — Thu, 04 Jun 2026 06:40:57 +0000

Most teams do everything right and still launch into silence.

The UI is clean. The code is solid. Database is indexed. Lighthouse is green.

Then launch day hits - organic traffic is flat, leads ghost after the price reveal, and the site doesn't show up anywhere on Google.

The product isn't the problem. The thinking behind who needs to read that page is.

Problem 1: Your Sales Page Sells Features, Not Outcomes

Watch any SaaS sales call. It goes like this:

Features → Deliverables → Process → Price.

Lead ghosts. Team panics. Someone says "let's offer a discount."

That's the wrong fix.

Buyers don't ghost because of price. They ghost because they never understood what changes for them after buying.

"We build custom dashboards" → feature

"You'll stop spending 3 hours every Monday pulling reports" → outcome

Position around the outcome. Browsers self-filter. Real buyers show up.

Problem 2: Your React App Is Invisible to Google

Many teams build product pages in React (Vite). Works fine for users. But when the page loads dynamic content from a database - product names, prices, descriptions - here's what Google actually sees:

Googlebot visits /products/your-product
Server returns → <div id="root"></div>  ← empty shell, no DB data
React fetches DB data → only AFTER browser runs JavaScript
Googlebot doesn't wait → indexes a blank page
Result → you never appear in search

React sends an empty container. The database data loads later in the browser. Googlebot is already gone.

Next.js flips this:

Googlebot visits /products/your-product
Next.js hits the DB on the SERVER before sending anything
Googlebot receives → full HTML with title, price, description already inside
Result → indexed and ranked

If the goal is traffic and leads from search - SSR isn't optional.

Problem 3: SEO Alone Isn't Enough Anymore

In 2026, a chunk of your potential buyers never open Google. They ask ChatGPT or Perplexity directly and get a single synthesized answer.

Your page can rank #2 on Google and still never get cited by an AI-because the text wasn't structured cleanly enough to extract.

This is the gap between SEO, AEO (Answer Engine Optimization), and GEO (Generative Engine Optimization).

What	Who it's for
SEO	Google's crawler
AEO	AI engines answering questions
GEO	Getting cited in AI-generated responses

You need all three now.

What Actually Works: Structure Your Page for All Three Readers

For Google - one <h1>, semantic heading hierarchy, fast load, descriptive alt text, sitemap + robots.txt, backlink

For AI engines - write specs in tables, FAQs in natural Q&A language, use explicit <section id="..."> tags so content chunks stay coherent when AI crawlers split your page

For both - JSON-LD structured data. Not optional anymore.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Your Product Name",
  "description": "One clear sentence about what it does and who it's for.",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "99.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Perplexity reads this. Gemini reads this. Google reads this. It's the closest thing to a universal language for product pages right now.

The One Thing Connecting All Three Problems

Buyers ghost → unclear outcome

Google ignores the page → unclear content structure

AI skips the page → unclear text formatting

Every single time, something couldn't understand what was being offered fast enough to care.

Great products get buried every day because the page wasn't built for the right readers.

Build for the buyer. Build for the crawler. Build for the AI.

The traffic problem usually solves itself after that.

Drop a 🧡 if this hit something you've seen before. Curious what's working for your team in the comments.

I Built a Real-Time Financial Dashboard That Talks Directly to Tally Prime's XML API

Suresh — Wed, 03 Jun 2026 12:01:37 +0000

Every accountant I spoke to had the same complaint.

Open Tally Prime → export data → wait → open Excel → format it → wait some more.

Repeat this every single day for ledgers, invoices, balance sheets.

It was slow, manual, and error-prone. One wrong cell in Excel and the numbers don't match. One missed export and the report is already stale.

So I built TallySync - a real-time financial dashboard that talks directly to Tally Prime via its XML API. Create ledgers, push invoices, pull data, view analytics - all from a clean web UI, without touching Tally's menus at all.

🎥 Live Demo: sureshcodes.vercel.app/tallysync

📂 Source Code: github.com/Suresh4405/TallySync-Portal

What It Does

Create ledgers (with GST, PAN, address, opening balance) and push them straight into Tally
Create sales invoices and sync them as vouchers in Tally
Pull ledgers from an existing Tally company into the dashboard database
View analytics — revenue charts, sync status breakdowns, ledger summaries
Admin panel to manage users and monitor sync logs
JWT-based auth with protected routes

The Tech Stack

Frontend: React + Vite, Material UI, Recharts, Axios

Backend: Node.js + Express, Sequelize ORM, MySQL

Tally Integration: Tally XML API (ODBC port 9000)

How It Works

Step 1: Tally's XML API

Tally exposes a local HTTP server on port 9000 when ODBC is enabled. You can send XML envelopes to it and it either exports data or imports it directly into the active company.

To enable it: open Tally → F11 → F1 → Enable ODBC Server

Here's how the backend talks to Tally:

// services/TallyService.js
async sendRequestToTally(xmlData) {
  const response = await axios.post(this.tallyHost, xmlData, {
    headers: {
      'Content-Type': 'application/xml',
      'Accept': 'application/xml'
    },
    timeout: 30000
  });
  return response.data;
}

If ECONNREFUSED comes back, the app catches it and gives a clear message instead of a cryptic error.

Step 2: Creating a Ledger in Tally

When you submit a ledger form in the UI, the backend saves it to MySQL first, then fires an XML import request to Tally:

// services/TallyService.js
async createLedgerInTally(ledgerData, userId) {
  const isConnected = await this.testTallyConnection();
  if (!isConnected) {
    throw new Error('Cannot connect to Tally. Please check Tally is running.');
  }

  const xml = `<?xml version="1.0" encoding="UTF-8"?>
<ENVELOPE>
  <HEADER>
    <TALLYREQUEST>Import Data</TALLYREQUEST>
  </HEADER>
  <BODY>
    <IMPORTDATA>
      <REQUESTDESC>
        <REPORTNAME>All Masters</REPORTNAME>
      </REQUESTDESC>
      <REQUESTDATA>
        <TALLYMESSAGE xmlns:UDF="TallyUDF">
          <LEDGER NAME="${ledgerData.ledger_name}" Action="Create">
            <PARENT>${ledgerData.parent_group || 'Sundry Debtors'}</PARENT>
            <OPENINGBALANCE>${ledgerData.opening_balance || 0}</OPENINGBALANCE>
            <GSTREGISTRATIONTYPE>Regular</GSTREGISTRATIONTYPE>
            <PARTYGSTIN>${ledgerData.gst_number || ''}</PARTYGSTIN>
          </LEDGER>
        </TALLYMESSAGE>
      </REQUESTDATA>
    </IMPORTDATA>
  </BODY>
</ENVELOPE>`;

  const response = await this.sendRequestToTally(xml);
  // parse response, extract GUID, update DB record
}

If Tally accepts it, the tally_guid is extracted from the response and saved back to the DB so the record is fully traceable.

Step 3: Pulling Ledgers Back from Tally

The sync is bidirectional. The app can also fetch all ledgers from Tally and upsert them into MySQL:

async syncLedgersToDatabase(userId) {
  const tallyLedgers = await this.getLedgersFromTally();

  for (const tallyLedger of tallyLedgers) {
    const [ledger, created] = await TallyLedger.findOrCreate({
      where: { ledger_name: tallyLedger.name },
      defaults: {
        ledger_name: tallyLedger.name,
        parent_group: tallyLedger.parent,
        opening_balance: parseFloat(tallyLedger.opening_balance) || 0,
        closing_balance: parseFloat(tallyLedger.closing_balance) || 0,
        tally_guid: tallyLedger.guid,
        synced_at: new Date()
      }
    });

    if (!created) {
      await ledger.update({ closing_balance: ..., synced_at: new Date() });
    }
  }
}

Step 4: The Dashboard & Analytics

The dashboard shows:

Total ledgers, invoices, synced count, failed syncs
Revenue trend (bar/line/area chart via Recharts)
Sync status pie chart (pending / success / failed)
Recent sync activity log

The analytics page lets you filter by date range and toggle between chart types.

The Database Schema

Three core tables:

tally_ledgers — stores ledger data with tally_guid, synced_at, GST, PAN, address, balances

tally_invoices — stores invoice/voucher data with sync_status enum (pending / success / failed)

sync_logs — audit trail of every push/pull operation with timestamps and error messages

Sequelize handles migrations with sync({ alter: false }) in production so the schema doesn't get nuked on redeploy.

What Broke First

XML parsing. Tally's response XML is deeply nested and the tag names change depending on the operation. I had to write a dedicated parser that extracts the GUID and checks for error strings inside the response body — because Tally returns HTTP 200 even when the import fails. The error is buried in the XML.

Connection refused with no context. The first time Tally wasn't running, the frontend just showed a generic 500. I added explicit ECONNREFUSED handling in the service layer so users get a helpful checklist instead.

Why I Stored Data in MySQL Too

I could have just been a passthrough — send to Tally and forget. But having a local copy means:

You can query, filter, and show analytics without hitting Tally every time
You have a sync log to audit what succeeded and what failed
If Tally is offline, users can still view existing records

Setup

# Server
cd server
cp .env.example .env  # set DB_HOST, TALLY_HOST, JWT_SECRET
npm install
node indexserver.js

# Client
cd client
cp .env.example .env  # set VITE_API_URL
npm install
npm run dev

Make sure Tally is open with ODBC enabled on port 9000. The app checks the connection before every push operation.

🚀 Live Demo

https://sureshcodes.vercel.app/tallysync

📂 Source Code

github.com/Suresh4405/TallySync-Portal

👨‍💻 Portfolio

sureshcodes.vercel.app

Drop a 🧡 if this was useful — especially if you've ever fought with Tally's XML API.

I built a bulk email tool in one evening - no database, no .env, credentials never stored

Suresh — Wed, 03 Jun 2026 10:15:42 +0000

Every week I had to send 100+ personalized emails.

Open Excel → copy name → paste → change email → repeat 100 times.

It was taking nearly 3 hours every week.

So instead of doing it manually again, I spent one evening building a tool that does the same job in about 2 minutes.

What it does

Upload Excel file → Parse data → Detect columns → Write template with {{variables}} → Preview emails → Send all via Gmail

No database

✅ No .env

✅ No stored credentials

✅ No authentication setup

✅ Works with Gmail App Passwords

🔗 Live Demo: https://bulk-mail-sender-lilac.vercel.app/

📂 Source Code: https://github.com/Suresh4405/BulkMail-Sender

👨‍💻 Portfolio: https://sureshcodes.vercel.app/

Why I Built It

Most bulk email tools either:

Charge monthly fees
Require complicated setup
Store your credentials somewhere

I wanted something simpler.

A tool where credentials exist only during the current request.

Once the emails are sent, everything disappears from memory.

That became the core design principle behind the project:

If there is no stored data, there is nothing to leak.

How It Works

Step 1: Login with Email & App Password

The user enters a Gmail address and App Password.

The credentials are verified instantly before sending any emails.

Code – app/api/testCredentials/route.ts

import { NextRequest, NextResponse } from 'next/server';
import nodemailer from 'nodemailer';

export async function POST(request: NextRequest) {
  try {
    const { email, password } = await request.json();

    const transporter = nodemailer.createTransport({
      service: 'gmail',
      auth: {
        user: email,
        pass: password,
      },
    });

    await transporter.verify();

    return NextResponse.json({ success: true });
  } catch {
    return NextResponse.json(
      { success: false },
      { status: 401 }
    );
  }
}

Step 2: Import Your Excel File

Upload any Excel spreadsheet.

The application automatically:

Reads the file
Detects columns
Generates variables
Shows a preview before sending

Example data:

Name	Company	Email
John	Tesla	john@example.com
Sarah	Netflix	sarah@example.com

The detected columns become variables like:

{{Name}}
{{Company}}
{{Email}}

Code – app/api/readExcel/route.ts

import { NextRequest, NextResponse } from 'next/server';
import * as XLSX from 'xlsx';

export async function POST(request: NextRequest) {
  try {
    const formData = await request.formData();
    const file = formData.get('excel') as File;

    const bytes = await file.arrayBuffer();
    const buffer = Buffer.from(bytes);

    const workbook = XLSX.read(buffer, {
      type: 'buffer',
    });

    const sheet =
      workbook.Sheets[workbook.SheetNames[0]];

    const rows =
      XLSX.utils.sheet_to_json(sheet);

    const columns =
      Object.keys(rows[0] || {});

    return NextResponse.json({
      columns,
      allData: rows,
      preview: rows.slice(0, 5),
    });
  } catch {
    return NextResponse.json({
      columns: [],
      allData: [],
      preview: [],
    });
  }
}

Step 3: Write Email & Send (Live Preview)

Write your email once using variables.

Example:

Hi {{Name}},

I came across {{Company}} and wanted to connect.

Best,
Suresh

The application automatically personalizes every email.

Frontend – app/page.tsx

const insertVariable = (variable: string) => {
  const insertion = `{{${variable}}}`;

  switch (activeField) {
    case 'to':
      setTo(
        prev =>
          prev +
          (prev ? ' ' : '') +
          insertion
      );
      break;

    case 'body':
      const start =
        textarea.selectionStart;

      const end =
        textarea.selectionEnd;

      const newText =
        body.substring(0, start) +
        insertion +
        body.substring(end);

      setBody(newText);
      break;
  }
};

Backend – app/api/sendEmails/route.ts

const transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: senderEmail,
    pass: senderPassword,
  },
});

for (const row of rows) {
  await transporter.sendMail({
    to: replaceVariables(toTemplate, row),
    subject: replaceVariables(
      subjectTemplate,
      row
    ),
    html: markdownToHtml(
      bodyTemplate,
      row
    ),
  });

  await new Promise(resolve =>
    setTimeout(resolve, 1000)
  );
}

Helper Functions

function replaceVariables(
  template: string,
  row: any
) {
  return template.replace(
    /{{(.*?)}}/g,
    (_, key) => row[key.trim()] || ''
  );
}

function markdownToHtml(
  markdown: string,
  row: any
) {
  const withVars =
    replaceVariables(markdown, row);

  return withVars.replace(
    /\*\*(.*?)\*\*/g,
    '<strong>$1</strong>'
  );
}

The Privacy Design

Most bulk email tools store your Gmail credentials somewhere.

This one doesn't.

The flow is simple:

Enter credentials
       ↓
Verify credentials
       ↓
Send emails
       ↓
Request ends
       ↓
Memory cleared

No database.

No Redis.

No log file.

No .env.

No stored credentials.

Tradeoff?

You enter credentials each session.

Benefit?

Nothing sensitive remains after the request completes.

What Broke The First Time

The first version worked perfectly.

Until I tried sending 100 emails.

I fired requests as fast as Node.js could loop.

By email #47 Gmail responded with:

User rate limit exceeded

The remaining emails never sent.

That forced me to learn Gmail's sending limits and add throttling.

Rate Limiting (The 1-Second Delay)

The fix was surprisingly simple:

await new Promise(resolve =>
  setTimeout(resolve, 1000)
);

One second per email.

100 emails = roughly 100 seconds.

A little slower.

A lot more reliable.

Lessons Learned

Building the tool took a few hours.

Making it reliable took longer.

A few things I learned:

Gmail rate limits matter
Simplicity is often a security feature
Excel is still the easiest format for non-technical users
Small tools solving real problems are often the most useful projects

Sometimes the best side projects aren't startups.

They're solutions to annoyances you face every week.

Tech Stack

Next.js 15
TypeScript
Nodemailer
XLSX
Tailwind CSS
Vercel

Future Improvements

A few features I'm considering:

Scheduled campaigns
Retry queue
CSV support
Email analytics
Progress tracking
Background processing

Try It Yourself

🚀 Live Demo

https://bulk-mail-sender-lilac.vercel.app/

📂 Source Code

https://github.com/Suresh4405/BulkMail-Sender

👨‍💻 Portfolio

https://sureshcodes.vercel.app/

From 3 hours of copy-pasting to 2 minutes of automation.

Built in one evening with Next.js, Nodemailer, and zero stored credentials.

If you've ever had to send hundreds of personalized emails manually, leave a 🧡 and tell me how you're solving it.