DEV Community: Rekha Suthar

Building AI Resume Tailor — v0 build notes

Rekha Suthar — Sun, 10 May 2026 09:58:15 +0000

A short build log on shipping the first AI feature for my portfolio: paste a resume + a job description, get back tailored bullet rewrites, ATS keyword gaps, and likely interview questions. End-to-end on free tools.

What it is

AI Resume Tailor(Live Link).

Two textareas. One button. Behind the button: a Vercel serverless function that calls Groq's Llama 3.3 70B in JSON mode and returns three things — a list of tailored bullet rewrites, a missing-keyword gap analysis, and 5 predicted interview questions with prep tips. Plus a 0–100 match score.

It's the same prompt-engineering, structured-output, "talk to an LLM and render the response cleanly" pattern that AI app companies are hiring for every day. So I built one.

Stack — and why each piece

I picked everything by one rule: it must be free, no credit card, with enough quota to actually use the app.

Vite + React 18 + Tailwind CSS for the frontend. Vite over CRA because it's faster, and CRA is unmaintained. Tailwind because shipping a tiny single-page app shouldn't need 600 lines of CSS.
Vercel Hobby tier for hosting. The killer feature for this project: serverless functions live in the same repo as the frontend. Drop a file in /api/tailor.js and it becomes a routable endpoint. No second hosting account, no CORS dance.
Groq Cloud for inference. Free API key, no credit card, very fast inference (Llama 3.3 70B at ~300 tokens/sec). Their JSON mode forces the model to return parseable JSON, which removes a whole category of "the model added markdown around its answer" bugs.

The single most important architecture decision: the API key never leaves the server. Browsers can read every script you ship, so an API call that includes the Groq key client-side is a key any visitor can extract. The serverless function is the firewall — the browser POSTs /api/tailor, the function reads the key from process.env.GROQ_API_KEY, talks to Groq, and pipes back only the result.

The prompt that does the work

Most of the value is in the system prompt. Three rules I leaned on:

1. Force structured output. The system prompt declares the exact JSON shape and Groq's response_format: { type: 'json_object' } is the enforcer. Without that, Llama would occasionally wrap the answer in markdown — "Here's your tailored resume: { … }" — and JSON.parse would explode.

2. Be honest, don't invent. A career coach who fabricates skills is worse than no coach. The system prompt explicitly says: "Be honest. If the resume is weak for the role, say so via the score and the missing-keywords section — do NOT invent skills the candidate doesn't have." Without that line, the model is too eager to please and quietly upgrades "I built a CRUD app" to "Led architecture for distributed systems."

3. Ground every output in something concrete. Each tailored bullet ships with both the original line and the rewrite, so the user can see the diff. Each missing keyword ships with an actionable suggestion ("Add a 1-line bullet about your school project on X" instead of "Learn TypeScript"). Each interview question ships with what-they-want and a prep-tip. Specificity beats vagueness, every time.

Cost at this scale

Free, currently. Groq's Llama 3.3 70B free tier gives you ~14,400 requests/day with a per-minute rate limit. Each tailor request uses ~5,000 tokens in + ~1,500 out, well under any single limit. Vercel Hobby gives 100k function invocations and 100 GB-hours of compute per month. For a portfolio piece that maybe handles 50 requests/day from recruiters poking at it, both tiers are wildly oversized.

What's still v0

No streaming yet. The user clicks Tailor, sees a spinner for ~5 seconds, then the full result lands. v1 should stream — partial output as it generates, even if just the bullets section first. SSE on the function side, ReadableStream reader on the client. That's the next iteration.
No PDF upload. Right now it's paste-only. Most people have their resume as a PDF, not as plain text. Adding pdfjs-dist to extract text client-side is maybe an hour's work.
No history. Run it twice on different JDs and the previous result is gone. localStorage is enough for a v1 — no backend needed. Shareable result links would require an actual database; not worth it yet.
No streaming of the thinking. Llama doesn't expose chain-of-thought, so we don't get to show "thinking..." with intermediate steps. A streaming UI does the same job perceptually, which is why v1 is streaming-first.

The trickiest bug so far

Llama 3.3, even in JSON mode, occasionally returns valid JSON with the wrong shape — say, tailored_bullets as a string of bullets joined with newlines instead of an array of objects. JSON mode protects you from "is this parseable JSON" but not "is this the JSON I asked for."

Two defenses, in order of cost:

Be explicit in the system prompt. I literally pasted the JSON skeleton with empty strings inside ({ "tailored_bullets": [{"original": "", "rewrite": "", "why": ""}], … }) and told the model "return ONLY valid JSON matching this exact shape." That alone fixed ~95% of drift.
Validate on the client. The React app accesses result?.tailored_bullets with optional chaining and [] fallback for every list. If the model returns junk, the UI just shows fewer panels — no white-screen crash. Cheap, correct, ships.

A future v2 would replace the prompt-engineering defence with a Zod schema or a JSON Schema constrained-decoding layer. For v0, prompt + optional chaining is enough.

Repo

github.com/rekha0suthar/ai-resume-tailor · MIT licensed. Fork it, deploy your own. The whole thing is ~600 lines including the README.

Next up: streaming the response (v1) and PDF upload (v2). I'll post the streaming UX write-up after v1 ships — designing "AI is thinking" loading states is its own discipline.

Role-based access in a MERN e-commerce app

Rekha Suthar — Sun, 10 May 2026 04:08:27 +0000

A short walkthrough of how I structured permissions for customers, admins, and store managers in Grocery Store — what worked, what I'd change, and the one bug that taught me to never trust the client.

When I started building Grocery Store, I had three user types in mind:

Customers — browse the catalog, add to cart, check out.
Store managers — add or edit products, manage inventory.
Admins — everything a store manager can do, plus user management.

That sounds like a clean three-role hierarchy on paper. In practice, getting it right takes more than dropping a role field on the user model. Here's how I structured it, and the rough edges I ran into along the way.

The user shape

The User model carries a single role field with one of three values:

// models/User.js
const userSchema = new mongoose.Schema({
  name:     { type: String, required: true },
  email:    { type: String, required: true, unique: true },
  password: { type: String, required: true },
  role: {
    type: String,
    enum: ['customer', 'manager', 'admin'],
    default: 'customer',
  },
});

Single source of truth. Customers self-sign up; managers and admins are seeded or promoted by an existing admin.

Three places permissions are enforced

1. JWT payload. When a user logs in, the role goes into the signed JWT, so every authenticated request carries it without an extra DB lookup:

const token = jwt.sign(
  { id: user._id, role: user.role },
  process.env.JWT_SECRET,
  { expiresIn: '7d' }
);

2. Express middleware. Two layers — requireAuth checks the token is valid, then requireRole checks it carries the right role:

// middleware/auth.js
export const requireAuth = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch {
    res.status(401).json({ error: 'Not authorized' });
  }
};

export const requireRole = (...allowed) => (req, res, next) => {
  if (!allowed.includes(req.user.role)) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  next();
};

Routes then read like a permission spec:

router.post('/products',  requireAuth, requireRole('manager', 'admin'), createProduct);
router.delete('/users/:id', requireAuth, requireRole('admin'),         deleteUser);

3. React UI. A small <RequireRole roles={['admin']}> wrapper hides admin-only links from the navbar and gates whole admin pages:

const RequireRole = ({ roles, children }) => {
  const { user } = useAuth();
  if (!user || !roles.includes(user.role)) return null;
  return children;
};

The key insight: the UI guard is for UX, not security. If a customer crafts a request to DELETE /users/123, the React wrapper isn't between them and the database. The middleware is. Always assume the client is hostile.

The bug that taught me that

Early on I had role-based UI but not role-based middleware on a couple of admin endpoints. I assumed: "if the button isn't rendered, the customer can't reach the endpoint." True for honest customers. Anyone with browser dev tools and 30 seconds of curiosity can copy the request from the admin's network tab and replay it themselves.

Caught it in code review with a friend. The fix was a one-line requireRole('admin') add. The lesson — every mutation route needs explicit role enforcement, full stop — was worth more than the bug took to fix.

What I'd change next time

Use a permission flag, not a role string. role: 'admin' works for three roles. The moment the product needs "managers who can read user emails but not delete them," the role field collapses. A permissions: ['products.write', 'users.read'] array — or a small ACL table — scales better. I'd start there if I rebuilt today.

Centralize the policy. My current code spreads requireRole('admin') calls across routes. Better: one policy.js file mapping every route to required permissions, applied via a single middleware. One place to audit, one place to change.

Audit log. Every action a manager or admin takes should land in an audit collection. I didn't add this and I'd regret it the moment a real product manager said "wait, who deleted that?".

Takeaway

Role-based access is one of those things that looks trivial — add a field, check it, done — and stays trivial as long as you remember the cardinal rule: the server enforces, the client suggests. Build both layers, but never let the UI carry the security weight.

Repo: github.com/rekha0suthar/grocery-store · Live: grocery-store-ruddy-eight.vercel.app

Next up: build notes from the AI Resume Tailor — prompt design for structured output and streaming UX in React.