Micro-Intern Project Engineer (IAP-Alumni Host)

Company Overview

GrowthFactor is the AI analyst for commercial real estate. We make expansion analysis as easy as asking a question, then ground every answer in a model tailored to each brand, so our customers open the right locations, faster. Ask where to grow in plain English and see the answer on a live map.

We're a team of 27, building for customers who make seven-figure decisions on what we ship. Our office is at 222 Third St in Cambridge, a 12-minute walk from Kendall Square.

Purpose of the Micro-Internship

Our usage is growing exponentially. That's the good problem, but it means queries / endpoints that were fine at last year's data volume are no longer fine, and a single slow query / endpoint can now consume a pod's workers and take down a pod for everyone. We know this risk is there, but we don’t have evidence-backed picture of where it is.

This micro-internship exists to produce that picture and to fix the worst of what it finds. This is a performance engineering internship. You will work profiling, query plans, load testing, and the operational guardrails that keep one bad request from becoming an outage.

Project Specifications and Desired Outcome

The project: Find the performance bottlenecks in GrowthFactor's backend.

Desired outcome by the end of the term:

• A ranked inventory of performance bottlenecks across our FastAPI backend, frontend, and PostgreSQL database
• A reproducible load-testing setup that can put realistic traffic against our staging environment, so any future change can be measured the same way
• Guardrails so a slow query degrades one request instead of a pod: statement timeouts, sensible pagination limits, and alerting on the slow-query threshold
• A short written handoff: what you measured, what you fixed, what you'd fix next, and the rough breaking point of the system as it stands

Major Duties and Responsibilities

Listed roughly in order of how much of the project each represents:

• Measure and profile (primary, ongoing). Use our existing observability tooling (Sentry + Logfire) plus PostgreSQL's own query statistics to find what's actually slow under real traffic.
• Build the load-testing harness (early, then reused throughout). Write a repeatable way to generate realistic load against staging, so findings are reproducible and fixes are provably fixes.
• Fix the top bottlenecks (second half). Write and ship the changes in Python, Next.js, and SQL, with before/after numbers attached to every pull request.
• Add operational guardrails (ongoing). Timeouts, query limits, and alerting.
• Participate in engineering rituals (weekly). Attend stand-up, team meetings, open pull requests, and get your code reviewed like anyone else on the team.
• Present your work (once, at the end). A short demo and writeup to the engineering team.

Additional projects may be developed based on your skill set and interests. Students who move quickly have room to extend into adjacent work, such as capacity planning for the infrastructure itself.

Relationship to Organizational Objectives

Reliability is the constraint on how fast we can grow. Our customers make seven-figure decisions on this product, and a timeout during that work costs us credibility we can't buy back. Right now our understanding of where the system strains is anecdotal, which means we're reacting to slowness rather than anticipating it.

This project turns that into something measured. It maps directly to a tracked engineering priority on our roadmap, and everything you build we will use and keep using.

Supervision, Mentorship, and Teamwork

• Reports to: Sameena Shaffeeullah (MIT 2019), Head of Engineering
• Mentorship: You'll be paired with an engineer on the backend team (Cole, MIT 2026) for a weekly 1:1, separate from your manager.
• Team interaction: You'll sit in the same stand-ups, code reviews, and architecture discussions as the rest of engineering. Because this work touches production, you'll also work closely with whoever is on call.
• Equipment and tooling: Laptop provided if you need one. Full access to our tools (like Claude Code / codex)

Required Skills and Characteristics

Technical

• Comfortable writing Python beyond coursework
• Comfortable with SQL and relational databases. You should be able to read a query and reason about what it costs; we'll teach you the rest of reading a query plan.
• Familiar with Git and a code review workflow

Working style

• You ask questions early. This matters more than anything on the technical list.
• You can take feedback on your code and use it.
• You're comfortable when the answer isn't documented anywhere and you have to go find it.
• You're rigorous about evidence. You'd rather measure something than argue about it, and you don't call something fixed until the numbers say so.

What You Will Learn

• How to profile and load-test a real production system, and how performance work differs from the version taught in a systems course
• PostgreSQL query planning and indexing against a database large enough that the choices matter
• How production incidents actually happen (resource exhaustion, cascading slowness) and the operational patterns that contain them
• How an early-stage engineering team makes technical decisions, by being in the room where they're made
• A concrete body of work with measured results you can point to in future interviews, plus a reference from the Head of Engineering

Location

• Format: Hybrid. We'd like you on-site in our Cambridge office one day per week, with the remaining hours remote and flexible. The office is a short walk from campus down Third Street.

Anticipated Pay Range

$20–$40 per hour, depending on experience.