DEV Community: Ayush Srivastava

Building InternFlow (Part 4): The Roadmap Beyond an Internship Platform

Ayush Srivastava — Sun, 28 Jun 2026 09:31:54 +0000

InternFlow started as a tool to solve one problem. After talking to students, I realized it needs to solve a dozen.

The first version of InternFlow solved a problem I personally faced: finding internships, getting code reviewed, and turning GitHub projects into a resume — all in one place.

But as I used the product and talked to other students, something became clear: landing an internship isn't one problem. It's a series of smaller ones.

Finding opportunities is only one piece of the puzzle. Students also struggle with:

Optimizing their LinkedIn and GitHub profile for recruiter visibility
Preparing for technical interviews without knowing where to start
Understanding what their GitHub projects actually say about them
Making resumes that pass ATS filters before a human ever reads them

That's why the next phase of InternFlow is focused on becoming a developer career platform rather than just an internship portal.

1. LinkedIn Profile Optimizer 🟡 Building now

Instead of generic advice, the system will analyze a user's actual profile and provide specific suggestions:

Rewrite the headline for better recruiter search visibility
Identify missing skills and keywords for their target role
Improve the About section impact
Score current project descriptions and suggest stronger alternatives

The goal is actionable, specific feedback — not "make your headline more impactful."

2. AI Interview Preparation 🔵 Exploring

Preparing for technical interviews is overwhelming when you don't know where to start.

I'm building an interview prep system that adapts to a student's actual skill level and target role — not random LeetCode. It would:

Generate personalized interview sessions based on your GitHub stack
Explain mistakes in plain language, not just mark them wrong
Build a topic improvement plan based on your weak areas

3. Personalized Internship Recommendations ⚪ Planned

Right now, InternFlow shows the same listings to everyone. That's not useful.

The next version will match opportunities to individual students based on:

Technologies in their GitHub projects
Skills identified from code reviews
Roles they've shown interest in
Gaps between their current profile and job requirements

4. Advanced GitHub Insights ⚪ Planned

The current repository analysis gives summaries and code reviews. Future improvements:

Project quality score — how does this project compare to what recruiters expect?
Architecture analysis — is the codebase structured well?
Technology trend alignment — are you building with in-demand tools?
Portfolio impact suggestions — what would make this project stand out more?

5. ATS Resume Intelligence ⚪ Planned

Instead of generating a resume once and forgetting it, the platform will continuously improve it:

Compare your current resume against a specific job description
Identify missing keywords that ATS filters look for
Estimate ATS compatibility score before you apply
Suggest targeted bullet rewrites for each application

What hasn't changed

The scope is bigger. But the filter I apply to every feature is the same one I used when building version one:

Does this make a real difference for a student trying to land their first opportunity?

If the answer is no, it doesn't ship.

Series recap

This is Part 4 of a series documenting the technical decisions behind InternFlow:

[Part 1] — Why I chose microservices over a monolith
[Part 2] — Building a RAG pipeline without calling GPT APIs
[Part 3] — Deployment lessons from running 7 Docker services in production
Part 4 — This article: the roadmap

If you're a B.Tech or engineering student, InternFlow is free to use.

Connect your GitHub repo, push a commit, get an AI code review, and turn your real work into resume bullets that get you shortlisted.

→ Create your free account at intern-flow.in

What features would you want to see? Drop a comment — most of the roadmap above came from conversations with students.

Building InternFlow (Part 3): Lessons Learned Deploying a Multi-Service AI Application

Ayush Srivastava — Sun, 28 Jun 2026 09:30:08 +0000

Taking InternFlow from Docker Compose on a laptop to a production server exposed problems that no tutorial prepares you for.

Deploying a single web application is straightforward. You push code, a server runs it, done.

Deploying seven interconnected services — with AI models, background crawlers, databases, and a reverse proxy — is an entirely different challenge.

The production stack

[ Internet ]
     │
[ Nginx reverse proxy + SSL ]
     │
┌────┴────────────────────────┐
│  Next.js  │  FastAPI API    │
├───────────┴─────────────────┤
│  AI Service │ RAG Service   │
│  Job Crawler                │
├─────────────────────────────┤
│  PostgreSQL │ Redis         │
│  Docker volumes (persistent)│
└─────────────────────────────┘

Every layer had at least one thing that surprised me.

Lesson 1: Separate infrastructure from application logic

The biggest mistake I made early on was mixing infrastructure configuration with application code. Environment variables were hardcoded in places. Database connection strings were duplicated across services.

The fix was treating infrastructure as a completely separate concern:

# docker-compose.yml — environment from files, not hardcoded
services:
  api:
    env_file:
      - .env.production
    depends_on:
      postgres:
        condition: service_healthy

# .env.production — never committed to git
DATABASE_URL=postgresql://user:pass@postgres:5432/internflow
REDIS_URL=redis://redis:6379
SECRET_KEY=your-secret-here

Lesson 2: Logs are your only debugger in production

Before: Service fails silently. No error surfaces. User sees a blank response. I SSH into the server and run docker ps to find a container has been OOMkilled with no trace of why.

After: Structured logging with timestamps and service names. Every request logged with duration. Every error logged with full stack trace and context.

import logging
import time

logger = logging.getLogger(__name__)

async def generate_resume(repo_id: str):
    start = time.time()
    logger.info(f"[resume] starting generation for repo={repo_id}")

    try:
        result = await pipeline.run(repo_id)
        logger.info(f"[resume] completed repo={repo_id} duration={time.time()-start:.2f}s")
        return result
    except Exception as e:
        logger.error(f"[resume] failed repo={repo_id} error={str(e)}", exc_info=True)
        raise

Good logs are not a nice-to-have. In a multi-service architecture, they're the only way to know what your system is doing.

Lesson 3: Health checks are load-bearing

Docker's healthcheck directive sounds like a monitoring nicety. In practice it's critical for startup ordering.

Services come up in unpredictable order. A FastAPI service that starts before PostgreSQL is ready will crash on first database connection — silently, in a way that looks like the application is broken when it's actually just a race condition.

services:
  postgres:
    image: postgres:15
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  api:
    depends_on:
      postgres:
        condition: service_healthy  # waits for postgres to pass health check

This single change eliminated an entire class of random startup failures.

Lesson 4: Persistent storage requires deliberate planning

The FAISS vector indexes are large. Model weights are large. PostgreSQL data must survive container restarts.

Early on I had all of this in ephemeral container filesystems. One docker compose down wiped everything — including indexed repositories.

volumes:
  postgres_data:
  faiss_indexes:
  model_cache:

services:
  postgres:
    volumes:
      - postgres_data:/var/lib/postgresql/data

  rag_service:
    volumes:
      - faiss_indexes:/app/indexes
      - model_cache:/app/models

Named volumes persist across docker compose down and up. Pair this with a nightly backup script and you have a real persistence story.

Lesson 5: Nginx config is part of your application

I treated Nginx as an afterthought — something I'd configure "at the end." That was wrong.

server {
    listen 80;
    server_name intern-flow.in;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name intern-flow.in;

    ssl_certificate /etc/letsencrypt/live/intern-flow.in/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/intern-flow.in/privkey.pem;

    # Frontend
    location / {
        proxy_pass http://frontend:3000;
        proxy_set_header Host $host;
    }

    # API
    location /api/ {
        proxy_pass http://api:8000;
        proxy_read_timeout 120s;  # AI endpoints take longer
    }
}

Note the proxy_read_timeout 120s for AI endpoints. Default Nginx timeout is 60 seconds — AI generation regularly exceeded this and caused cryptic 504 errors that took me hours to trace.

The key lessons, distilled

Infrastructure is application code — treat Dockerfiles, Nginx configs, and Compose files with the same care as your Python or TypeScript
Observability before features — logging and health checks should be set up before any feature goes to production
Assume services will fail — design for restart, not for reliability
Persistence is separate from compute — containers are disposable, data is not
Read the timeout docs — every proxy, every client, every service has a default timeout that will surprise you in production

In Part 4, I'll cover where InternFlow is going next — beyond an internship tool into a full developer career platform.

InternFlow helps B.Tech and engineering students turn their GitHub projects into internship offers. AI code reviews on every commit, ATS resume generation, and daily internship listings.

→ Try it free at intern-flow.in

Building InternFlow (Part 2): Designing an AI Pipeline Without Calling GPT APIs

Ayush Srivastava — Sun, 28 Jun 2026 09:25:39 +0000

How I built a Retrieval-Augmented Generation system for code review and resume generation — and why avoiding hosted LLMs was the right call.

One of the first decisions I made when designing InternFlow's AI layer was this: I didn't want to depend on OpenAI or any hosted LLM API for the core functionality.

This wasn't about cost alone — though that matters for a student project. It was about understanding how AI products actually work underneath the marketing.

Why not just call GPT?

The core problem with sending code to a hosted LLM without context: it hallucinates. It'll write confident-sounding review comments about patterns it hasn't seen. For a resume generator, it'll invent metrics. None of that is useful for a student trying to land an internship.

Hosted LLM API ❌	Local RAG Pipeline ✅
Hallucinations on repo-specific code	Answers grounded in real repo data
API cost scales with every request	Fixed infrastructure cost
No control over context window	Full control over what the model sees
Third-party dependency	Runs entirely on our infrastructure

The RAG pipeline

RAG stands for Retrieval-Augmented Generation. Instead of asking a model to answer from memory, you first retrieve relevant context, then pass it to the model alongside the question.

Here's how the InternFlow pipeline works step by step:

Step 1: fetch_repository()
        ↓
        Pull metadata + source files from GitHub API
        Filter to relevant file types (.py, .ts, .md, etc.)

Step 2: chunk_content()
        ↓
        Split files into overlapping chunks
        Function-level splitting for code
        Paragraph-level for documentation

Step 3: generate_embeddings()
        ↓
        Run each chunk through sentence-transformers
        Local embedding model — no GPU required

Step 4: store_in_faiss()
        ↓
        Index all embeddings in FAISS vector database
        Persistent per-repository index

Step 5: retrieve_context(query)
        ↓
        Embed the query at generation time
        Retrieve top-k most similar chunks

Step 6: generate(context + prompt)
        ↓
        Pass retrieved context to local language model
        Output is grounded in actual repository content

RAG reduces hallucinations because the model is answering from retrieved evidence, not from memory. For code review, this matters enormously.

The tools I used

# Embedding model
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')

# Vector store
import faiss
index = faiss.IndexFlatL2(embedding_dim)

# Chunking
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64
)

The all-MiniLM-L6-v2 model is small enough to run on CPU without meaningful latency. FAISS handles similarity search efficiently even with thousands of chunks per repository.

What made this harder than expected

Inference speed — Local models are slow without a GPU. I had to experiment with quantization and pick model sizes carefully. The right model for this use case is the smallest one that produces acceptable output.

Docker image size — A single AI service image with model weights bloated to gigabytes. I ended up downloading weights at container startup rather than baking them into the image layer, which made deployments much faster.

Memory management — Loading multiple models simultaneously caused OOM errors. Each service needed explicit memory budgets and lazy loading — models loaded on first request, not at startup.

Prompt engineering — Getting consistent, structured output from local models required significantly more iteration than with hosted APIs. The model needs very explicit instructions about output format.

The result

When a student connects their GitHub repo and pushes a commit, InternFlow can now:

Review the diff against their existing codebase context
Generate resume bullets that reference actual functions, actual metrics, actual decisions — not generic boilerplate

The pipeline runs entirely on our infrastructure, with no per-request API cost.

The bigger lesson: most of the engineering in an AI product has nothing to do with AI. It's data pipelines, memory management, latency budgets, and output parsing. Calling a hosted API hides all of that from you.

In Part 3, I'll walk through the deployment challenges: getting all of this running reliably in production with Docker, Nginx, SSL, and persistent storage.

I'm building InternFlow — connect your GitHub, get AI code reviews on every commit, and generate ATS-ready resume bullets from your real work.

→ Try it free at intern-flow.in

Building InternFlow (Part 1): Why I Chose a Microservice Architecture for a Student Project

Ayush Srivastava — Sun, 28 Jun 2026 09:24:44 +0000

Most tutorials tell you to start with a monolith. Here's why InternFlow went the other way — and what I learned from it.

When I started building InternFlow, I knew it wouldn't be just another CRUD application. The platform needed to handle job crawling, AI-powered repository analysis, resume generation, authentication, and multiple background processes — all running concurrently.

The obvious first instinct was to put everything inside one FastAPI application. Easier to build, easier to run locally, easier to reason about.

But I kept running into the same problem: each feature had wildly different resource requirements.

The resource mismatch problem

Job Crawler — Network I/O bound, runs on a schedule
AI Service — CPU and memory heavy, unpredictable duration
Web API — Latency sensitive, users expect immediate responses
RAG Service — FAISS indexes + embedding models loaded in memory

If all of these lived in one process, a single heavy AI request could block user-facing API responses. The job crawler running on a schedule would compete for the same thread pool as the REST endpoints. Debugging which part of the monolith was causing the slowdown would become a nightmare.

Running different workloads inside one process means the worst-performing one defines your entire system's reliability.

The architecture I settled on

         ┌─────────────────────┐
         │   Next.js Frontend  │
         └──────────┬──────────┘
                    │ HTTP
         ┌──────────▼──────────┐
         │  FastAPI API Service │
         └──┬──────────────┬───┘
            │   Docker     │  internal network
   ┌────────▼───┐   ┌──────▼──────┐   ┌───────────┐
   │ AI Service │   │ RAG Service │   │  Crawler  │
   └────────────┘   └─────────────┘   └───────────┘
            │              │
   ┌────────▼──────────────▼──────────┐
   │     PostgreSQL  │  Redis          │
   └─────────────────────────────────┘

Docker Compose became the glue holding everything together. Each service has its own Dockerfile, its own environment variables, and its own health checks. They communicate over a shared internal network, but are completely isolated from each other's failures.

Monolith vs microservices for this project

Single FastAPI App	Microservices (chosen)
Heavy AI task slows all API responses	AI service is isolated — API stays fast
Crawler competes with user requests	Crawler runs on its own schedule
One crash takes everything down	Service restarts don't affect others
Hard to find the slow component	Per-service logs make debugging fast
✅ Simpler local dev setup	❌ Docker Compose adds initial overhead

The trade-off was real: the initial setup took longer. Writing Docker configs, managing inter-service communication, and dealing with network issues added friction in the first week. But every hour spent on that setup saved multiple hours later when debugging and scaling.

What I'd tell someone starting a similar project

If your project has genuinely different resource profiles across features — network-heavy, compute-heavy, latency-sensitive — separate them early. The cost of splitting a monolith later is much higher than the cost of Docker Compose configuration upfront.

If you're building a simple CRUD app with one background job, a monolith is probably the right call.

InternFlow wasn't that kind of project.

Docker Compose isn't just a deployment tool — it's an architectural decision that forces you to think about service boundaries before you have to.

In Part 2, I'll explain how I designed the AI pipeline that powers repository analysis and resume generation — including why I chose RAG over direct LLM API calls.

I'm building InternFlow — an AI code review and resume generation platform for B.Tech and engineering students. Connect your GitHub, get line-level code reviews on every commit, and turn your real work into ATS-ready resume bullets.

→ Try it free at intern-flow.in