You ask it about recursion, and it asks what you already think recursion means. You ask for the derivative of x², and it asks what the power rule does to exponents. You say your exam is in ten minutes and beg it to just tell you, and it still asks you a smaller question instead.

That constraint made the project interesting.

The goal was not to build another chatbot UI around an LLM API. The goal was to build a tutor with a specific behaviour: guide the learner without leaking the final answer too early.

Three things ended up mattering most:

1. The system prompt

2. Cost protection

3. Choosing the right backend pattern

These are also the things that separate an LLM demo from something closer to a real product.

The system prompt is the product

What makes a Socratic tutor different from a generic chatbot is not only the model. It is the instruction layer around the model.

In my project, the most important file is not the API route. It is consts/prompt.ts.

That file controls the tutor’s behaviour. It tells the model not to give direct answers, how to respond when the user pressures it, how to ask smaller guiding questions, and how to keep the learner inside the problem instead of escaping to the final solution.

The prompt had to defend against patterns like authority pressure, emotional pressure, hypothetical framing, decomposition, and roleplay laundering.

A weak prompt says:

Do not give the answer.

A stronger prompt explains what to do instead:

Ask a smaller question.
Check the learner’s current understanding.
Give a hint only when needed.
Move one step at a time.
Refuse answer-seeking attempts without sounding robotic.

That was the first big lesson: prompt writing is not just wording. It is behaviour design.

The model is still the same model. But the product feels different because the prompt creates a decision path for each user message.

Three pages of prompt. A small API call. But the prompt is what turns the API call into a tutor.

Cost protection is real engineering

A naive LLM route is easy to write:

1. Receive the message

2. Call the model

3. Return the answer

That is fine for a local experiment. It is not enough for a public AI app.

The moment the app is live, every request has a real cost attached to it. If someone abuses the route, it is not just a bug. It can become a bill.

So the API route became more than a wrapper around Anthropic. It became a control layer.

Before the model is called, the request goes through Zod validation, so malformed message history never reaches the API.

Then I identify the request source using the forwarded IP header:

const userIp = req.headers.get("x-forwarded-for")?.split(",")[0].trim();

That lets me create a daily Redis key per IP:

const ipUsageKey = `ipUsage:\({userIp}:\){today}`;

I used Redis because this state is temporary, fast-changing, and does not need to live in a permanent database.

The IP limiter uses INCR first:

const newIpCount = await redis.incr(ipUsageKey);

That matters because Redis increments are atomic.

A naive read-then-write limiter can break under concurrency. Two requests can read the same old value, both pass the check, and both move forward.

With INCR, Redis handles the count safely.

If the user goes over the daily limit, I refund the count:

if (newIpCount > DAILY_IP_REQUEST_LIMIT) {
  await redis.decr(ipUsageKey);
}

That DECR looks small, but it matters. Without it, even rejected requests would keep increasing the count and could lock the user out unfairly.

I also added global daily token caps. Instead of only limiting requests, I track input and output tokens separately:

const InputTokenKey = `DailyInputToken:Global:${today}`;
const OutputTokenKey = `DailyOutputToken:Global:${today}`;

This gives the app a hard daily ceiling.

After the model responds, I update the counters using the actual token usage returned by Anthropic:

await Promise.all([
  incrementDailyTokenUsage(InputTokenKey, inputToken),
  incrementDailyTokenUsage(OutputTokenKey, outputToken)
]);

I used Promise.all because these two Redis writes do not depend on each other.

None of this makes the UI look more impressive. The user still sees a simple chat box. But this is the backend work that decides whether the project can safely stay online.

API routes vs Server Actions, and why I did not stream

I also had to decide how the frontend should talk to the backend.

Server Actions are great for many things in Next.js: forms, mutations, CRUD operations, and reducing client-side fetch boilerplate.

But for this project, I used a plain API route because I wanted clear control over request validation, response status codes, rate limiting, token accounting, and error handling.

I also deliberately chose not to stream the response.

That might sound strange because streaming is common in AI apps. But engineering is not about adding a feature because everyone else is doing it. It is about asking whether the user can actually feel the difference.

In this project, responses usually come back quickly enough that a loading bubble communicates the state clearly.

So instead of adding streaming complexity early, I kept the flow simple:

1. User sends a message

2. UI shows a thinking indicator

3. API route validates and checks limits

4. Model responds

5. UI appends the tutor message

The code stays easier to reason about, and token accounting stays cleaner because the full response is handled in one place.

If response time becomes a real UX issue later, streaming can be added. But it did not need to be the first version.

That was the lesson:

Do not cargo-cult complexity. Add it when the user can feel its absence.

The frontend still matters

The backend makes the app safe. The frontend makes it feel usable.

I added small UX decisions that are easy to ignore but matter in practice.

The chat automatically scrolls to the newest message. The input clears immediately after sending. The app disables sending while the tutor is thinking. Errors show as toast messages instead of silently failing.

On desktop, the input refocuses after sending so the user can keep typing naturally. On mobile, I avoid forcing focus back into the input because that can reopen the keyboard and make the experience annoying.

That detail is small, but it is product thinking.

A polished AI app is not only about the model response. It is also about everything around the response.

What's in the box

So this was not just:

I built a chatbot.

It was closer to:

I built a constrained LLM product with a researched system prompt, validated request handling, Redis-backed usage limits, global token caps, real token accounting, graceful error handling, and a mobile-aware chat UI.

The final product is simple on purpose.

One chat interface. One API route. One model.

But behind that simplicity are the decisions that make the app safer, cheaper, and more reliable.

If you are a junior developer building an AI portfolio project, my advice is this:

Do not just build a chatbot.

Build a product with constraints. Pick a behaviour. Make the prompt enforce that behaviour. Protect the route. Track cost. Validate input. Handle failure. Then explain those decisions clearly.

That is where the real engineering shows up.

Demo: https://socratic-tutor-eight.vercel.app/

Code: https://github.com/itstalhasattar/socratic-tutor

The system prompt is in consts/prompt.ts.

It is worth reading because that is where most of the product behaviour lives.

The Problem

We integrate with SuperControl, a property management API. Their security model is the old-school kind: they don't issue API keys you carry in a header. Instead, you give them a list of IP addresses, and they only accept requests coming from those IPs. Anything else gets dropped at the edge.

That works perfectly if your backend is one server with one IP. It falls apart the moment you deploy on Vercel.

Vercel runs your code on serverless functions. Every invocation can come from a different machine in a different data center, with a different outbound IP. The whole pool changes over time — they add new edges, retire old ones, scale up during traffic spikes. There's no published list of stable IPs to whitelist, and even if there were, it would be huge and changing.

So I had two options. Either ask SuperControl to whitelist "the internet" (not going to happen), or put something in the middle that has one IP that never changes.

The Managed Alternatives (and Why I Didn't Use Them)

This problem is common enough that every major platform has a paid product for it. The question is whether the price tag matches the integration.

• Vercel Static IPs — $100/month per project on the Pro plan, plus regional Private Data Transfer fees on top. Available on Pro and Enterprise; not on Hobby.

• AWS NAT Gateway — \(0.045/hour (~\)32.85/month) per gateway, plus \(0.045/GB processed, plus standard data transfer out. A single-AZ setup at low traffic lands around \)35–40/month; multi-AZ production setups easily run $100+ before data charges.

• Third-party proxies like QuotaGuard — around $19/month for entry tiers. Cheaper than the cloud-native options, but it's still a subscription to a black box.

All of them solve the problem. Justifiable at scale, when the cost is a rounding error against engineering hours saved. Overkill for a single integration where the upstream API itself doesn't justify enterprise spend.

The DIY answer: a $5/month VPS from any provider (Hetzner, DigitalOcean, Vultr) with a permanent IP and Nginx installed. Same outcome, a fraction of the cost. The trade-off is that you're now responsible for keeping the box patched and the cert renewed — Certbot's auto-renewal handles the second part; weekly apt update && apt upgrade handles the first.

For a single low-volume integration with one upstream, the trade is worth it. The moment I'm running ten of these or doing high-volume traffic, I'd reconsider.

Quick Detour: What's a Reverse Proxy? What's Nginx?

Skip this section if you already know.

A reverse proxy is a server that sits in front of another server and forwards traffic to it. The client thinks it's talking to the proxy; the proxy actually talks to the real backend on the client's behalf. "Reverse" because a normal proxy hides the client from the server (think VPN), while a reverse proxy hides the server from the client. Reverse proxies are how big sites do load balancing, caching, SSL termination, rate limiting, and — in our case — IP consolidation.

Nginx (pronounced "engine-x") is the software you run on a server to make it a reverse proxy. It's one of the most-used web servers on the internet, free, fast, and configured through plain text files. You describe what should happen to incoming requests, reload it, and it does that. No code, just rules.

Put together: I'm running Nginx on a VPS, configured so that requests hitting my proxy domain get forwarded to SuperControl's API.

The Solution

App on Vercel (dynamic IPs)
            ↓
Nginx on VPS (one static IP — whitelisted with SuperControl)
            ↓
SuperControl API

The VPS costs a few dollars a month and has a fixed IP. I gave that one IP to SuperControl. Every API call from the app now hits the VPS first, the VPS forwards it upstream, and SuperControl sees the same trusted address every time.

The catch: that subdomain is now publicly reachable. If I left it open, anyone who guessed the URL could use my VPS as a free, pre-authorized gateway into SuperControl's API. So the proxy needs its own auth layer — a shared secret in a custom header that the app sends and the VPS verifies before forwarding anything.

The Config

server {
    listen 443 ssl;
    server_name proxy.example.com;

    # Certbot-managed SSL certs here

    location = /health {
        return 200 "ok\n";
    }

    location / {
        if ($http_x_proxy_auth_key != "REPLACE_WITH_SECRET") {
            return 401;
        }

        proxy_pass https://api.upstream.example.com;
        proxy_ssl_server_name on;

        proxy_set_header Host api.upstream.example.com;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header x-proxy-auth-key "";
    }
}

server {
    listen 80;
    server_name proxy.example.com;
    return 301 https://\(host\)request_uri;
}

Forty lines doing six things:

1. HTTPS termination with a Certbot/Let's Encrypt cert, and HTTP→HTTPS redirect for anything that knocks on port 80.

2. /health as an exact-match endpoint for uptime monitors — no auth, no logging noise, just 200 ok.

3. Auth check on every other path: if the x-proxy-auth-key header doesn't match the shared secret, return 401 and forward nothing.

4. proxy_pass forwards the request to SuperControl, preserving the path, query string, method, and body.

5. Host header rewrite so the upstream sees its own domain instead of our proxy subdomain — most APIs reject requests with the wrong Host.

6. Strip the secret before forwarding. The auth key was for us; SuperControl has no business seeing it.

Three Things Worth Knowing

The header-to-variable rule. Nginx exposes every incoming header as a variable. The conversion: lowercase, replace hyphens with underscores, prefix with \(http_. So x-proxy-auth-key becomes \)http_x_proxy_auth_key, Authorization becomes \(http_authorization, Content-Type becomes \)http_content_type. Once you know the rule, every header is readable inside the config.

location = /path vs location /path. The = makes it an exact match — /health and nothing else. Without =, it's a prefix match, so / catches everything underneath it. This isn't just style: exact matches are checked first and short-circuit the rest of the routing, which is why they're the right choice for things like health checks.

proxy_ssl_server_name on is the gotcha that ate an hour of my time. SuperControl, like most modern APIs, uses SNI to pick which certificate to present during the TLS handshake. Without this directive, Nginx opens the connection without telling the upstream which hostname it's asking for, and the handshake fails with errors that look like generic 502s. The fix is one line; finding it isn't.

The Test Loop

sudo nginx -t                          # validate config syntax
sudo systemctl reload nginx            # apply if valid

# Health check — should always return 200
curl -i https://proxy.example.com/health

# Authed call — should return whatever the upstream returns
curl -i https://proxy.example.com/endpoint \
  -H "x-proxy-auth-key: REPLACE_WITH_SECRET"

# No header — should return 401, never touch the upstream
curl -i https://proxy.example.com/endpoint

nginx -t is the most important habit. It validates the whole file before you reload — catches misplaced braces, missing semicolons, and unreachable blocks before they take down a live config. Never reload without it.

Takeaway

Vercel and friends abstract away IPs, DNS, SSL, and routing so well that you can forget the network layer exists — until a third-party constraint forces you back into it. Forty lines of Nginx and a $5 VPS turned an unsolvable problem into a solved one. The skill isn't memorizing the syntax; it's recognizing when the abstraction has run out and being willing to drop a layer down to fix it.

Next.js alone gives you SSR, CSR, SSG and ISR. Four different rendering strategies. Each one sounds great until you try to figure out which one your project actually needs.

I'm going to break all of them down. Not just what they are but when to use each one and how they affect your SEO because sometimes what looks like the obvious choice is actually the wrong one for your situation.

Let's get into it.

SSR: Server-Side Rendering

When a user visits a page that uses SSR the server runs your React code right at that moment. It generates the full HTML and sends it to the browser. The user sees a complete page almost instantly.

But here's the thing. That page isn't interactive yet. It looks ready but buttons don't work and forms don't respond. In the background React is "hydrating" the page which means it's attaching all the event listeners and state management to the HTML that's already on screen. Once hydration finishes everything becomes interactive.

The psychology behind this matters. Users perceive your site as fast because they see content immediately. The brief moment before hydration completes is almost never noticed.

The two metrics that matter for SSR are First Contentful Paint (how quickly the user sees something) and Time to Interactive (how quickly they can actually use it). SSR optimizes heavily for the first one.

SEO impact: SSR is great for SEO. When Google's crawler hits your page it gets fully rendered HTML with all the content right there. No waiting for JavaScript to execute. Your meta tags, headings, text content and structured data are all present in the initial response. This is why most content heavy sites that care about search rankings go with SSR.

One tradeoff to know: you don't have access to browser APIs like window or localStorage during SSR because the code runs on the server. If your component needs those you'll need to handle that with client-side checks or move that logic to a client component.

CSR: Client-Side Rendering

CSR is the traditional React approach. The browser downloads your JavaScript bundle then the V8 engine executes it and React builds the entire page on the client side.

This means two things matter more than anything: the user's device performance and their network speed.

Here's where it gets interesting. Think about who your users actually are.

If you're building a luxury helicopter rental platform for clients in New York those users almost certainly have the latest iPhones fast home internet and 5G connections. For them CSR and SSR will feel almost identical in speed. The JavaScript bundle downloads in milliseconds on their connection and their device processes it instantly.

Now imagine you're building a government services portal used by people across rural areas with older phones and slower networks. That same JavaScript bundle that loaded instantly in New York might take 5 to 8 seconds to download and another few seconds to execute on a budget Android device. Suddenly SSR isn't just a nice optimization. It's the difference between a usable site and one that people abandon.

The rendering strategy you choose should be based on who is using your product not just what the technology can do.

SEO impact: CSR is the worst option for SEO. When Google's crawler visits a CSR page it initially sees an empty div or a loading spinner. Google can execute JavaScript and eventually see your content but it's a second pass and not guaranteed. Your pages may get indexed slower or with missing content. If you don't care about SEO like an admin dashboard or internal tool then CSR is totally fine. But if you need organic traffic from search don't use CSR for those pages.

SSG: Static Site Generation

SSG generates your pages at build time. When you run next build it pre-renders every page into static HTML files. These files sit on a CDN and when someone visits they just get served instantly. No server processing. No waiting.

This is the fastest option because there's literally nothing to compute at request time. The HTML already exists.

Use SSG when the content doesn't change frequently and isn't different per user. Think marketing pages, blog posts, documentation, landing pages and about pages. Your content is the same for everyone and it only changes when you deploy.

The downside is obvious. If your data changes you need to rebuild and redeploy. For a blog with 50 posts that's fine. For an e-commerce site with 100,000 products that update prices every hour that's not practical.

SEO impact: SSG is the best option for SEO. The HTML is pre-built and sitting on a CDN so Google gets it instantly. Page speed is as fast as it gets which Google directly uses as a ranking factor. Your content is fully rendered with all meta tags and structured data baked in. If your pages don't need to change per user and you want the best possible search rankings SSG is the answer.

ISR: Incremental Static Regeneration

ISR is the hybrid approach that tries to give you the speed of SSG with the freshness of SSR.

It works like this. You statically generate the page at build time just like SSG. But you set a revalidation time. After that time passes the next visitor triggers a background regeneration of the page. They still get the cached version instantly but the next visitor after them gets the freshly regenerated page.

Think of it as SSG with an expiration date.

This is perfect for content that changes but not in real time. Product pages where prices update daily. A news site where articles are published every few hours. A dashboard that shows data that refreshes every 30 minutes. The content needs to be relatively fresh but it doesn't need to be live to the second.

SEO impact: ISR gives you almost the same SEO benefits as SSG. The page is pre-rendered so Google sees full HTML on the first crawl. And because the page regenerates in the background your content stays fresh for subsequent crawls without sacrificing speed. This is the sweet spot for sites that need both good SEO and regularly updated content. E-commerce product pages and news sites use this a lot.

So Which One Do You Actually Use?

Here's the decision framework:

Use SSG when your content rarely changes and is the same for all users. Blogs. Docs. Marketing sites. Best SEO. Fastest performance. This should be your default starting point.

Use ISR when your content changes periodically but doesn't need to be real-time. Product catalogs. News articles. Nearly as good for SEO as SSG but your data stays fresh.

Use SSR when the content is different for every user or every request. Personalized dashboards. Search results. Pages that depend on cookies or authentication. Great for SEO when you need dynamic content that search engines should still index.

Use CSR when the page is behind authentication anyway and SEO doesn't matter. Admin panels. Internal tools. Complex interactive apps where the initial load time is less important than the runtime experience.

Quick Reference

The Real Lesson

The framework gives you these options. It doesn't tell you which one to pick. That's your job as an engineer. Understanding your users their devices their networks your SEO requirements and your content update frequency is what makes the difference.

A rendering strategy isn't a technical decision. It's a product decision.

And that's the kind of thinking that no tutorial and no AI tool is going to do for you.