DEV Community: mhk sameera

Cutting Through the LinkedIn Noise: Show Your Real, Deployed App — Not Your Title

mhk sameera — Wed, 23 Sep 2026 07:53:43 +0000

LinkedIn right now is wall-to-wall "Software Engineer | Full Stack Developer | AI Enthusiast | Open to Work" — and almost none of it tells you anything. A title is not proof you can build something. It's not proof you can ship something. It's definitely not proof you can be trusted with someone else's product.

So here's a simple idea instead of another opinion post: show the app, not the title.

The rule

Drop a comment with:

A live link — it has to actually work when someone clicks it right now.
One line on what it does and who it's for.
Your stack.

That's it. No "I'm a passionate developer" preamble, no CV, no "DM me." Just the proof.

If you don't have a deployed project yet, you still belong here. Drop what you're currently building, even unfinished, even with zero users — a personal project, something from a course that you extended yourself, whatever you're actually working on right now. The bar isn't "impressive," it's "real and yours." This is meant to surface actual work at every stage, not just finished products with traction.

What counts

This is for work you actually built — not a tutorial clone with your name swapped in, not a Figma mockup with no backend. It can be small. It can be in progress. It can have zero users. It just has to be something you're genuinely building or shipped yourself, not a copy-paste.

If it's not live anymore, say so and link a video walkthrough instead — that's fine, dead links aren't.

Why I think this is worth doing

I'm a solo full-stack developer myself, and I'm tired of scrolling past the same recycled "10 tips to become a 10x developer" carousel to find literally anyone showing actual work. The signal-to-noise ratio on tech LinkedIn right now is bad, and it's bad in both directions:

For developers at every stage — from someone learning their first framework to someone who's shipped ten products — your work is buried under personal branding and titles that say nothing. This isn't about ranking who's "more real." It's about making it possible to find actual work at all, whatever stage it's at.
For recruiters and founders, there's no fast way to see what someone can actually do, versus how well they write about themselves.

A thread where the currency is a real link — finished or not, big or small — fixes both problems at once. You can't fake something that actually exists.

For recruiters and anyone hiring

If you're looking for a solo full-stack developer — someone who can own a project front to back — this is a faster filter than a hundred LinkedIn profiles. You'll see everything from early-career developers actively building, to people with years of deployed, real-world products. Judge the actual work directly instead of a résumé describing it.

Keeping it going

I'll post this as a LinkedIn thread and keep it pinned. Reply with your project any time — this isn't a one-day thing, it's meant to keep collecting real, live work so it's still useful a month from now, not just for the first 48 hours.

If you've got something real — shipped or still in progress — drop it below. Link, what it does, stack. Let's see what people are actually building, at every stage.

You Expect Corolla Pricing but Ordered Lamborghini Options — What a Bad WordPress Job Taught Me About Discounts

mhk sameera — Mon, 21 Sep 2026 10:12:53 +0000

The conversation goes the same way almost every time a new client comes in.

They ask the cost. I ask what they actually need. I send a quote. "That's expensive." I walk through exactly what's in it, line by line. Still expensive. I offer a small discount to keep the relationship. They come back asking for more.

HI used to keep giving. Then a Canadian client taught me why that habit was going to cost me a lot more than money.

The job that changed how I quote

This client bargained hard, I dropped my price to close the deal, and the scope was small: a few updates to their existing WordPress site. I'm not a big fan of WordPress — I'll say that upfront, it colors this story — but it was a small job at a reduced rate, so I said yes.

"A few updates" did not stay a few updates. One small ask led to another, which needed a plugin that conflicted with another plugin, which needed a theme change, which broke something else. Each individual request sounded reasonable on its own. Together, they added up to rebuilding the entire site from scratch — at the price I'd agreed to for a handful of tweaks.

I did it. I finished the job. And I lost money and time on a client I'd already discounted to win.

What I actually did wrong

It wasn't agreeing to a discount. It was agreeing to a discount without re-scoping the moment the ask changed. Every "can you also just..." should have been a new estimate, not a favor squeezed into the old one. I said yes to the relationship instead of saying yes to a number, and by the time I noticed how far the scope had moved, I'd already done half the extra work for free.

What I say now

When a client pushes for a lower price after I've already explained the quote, I tell them straight:

"You're expecting Corolla pricing, but what you've asked for is Lamborghini options. You'll get exactly what you pay for."

It sounds blunt written down. In conversation it isn't — it's said plainly, not angrily, and it does something a longer explanation doesn't: it makes the mismatch obvious in one sentence. A client who wants custom logic, clean code, and something that won't break in six months is not shopping in the same category as a client who wants the cheapest possible build. Both are valid. They're not the same job.

What changed in how I run projects since then

The quote has a defined scope, in writing, before anything starts. Not "a few updates" — an actual list.
A discount is a number, not a mood. If I reduce the price, the scope shrinks to match it. I say that out loud when I offer the discount, not after the client tries to expand the work.
"Can you also just—" gets a real answer: "Sure, that's outside the current scope, here's what it adds." Every time, no exceptions, said the same calm way whether it's the first ask or the fifth.
I stopped treating discount requests as a negotiation I have to win by conceding. Explaining the quote once is fair. Explaining it three times while lowering the number each time teaches the client that pushback is how you get a cheaper Claude — sorry, cheaper developer.
I'm honest about not loving certain platforms going in. If I'm not a WordPress person and the job is a WordPress site, the client should hear that before I quote, not discover it when something breaks.
If the number doesn't work, I walk. Not every negotiation ends in a deal, and that's fine. I'd rather sleep well or watch a movie than take a job at a price that means I'm working for free by week two. Saying no to a bad price is cheaper than saying yes and resenting the project for the next month.

Why I think this is worth sharing

Every freelancer or agency dev has some version of this story. The details change — the platform, the client, the country — but the shape is identical: discount granted, scope quietly expands, developer eats the difference because walking away mid-project feels worse than finishing at a loss.

The fix isn't "don't give discounts" or "don't take small jobs." It's that price and scope have to move together, every time, out loud, before the work happens — not after you're three unpaid hours into a rebuild you didn't agree to.

What's your version of the Corolla line? Every developer I know has one phrase that ends these conversations — I'd like to hear yours.

AI Built My Site in an Hour, Why Are You Charging So Much? — 4 Questions That Usually End the Conversation

mhk sameera — Sun, 20 Sep 2026 07:16:31 +0000

I've had this conversation more times this year than in the previous five combined.

A client sends me a link. It's a genuinely nice-looking site — clean layout, good copy, responsive, built with an AI tool in an afternoon. Then comes the quote for the actual project, and the pushback:

"But I already built it. Why do I need to pay this much for web development?"

I don't argue. I ask four questions.

The four questions

Where is this going to be hosted?
How does the contact form actually send an email?
Who's going to point the domain and set up DNS?
Who's connecting this to a database?

I've asked some version of this to maybe a dozen clients this year. Not one has had an answer to all four. Most have an answer to zero.

And that's not a gotcha — it's the actual finding. What the AI tool built is a frontend. What the client thinks they have is a website. Those are not the same thing, and the gap between them is most of what I do for a living.

Why this keeps happening

It's not that clients are being difficult. The tools are genuinely good now, and "generate a working UI from a prompt" is a real, valuable thing that used to take a developer a week. I'm not going to pretend otherwise — some of what shows up in my inbox now is better-looking than what agencies were charging thousands for three years ago.

The problem is the tools stop exactly where the visible part ends. A generated page runs perfectly in the preview pane because the preview pane doesn't need a domain, doesn't send real email, doesn't persist data, and isn't reachable by the public internet. Every one of those is invisible until you try to actually launch.

So the client's mental model is "the site is done, I just need someone to put it online" — and mine is "the UI is done, and everything that makes it a product hasn't started."

What's actually missing, one question at a time

1. Hosting

A static export needs somewhere to live — Vercel, Netlify, a VPS — and someone has to choose based on what the site actually does. A pure static site is one decision. A site with a contact form, a login, or a database is a completely different one, with servers, environment variables, and a deploy pipeline. "Where does this run" is rarely a five-minute answer, and it's never zero cost.

2. The contact form

This is the one that trips up the most clients, because it looks finished. They fill it in, hit submit, nothing visibly breaks — and nothing happens on the other end either, because there's no backend to receive it.

A real contact form needs: an endpoint to POST to, a way to send the email (SMTP, Resend, SendGrid...), spam protection, and validation so someone can't inject garbage or a script into it. None of that exists in a frontend-only build. I've had a client swear their form "worked" because the button had a nice hover animation.

3. DNS and the domain

Buying a domain from GoDaddy or Namecheap is step one, not step ten. Someone still has to point A/CNAME records at the host, add MX records if email should work on that domain, set up SSL, and get www and the bare domain to agree on which one redirects to the other. Get this wrong and the site is either unreachable or half-secure. Every client I've asked has assumed this "just happens" when you buy the domain.

4. The database

If the site needs to store anything — leads, bookings, products, user accounts — a frontend has nothing to talk to. Someone has to choose a database, design the schema, write the API that the frontend calls, secure it so it isn't wide open to the internet, and back it up. This is usually the biggest gap, and the one clients understand the least, because in the AI tool's preview, fake data just... appears.

The tone I try to take

I don't lead with "well actually, you don't know what you're talking about." Two things are both true at once: the client got real value out of the AI tool, and they're about to find out the hard way that value stopped short of a working product.

So I ask the four questions, let the silence answer them, and then say something like: "What you've got is a genuinely solid starting point — better than a lot of what I used to have to build from scratch. What's left is the part that doesn't show up in a demo: hosting, the form actually working, DNS, and a database if you need one. That's what the quote covers."

Most clients relax once they understand what they're actually paying for isn't "building the site" — they already half-did that — it's making it real.

For other developers

Steal the four questions. They're not a trick, they're a genuinely fast way to find the edge of what a client has versus what they think they have, without a long technical explanation. Ask them early, in the first call, before you scope anything. The answers tell you exactly how much of the conversation you still need to have.

If you're getting this pushback too, what's your version of these four questions? I'd like to add to the list.

I Built a Services Marketplace, Never Had Time to Run It, So I Open-Sourced All of It

mhk sameera — Thu, 17 Sep 2026 12:04:20 +0000

Last week I published the complete source code of a services marketplace I built and deployed — a finished product, live at skilllanka.com, with payments, video, escrow and admin tooling all wired up. Not a tutorial project, not a starter template. The actual thing, minus the users I never had time to go and get.

It's called SkillHub on GitHub, it's MIT licensed, and you can clone it, rebrand it in two config files, and run your own marketplace with it.

Repo: https://github.com/Sameera-MHK/service_marketplace

This post is about why I did that, and a walkthrough of the one piece of it I'm most proud of: the trust score.

What it is

A two-sided marketplace for local services — think plumbers, tutors, designers, trainers — with a business directory bolted on. Four roles:

Clients browse verified professionals, post jobs, book paid consultations, join live video classes, buy from a Pro's storefront, rate work, raise disputes.
Pros onboard with ID verification, get a scored public profile, receive leads, sell consultations and classes, run a shop, request payouts, subscribe to a plan.
Businesses register a company profile with services, photos and opening hours.
Admins moderate, verify IDs, resolve disputes, approve payouts, set commissions, and read an audit log.

Under the hood: escrow-style job flow (30% deposit, balance released on client confirmation), a commission engine with per-category and per-Pro overrides, Free/Pro/Elite subscription tiers, LiveKit video, Stripe, i18n with a data-driven locale registry, and server-rendered Open Graph tags so links preview properly.

Stack is React 18 + Vite + Tailwind on the front, Node + Express + Mongoose on the back. 21 models, 17 route modules, and every third-party integration is optional — without Stripe the payment endpoints return a clear error, without Cloudinary uploads go to local disk, without SMTP emails print to the console. You can run the whole thing with just MongoDB and two JWT secrets.

Why open-source a production app?

About a year ago I had an idea: a services marketplace for the Sri Lankan market. Sri Lanka has a huge pool of skilled tradespeople and freelancers, and no good platform connecting them to clients with any kind of trust layer. I designed it, built it, and deployed it at skilllanka.com — it's still up if you want to click around.

Then reality. I run a SaaS company, a social media agency, and a steady flow of client development work. A marketplace doesn't grow by existing — it grows by someone promoting it every day, onboarding Pros one by one, answering support, posting on social media, chasing the first hundred users. I never had the time to be that person. The code was finished and deployed. The business side never started — no marketing, no Pro onboarding drive, and so no real users. A marketplace with zero users is just a very complete demo.

I could have let it sit in a private repo. But a complete, working marketplace is worth far more in someone else's hands than it is idle in mine. Maybe someone in Sri Lanka, or Kenya, or the Philippines, or a small town anywhere, wants to be a marketplace entrepreneur and just needs the product part already done. That's who this is for.

One honest note on how it was built: the idea, the architecture, the data model, the trust score design and the business logic are mine. For the actual coding I worked with AI assistants throughout — this is a lot of code for one person, and I'd rather say so than pretend otherwise. It's deployed and running, every flow is exercised end to end with the seeded data, and Stripe runs in test mode. What it hasn't had is real traffic — that's the part I'm handing over.

Before releasing it I spent a couple of weeks doing what most open-source dumps skip:

Stripped every brand, region, currency, price and legal line into two config files driven by environment variables
Wrote real docs — configuration, architecture, API, deployment, and a guide to hosting a demo
Added a seed script that creates 20 Pros, 6 businesses, 5 clients and jobs in every state, so you can see the whole app working in five minutes
Wrote a SECURITY.md that says plainly what the code does and doesn't protect against

And then I put a note at the top of the README: shared as-is, not actively maintained. Fork it, make it yours, don't expect me to answer issues. I'd rather be upfront than let people wait on PRs that won't get merged.

The trust score: how to rank professionals without getting gamed

Every marketplace has the same problem. You need to rank providers, and the obvious signal — average star rating — is terrible.

A Pro with three 5-star reviews from their friends shows 5.0. A Pro with 200 real jobs averaging 4.6 shows 4.6. The new guy wins. Your best professional loses.

So the score in SkillHub is a 0–100 composite of five signals, recomputed on every job event:

Signal	Weight	What it measures
Completion	30%	Jobs completed vs cancelled by the Pro
Rating	25%	Client ratings — Bayesian-adjusted and time-decayed
Responsiveness	20%	Average response time to leads
Disputes	15%	Disputes lost to the client, as a rate
Trust signals	10%	ID verified, trade certification, referred by a high-score Pro

The bands: Elite 90+, Trusted 75–89, Rising 55–74, Probation 35–54, Suspended ≤34.

Most of those are simple ratios. The rating signal is where the real work is.

Fixing the "three friends" problem: Bayesian shrinkage

Instead of trusting a Pro's raw average, we pull it toward the platform average until they've earned enough reviews to stand on their own.

const PLATFORM_MEAN_RATING = 4.2;   // what a typical Pro on the platform scores
const BAYESIAN_THRESHOLD = 30;      // how many reviews before we mostly trust yours

const v = ratedJobs.length;
const bayesianAdj =
  (v * weightedMean + BAYESIAN_THRESHOLD * PLATFORM_MEAN_RATING) / (v + BAYESIAN_THRESHOLD);

This is the same formula IMDb uses for its Top 250. Run the numbers:

3 reviews, all 5 stars: (3 × 5.0 + 30 × 4.2) / 33 = 4.27
200 reviews averaging 4.6: (200 × 4.6 + 30 × 4.2) / 230 = 4.55

The experienced Pro wins. The new Pro isn't punished — 4.27 is above the platform average — they just haven't proved anything yet. Get to 30 reviews and your own average carries about half the weight; at 100+ it's nearly all yours.

Fixing the "coasting" problem: time decay

The second problem: a Pro who was excellent two years ago and mediocre since. A plain average barely moves.

So each rating is weighted by how old it is:

const DECAY_LAMBDA = 0.003;  // per day

const weights = ratedJobs.map((j) => Math.exp(-DECAY_LAMBDA * daysAgo(j.createdAt)));
const weightedMean =
  ratedJobs.reduce((sum, j, i) => sum + j.workerRating * weights[i], 0) /
  weights.reduce((a, b) => a + b, 0);

At λ = 0.003, a rating's weight halves roughly every 230 days. A one-year-old review counts for about a third of a fresh one. A three-year-old review is nearly noise. Recent behaviour dominates, but history isn't erased.

Then the adjusted rating on a 1–5 scale is mapped to 0–100:

ratingScore = Math.round(((bayesianAdj - 1) / 4) * 100);

The parts that aren't math: caps and hard overrides

Weighted averages are fair, but a marketplace also needs rules that can't be averaged away.

// No ID verification? You can't score above 70, no matter how good your numbers are.
if (!user.idVerified) skillScore = Math.min(skillScore, 70);

// Lose two disputes in 30 days and you're suspended, full stop.
if (recentDisputesLost >= 2) {
  profile.isSuspended = true;
  skillScore = Math.min(skillScore, 34);
}

// Fraud flag from the moderation service: score goes to zero.
if (profile.fraudFlag) { skillScore = 0; scoreBand = 'suspended'; }

The ID cap is the one I'd defend hardest. It means "Trusted" and "Elite" on this platform always means a real, verified human. You can't buy your way there with reviews.

What I got wrong the first time

The first version used a plain average and a simple job count. Even with seeded test data the failure mode was obvious: new Pros with a handful of perfect reviews sitting above people with dozens of jobs. The composite score with shrinkage and decay was the second attempt, and it's the one that shipped.

The full function is about 120 lines: server/services/scoreService.js. Every constant is at the top. If your platform's ratings skew higher or lower than 4.2, change one number.

If you want to use it

git clone https://github.com/Sameera-MHK/service_marketplace skillhub
cd skillhub/server && npm install && cp .env.example .env
# set MONGO_URI, JWT_SECRET, JWT_REFRESH_SECRET
npm run dev
cd ../client && npm install && cp .env.example .env.local && npm run dev
cd ../server && npm run reseed

Log in as admin@skillhub.example.com / Admin123! and you've got a fully populated marketplace on localhost. Rebranding is client/src/config/site.js and server/config/site.js. Deployment guide, API reference and architecture docs are in /docs.

Things to know before you ship it:

The legal pages are sample text. Get a lawyer.
The bundled photos are placeholders. Replace them.
Change every seeded password.
Read SECURITY.md. It tells you what's your job.

What's actually in it that took the longest

For anyone building a marketplace from scratch, the features that ate the most time — and that you get for free here:

The commission engine. Platform default → per-category rate → per-Pro override → volume tiers, resolved in priority order per transaction type. Every marketplace gets this wrong the first time.
Escrow job flow with disputes. Deposit, hold, release on confirmation, admin resolution path. The state machine has more edges than you'd think.
Graceful degradation. Making every integration optional without if (stripe) scattered through 50 files. It's a service layer with no-op fallbacks, and it's what makes the repo usable by a stranger in five minutes.
Trust score. Above.

If you fork it and build something, I'd like to see it. And if you've solved the provider-ranking problem differently — a different prior, a different decay, something learned — tell me in the comments. I'm sure this isn't the last word on it.

I Connected Claude to 20 Years of Azure SQL Data with a Custom MCP Server. Here's How.

mhk sameera — Tue, 15 Sep 2026 10:08:03 +0000

A client came to me with a request that sounded simple:

"We have 20 years of data in our database. We want our managers to ask Claude questions and get reports. Marketing, HR, R&D, Production, Procurement, Sales — all of them."

No dashboards, no BI tool, no SQL training. Just: type a question, get an answer from the actual data.

The database is Azure SQL. It's been growing since the mid-2000s. It has hundreds of tables — real business data, but also legacy tables nobody remembers, staging tables, system tables, half-finished migrations, and a lot of columns that would confuse a human, let alone a language model.

Here's how I built it, what I got right, and what I'd tighten up next.

The architecture

Claude (each manager's account)
        │
        │  HTTPS + secret key
        ▼
mcp.company-domain.com  ──►  Nginx (reverse proxy, SSL)
                                    │
                                    ▼
                        Node.js MCP server on the company VPS
                        (table whitelist lives here)
                        + knowledge base table (which tables matter per department)
                                    │
                                    │  read-only SQL user
                                    ▼
                              Azure SQL Database

Four decisions drove everything:

Self-host the MCP server on the client's own VPS. The data path is Claude → their server → their DB. No third-party middleware sitting on 20 years of business data.
Whitelist tables at the MCP layer. Claude never sees the tables that aren't on the list. It can't query what it doesn't know exists.
Read-only database user. The MCP server connects with a SQL login that can only SELECT. A hallucinated DELETE is a syntax error, not a disaster.
One shared key, small audience. More on this tradeoff below.

Step 1: The MCP server

MCP (Model Context Protocol) is the standard Claude uses to talk to external tools. You write a server that exposes "tools" — functions with a name, a description, and a schema — and Claude decides when to call them.

I built it in Node.js with the official SDK. Stripped down, the core looks like this:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import sql from "mssql";
import { z } from "zod";

const ALLOWED_TABLES = [
  "SalesOrders",
  "SalesOrderLines",
  "Customers",
  "Products",
  "Suppliers",
  "PurchaseOrders",
  "ProductionBatches",
  "Employees",          // no salary columns exposed — see below
  // ... one line per table each department needs
];

const server = new McpServer({ name: "company-data", version: "1.0.0" });

// Tool 1: let Claude discover what it's allowed to see
server.tool("list_tables", "List the tables available for querying", {}, async () => ({
  content: [{ type: "text", text: ALLOWED_TABLES.join("\n") }],
}));

// Tool 2: schema for a whitelisted table
server.tool(
  "describe_table",
  "Get columns and types for a table",
  { table: z.string() },
  async ({ table }) => {
    if (!ALLOWED_TABLES.includes(table)) {
      return { content: [{ type: "text", text: `Table '${table}' is not available.` }] };
    }
    const result = await pool.request()
      .input("t", sql.NVarChar, table)
      .query(`SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = @t`);
    return { content: [{ type: "text", text: JSON.stringify(result.recordset, null, 2) }] };
  }
);

// Tool 3: run a read-only query
server.tool(
  "run_query",
  "Run a SELECT query against allowed tables. Max 500 rows.",
  { query: z.string() },
  async ({ query }) => {
    const q = query.trim();
    if (!/^select\s/i.test(q)) {
      return { content: [{ type: "text", text: "Only SELECT statements are allowed." }] };
    }
    for (const t of extractTableNames(q)) {
      if (!ALLOWED_TABLES.includes(t)) {
        return { content: [{ type: "text", text: `Table '${t}' is not available.` }] };
      }
    }
    const result = await pool.request().query(`SELECT TOP 500 * FROM (${q}) AS sub`);
    return { content: [{ type: "text", text: JSON.stringify(result.recordset) }] };
  }
);

Three layers of protection on run_query:

Regex rejects anything that isn't a SELECT.
Every table referenced in the query is checked against the whitelist.
Even if both of those somehow failed, the SQL login itself is read-only.

Defence in depth. Any one layer could have a bug; all three at once is unlikely.

Step 2: Whitelisting — the part that made it work

The instinct is to give Claude the whole schema and let it figure things out. Don't.

With hundreds of tables, Claude picks the wrong one constantly. There were three different "customer" tables from three different eras of the system. There were tables with _old, _bak, _v2 suffixes. There were tables with 80 columns where 70 were unused.

The whitelist solves two problems at once:

Security — sensitive and irrelevant tables are invisible.
Accuracy — Claude only has to reason about the tables that matter, so it picks the right one.

The whitelist lives in the server code. When a department needs a new table, I add one line and redeploy. That's deliberately manual — I want a human to look at every table before Claude can see it.

For the Employees table, I went one step further and exposed a SQL view with the sensitive columns removed, rather than the raw table. The view name goes on the whitelist; the table doesn't.

Step 2.5: The knowledge base table

Whitelisting fixed what Claude can see. It didn't fix which table Claude should reach for when someone from Marketing asks a Marketing question.

So I added one more table to the database — a knowledge base that describes the other tables in plain English:

CREATE TABLE mcp_knowledge_base (
  department   NVARCHAR(50),    -- Marketing, HR, RnD, Production, Procurement, Sales
  table_name   NVARCHAR(128),
  description  NVARCHAR(MAX),   -- what this table holds, in business language
  key_columns  NVARCHAR(MAX),   -- the columns that matter and what they mean
  notes        NVARCHAR(MAX)    -- gotchas: "status 3 means cancelled", "amounts in AED", etc.
);

And a fourth tool on the MCP server:

server.tool(
  "get_table_guide",
  "Find which tables are relevant for a department or topic, with descriptions",
  { topic: z.string() },
  async ({ topic }) => {
    const result = await pool.request()
      .input("t", sql.NVarChar, `%${topic}%`)
      .query(`SELECT department, table_name, description, key_columns, notes
              FROM mcp_knowledge_base
              WHERE department LIKE @t OR description LIKE @t OR table_name LIKE @t`);
    return { content: [{ type: "text", text: JSON.stringify(result.recordset, null, 2) }] };
  }
);

Now when a manager asks about campaign performance, Claude calls get_table_guide("marketing"), gets back the three or four tables that actually matter with a description of each, and goes straight to them — instead of scanning fifty table names and guessing.

This table is the one thing the client's team updates themselves. When a column's meaning changes or a new report pattern emerges, they add a row. No code change, no redeploy. It's turned into a living data dictionary — something this company never had in 20 years — and it exists because an LLM needed it.

Two rules for writing the descriptions: write for a smart new employee, not a DBA, and put the gotchas in. "Amounts are in AED excluding VAT" saves Claude from a wrong answer far more often than a perfect schema does.

Step 3: Nginx in front

The MCP server runs on a local port on the VPS. Nginx sits in front on a company subdomain with an SSL certificate from Let's Encrypt.

server {
    listen 443 ssl;
    server_name mcp.company-domain.com;

    ssl_certificate     /etc/letsencrypt/live/mcp.company-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mcp.company-domain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:7544;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

Two lines matter more than they look:

The Upgrade / Connection headers. MCP uses long-lived streaming connections. Without these, Nginx treats it as a plain HTTP request and the connection drops.
The 300-second timeouts. Nginx defaults to 60s. Some of these queries run against 20 years of data. A report that takes 90 seconds to aggregate would silently fail with the defaults. Five minutes was the point where every real query finished.

Step 4: Connecting Claude

Each manager adds the server in Claude as a custom connector: the subdomain URL plus the shared secret key. That's it — no software to install.

To start a session, the user types the name of the MCP server in their first message so Claude knows to use it. After that, they just ask questions in plain English:

"Compare procurement spend by supplier for the last three quarters and flag any supplier where cost per unit went up more than 10%."

Claude calls get_table_guide("procurement"), reads which tables matter and what the columns mean, calls describe_table where it needs more detail, writes the SQL, calls run_query, and turns the result into a readable answer — a table, a summary, sometimes a chart.

Anyone in the company whose Claude account doesn't have the connector configured gets nothing. Claude has no knowledge of the data on its own.

The tradeoff I made on purpose: one shared key

The client asked for a single shared key. The audience is a small group — CEO, CFO, general managers, department heads. People who already have cross-department visibility. Managing per-user keys for a group that size would have been more admin work than security benefit.

I agreed, with two conditions: the key stays with senior management only, and the DB user stays read-only so the worst case is "someone saw a report they shouldn't have," not "someone changed data."

Where this would break: if access expands to 50 people, or if departments genuinely need to be isolated from each other (HR from Sales, say), the shared key stops being acceptable. At that point the right move is per-department keys mapped to per-department whitelists, or OAuth through Claude's connector system so access follows the user's identity. The code change is small; the policy change is the hard part.

What I'd tighten next

Being honest about the gaps:

Audit log. Every query, who ran it, when, how many rows. This is a five-line addition and the client will want it the first time someone asks "who looked at that?"
Rate limiting on the endpoint. A leaked key today means unlimited reads. A rate limit caps the damage.
Whitelist as config, not code. A JSON file or a small admin table so the client can add tables without me redeploying.
Row limits per table. TOP 500 is a global cap. Some tables should be lower.
Query cost guard. Reject queries with no WHERE on the very large tables.

Was it worth it?

The client went from "ask IT for a report, wait three days" to "ask Claude, wait thirty seconds." Managers who never touched SQL are pulling supplier comparisons, production yield trends, and sales-by-region breakdowns themselves.

The whole thing is about 300 lines of Node, one Nginx config, a read-only SQL user, and one knowledge base table that the client now maintains themselves. The hard parts weren't technical — they were deciding what Claude should be allowed to see, and being disciplined about saying no to the rest.

If you've connected an LLM to a legacy database, I'd like to hear how you handled the "too many tables" problem — whitelist, views, semantic layer, something else?

The Good, The Bad, and The Hydration Errors: Migrating a Production React SPA to Next.js App Router

mhk sameera — Sun, 13 Sep 2026 17:39:24 +0000

Two and a half years ago I built a corporate website for a Dubai-based food manufacturer as a plain React SPA — about 20 pages covering their brands, factories, product categories and export markets. Create React App, react-router, useEffect for data, react-helmet for meta tags. It looked good and the client was happy.

Then the SEO reports came in. The company sells in 50+ countries, and search is where their distributors and private-label buyers find them. A client-rendered SPA where Google sees an empty <div id="root"> and a loading spinner is a bad place to be.

So I rewrote it in Next.js App Router. Not "migrated" — rewrote. Every single file. With two hard constraints from the client:

Every URL stays exactly the same. /about, /our-brands, /private-labels, /travel-retail — all of it. Years of indexed pages and backlinks were not going to be thrown away.
The site has to look identical. No redesign. Users should not notice anything changed except that it's faster.

Here's what that actually involved.

Why a full rewrite instead of incremental migration

Everyone recommends incremental migration. I tried for about two days and gave up.

The SPA's architecture was fundamentally client-first: routing in react-router, data fetching in components, layout state in context providers wrapping the whole tree. App Router wants the opposite — server-first, with client interactivity as the exception. Trying to run both mental models in one codebase meant every component needed a "which world am I in?" check.

For a ~20-page marketing site, a clean rewrite was faster than a careful migration. If you have a 200-page app with complex client state, your answer might be different. But don't assume incremental is always the right call.

Step 1: Routes — react-router to the file system

This was the easy part, and the most important one for SEO.

Old:

<Route path="/confectionery" element={<Confectionery />} />
<Route path="/snacks" element={<Snacks />} />
<Route path="/our-brands" element={<Brands />} />

New:

app/
  confectionery/page.tsx
  snacks/page.tsx
  our-brands/page.tsx

One folder per route, named exactly as the old path. I literally opened the old router file and created folders line by line. Then I ran a script against the old sitemap to hit every URL on the new build and check for 200s.

Two gotchas:

Trailing slashes. The old SPA served /about and /about/ identically. Next.js redirects one to the other by default. Check which version Google had indexed and set trailingSlash in next.config.js to match.
Legacy URLs you forgot about. Old PDFs, a /catalogue vs /catalog spelling inconsistency, a factory page that had been linked from a partner site. Grep your analytics for every path that got a hit in the last year and add redirects() for anything that doesn't map cleanly.

Step 2: The Server vs Client Component split

This is where the real work was, and where the mental model shift happens.

My rule became: everything is a Server Component until it can't be.

What stayed on the server (most of it):

Page layouts, headers, footers
Static content sections — text, images, brand grids, factory listings
Anything reading from a CMS or JSON at build time

What had to become 'use client':

The mobile navigation (needs useState for open/close)
Image carousels and sliders
The hero video with a mute/unmute button
The contact form (form state, validation, submit)
Anything using framer-motion or scroll-triggered animations
Anything touching window, document, or localStorage

The trap I fell into early: marking a whole page 'use client' because one small piece needed interactivity. That throws away the entire point of the migration. The fix is to push the client boundary as far down as possible — the button is a client component, the section containing it stays on the server.

// app/about/page.tsx — Server Component, no directive
import HeroVideo from './HeroVideo'; // 'use client' lives in here

export default function AboutPage() {
  return (
    <>
      <section>...static content, rendered on server...</section>
      <HeroVideo src="..." />   {/* only this hydrates */}
    </>
  );
}

Step 3: Data fetching — killing useEffect

The old site had this pattern everywhere:

const [brands, setBrands] = useState([]);
useEffect(() => {
  fetch('/api/brands').then(r => r.json()).then(setBrands);
}, []);

Loading spinner, then content. Google sees the spinner.

In App Router, the component is async and just fetches:

export default async function BrandsPage() {
  const brands = await getBrands();
  return <BrandGrid brands={brands} />;
}

No loading state, no spinner, HTML arrives with the content in it. This one change is 80% of the SEO win.

Step 4: Meta tags — react-helmet to the Metadata API

The old site used react-helmet to set titles and descriptions client-side. Which means crawlers that don't execute JS never saw them.

App Router has this built in:

export const metadata = {
  title: 'Company Name | Confectionery, Date & Snack Brands from Dubai',
  description: '...',
  openGraph: { images: ['...'], type: 'website' },
  alternates: { canonical: 'https://example.com' },
};

Per page, statically, in the HTML. I also added sitemap.ts and robots.ts in the app folder so those are generated automatically instead of being hand-maintained files that drift out of date.

Step 5: Images

The SPA used plain <img> tags pointing at Cloudinary. I kept Cloudinary but wrapped everything in next/image with a custom loader so I got proper srcset, lazy loading, and no layout shift — without moving 200+ images anywhere.

One annoyance: next/image requires width and height (or fill). The old code had none of that. I spent an afternoon adding dimensions. Worth it — CLS dropped to nearly zero.

The Bad: Hydration errors

Now the part from the title.

A hydration error happens when the HTML the server rendered doesn't match what React renders on the client's first pass. React then throws away the server HTML and re-renders from scratch — which is slow, ugly, and defeats the purpose.

Where they came from in this project:

window and localStorage checks in render. Any typeof window !== 'undefined' branch that changes output. Server takes one path, client takes another, mismatch. Fix: move it into useEffect, or render a neutral state first.
Dates and locales. new Date().getFullYear() in the footer copyright. Rendered on a server in one timezone, hydrated in a browser in another — usually fine, until it's midnight somewhere. Fix: compute it once and pass it as a prop, or accept it's a client component.
Third-party scripts injecting DOM. A chat widget and an analytics tag both modified the body before React hydrated. Fix: load them with next/script using strategy="afterInteractive".
Nested <a> tags. The old site had a card component that was an <a> wrapping content that also contained an <a>. Browsers silently "fix" invalid HTML, and the fixed version doesn't match React's output. Fix: fix your HTML.
Random IDs. A component generated Math.random() IDs for accessibility attributes. Different on server and client every time. Fix: useId().

Debugging tip: the error message in dev tells you which element mismatched. Don't ignore it and don't suppress it with suppressHydrationWarning unless you understand exactly why (the footer year is the one legitimate case).

Step 6: The contact form

The old form POSTed to an external service from the client. I moved it to a Route Handler at app/api/contact/route.ts — the API key is now server-side only, I added server validation with Zod, and rate limiting so the form can't be spammed. (If you read my last post, you know why I care about this now.)

Step 7: Caching — the part nobody explains well

App Router caches aggressively by default, and the rules changed between versions. For a marketing site the simple approach is:

Pages with content that rarely changes: let them be static. Build once, serve from CDN.
Pages pulling from a CMS: export const revalidate = 3600 so they rebuild at most hourly.
Anything that must be fresh on every request: export const dynamic = 'force-dynamic'.

Don't try to be clever. Start fully static, and only opt into dynamic where you actually saw stale content.

The Good: what changed

Before (SPA): a blank page and a spinner until the JS bundle loaded, meta tags set by JavaScript, Lighthouse performance in the 50s–60s on mobile.

After: full HTML on first byte, every page with server-rendered meta and canonical tags, Lighthouse performance in the 90s, and the site indexed properly within a few weeks of launch.

The site looks exactly the same to a visitor. That was the requirement. But Google sees a completely different site.

What I'd tell someone about to do this

Map every old route to a folder first, before writing a single component. Routes are your SEO contract.
Default to Server Components. Add 'use client' only when the compiler complains, and add it as low in the tree as possible.
Hunt down every window, Date, Math.random, and localStorage in render paths before you deploy — those are your hydration errors.
Test the build with JS disabled. If the page is readable, you did it right.
For a small-to-mid site, seriously consider a clean rewrite over incremental migration. It's less scary than it sounds.

If you've done a similar migration and hit a hydration error I didn't list, drop it in the comments — I'm sure I haven't seen them all.

3 Things Vibe Coders Must Check Before Pushing to Production

mhk sameera — Wed, 09 Sep 2026 07:47:50 +0000

Vibe coding is amazing. You describe what you want, the AI writes it, it works on localhost, and you feel like a 10x developer.

Then you push to production with real users and real data, and things get ugly.

I've shipped a few projects this way, and I've learned — once at the cost of real money — that AI-generated code is great at making things work and terrible at making things safe. The AI optimizes for "it runs" — not for "it survives the internet."

Here are the three things I now check every single time before going live. None of them are complicated, and skipping them is how you end up leaking user data.

1. Exposed environment variables (this one cost me real money)

Let me tell you how I learned this.

I run AskLeya, a SaaS chat assistant for businesses. It uses an OpenRouter API key to call GPT-4o, and that model has exactly one job: read the customer's knowledge base and answer their customers' questions. That's it. One model, one purpose.

One day a customer flagged that their chat widget had stopped responding. I checked the code. No errors. I checked the server. Fine. Then I opened the OpenRouter dashboard.

My credit — which by my usage math should have lasted a long time — was gone. And the usage log showed calls to Claude Opus, Claude Sonnet, Kimi, GLM and a handful of other models I had never touched. Someone had my key and was using it as their personal free AI account.

I rotated the key immediately and the app came back. I didn't spend more time hunting for exactly how it leaked — at that point the fix was the same regardless. But here's the uncomfortable part: I wasn't even fully vibe coding that project. I used AI help in some areas, wrote the rest myself, and I still got caught.

The likely suspects were the usual ones: a key that ended up in a client-side bundle, a .env that briefly touched a git commit, or a key pasted into a chat/tool while debugging. Any of them is enough.

Two things I do differently now:

Set a spend limit and a model allowlist on every key. OpenRouter (and most providers) let you cap credits per key and restrict which models it can call. If my key had been limited to GPT-4o with a small ceiling, the damage would have been capped and the alerts would have fired early. Do this on day one, not after.
Treat every key as already leaked. Ask "what happens if this gets out?" and design so the answer is "not much."

Now, the general checks:

Your AI assistant needs an API key to make something work. So it puts it somewhere convenient. Sometimes that "somewhere" ends up in the browser.

Things to check:

Client-side prefixes. In Next.js, anything starting with NEXT_PUBLIC_ is shipped to the browser. In Vite it's VITE_. If your OpenAI key, Stripe secret key, or database URL has one of these prefixes, it's public. Anyone can open DevTools and copy it.
.env committed to git. Check that .env is in your .gitignore before your first commit, not after. If it's already been pushed, rotating the keys is the only fix — deleting the file doesn't remove it from history.
Keys hardcoded in the code. AI tools sometimes paste the actual key into a file "temporarily." Grep your codebase for sk-, pk_, AKIA, and anything that looks like a token.
Server vs client boundary. Any call that uses a secret should happen on the server (API route, server action, edge function). If your frontend is calling a third-party API directly with a secret, that's a leak.

Quick test: build your project, open the output folder, and search the bundled JS for your keys. If you find one, you have a problem.

2. No rate limiting

Your app works fine when you're the only user. Then someone writes a 10-line script that hits your signup endpoint 50,000 times, or your AI chat endpoint 5,000 times, and you wake up to either a crashed app or a $400 API bill.

AI-generated code almost never adds rate limiting unless you ask for it.

Where you need it most:

Auth endpoints — login, signup, password reset. Without limits, these are open to brute force and spam accounts.
Anything that costs you money per request — LLM calls, email sending, SMS, image generation. This is the one that hurts your wallet.
Public forms — contact forms, comments, anything unauthenticated.
Expensive database queries — search, exports, reports.

You don't need to build this yourself. Most platforms have a one-line solution:

Vercel / Next.js: @upstash/ratelimit
Express: express-rate-limit
Supabase: enable rate limits in Auth settings
Cloudflare: rate limiting rules in the dashboard, no code needed

Even a crude limit like "10 requests per minute per IP" is 100x better than nothing.

3. OWASP vulnerabilities

OWASP publishes a Top 10 list of the most common web security holes. It's been around for years, and AI models were trained on plenty of code that ignores it — so your generated code probably does too.

You don't need to memorize the whole list. These are the ones I see most often in vibe-coded projects:

Broken access control. The API checks if you're logged in, but not if you're allowed to see this specific record. Change the ID in the URL from /orders/123 to /orders/124 and you're reading someone else's data. This is the #1 issue on OWASP's list and the #1 thing I find in AI-generated apps.
Injection. If any user input goes into a SQL query, shell command, or HTML without being sanitised or parameterised, you're exposed. Using an ORM helps but doesn't make you immune — raw queries sneak in.
Missing input validation. The frontend validates the form, but the API accepts anything. Validate on the server with something like Zod or Joi. The frontend is not a security boundary.
Insecure defaults. Debug mode on in production. CORS set to *. Database with no row-level security. Admin routes with no auth check because "nobody knows the URL."

The fix is simple but boring: for every API endpoint, ask "who can call this, and what can they get?" Then actually test it — log in as user A and try to fetch user B's data.

Before you push

Here's the checklist I run through:

Searched the built bundle for secrets
.env in .gitignore, no keys in git history
All secrets used server-side only
Rate limits on auth, paid APIs, and public forms
Every endpoint checks ownership, not just login
Server-side validation on all inputs
Debug mode off, CORS locked down

Takes maybe an hour. Saves you from a very bad week.

One more tip: you can literally paste this list into your AI assistant and say "audit my codebase for these." It's surprisingly good at finding the problems — it just doesn't fix them unless you ask.

What other things have bitten you after shipping an AI-built project? I'd like to add to this list.

Building Ask Leya: Lessons Learned from Local ONNX Embeddings, Prisma Migrations, and Express Async Handlers

mhk sameera — Tue, 08 Sep 2026 09:14:30 +0000

Why build another chat widget? Because every widget I tried either followed a rigid script or confidently made things up. Ask Leya answers from a business's own content and hands off to a human when it can't.

Here are three core architectural hurdles I ran into and how I solved them:

Cross-language retrieval is local, not the LLM Retrieval uses paraphrase-multilingual-MiniLM-L12-v2 through ONNX, in-process — 384 dims, trained across 50+ languages. A business writes its knowledge base in English; an Arabic visitor asks in Arabic; the local model embeds that question into the same vector space as the English entries and finds the right one.

No translation step, no API call, no per-query embedding cost, and nothing leaves the server to be embedded. The chat model then only has to phrase the answer back in Arabic, which is the easy half.

The trade: A cold start while the model loads, and it pulls in sharp, which cost me a 90-second production hang when a macOS binary got rsynced onto a Linux box.

Managing a database shared with unreleased modules
The database is shared with the rest of my broader app under development — 67 tables total right now, many of which belong to unreleased modules. Since Prisma migrate tries to treat unreleased tables as drift, every migration currently requires hand-filtering additive statements via prisma migrate diff until the full suite ships.
Express 4 doesn't forward async rejections
An unguarded async handler that throws gives you no response at all — the caller just hangs until it times out. That took /chat down for 90 seconds a request before I tracked it down.

The Stack
Frontend: Next.js App Router, React (with a dependency-free vanilla JS iframe widget so it can't collide with customer CSS).

Backend: Node.js, Express.

Database: Postgres (Neon) + pgvector.

Real-time & AI: Socket.IO for live human handoff, gpt-4o-mini via OpenRouter for replies.

Free tier, no credit card required. Features like WhatsApp, Instagram, and Messenger integrations are built out but kept behind the scenes until fully polished for self-serve.