ApplyOS
Applying to internships is a tracking problem before it is a writing problem.
- Category
- Product
- Status
- Shipped, actively evolving
- Role
- Solo builder
- Tech stack
- Next.js, Groq API, pdf-lib, Supabase, Vercel
- Timeline
- ~2 months from first commit to now
- Beta cohort
- 20+ users, 38% retention
- Read time
- 10 min
Context
Internship applications were fragmented across LinkedIn, Wellfound, company career pages, and spreadsheets. Every application meant editing a resume by hand, saving another PDF with a slightly different filename, applying, then losing track of whether it had actually been sent or followed up on.
There was no single place to see the whole process. Resume tailoring was repetitive. Tracking lived in notes or spreadsheets, if it existed at all.
The first version of the idea was an AI resume builder. That was the wrong frame. The real problem was that the process itself had no home.
Decisions
- We assumed
An AI resume builder was the product. Faster tailoring would solve the core problem.
- We found
20+ user conversations surfaced that AI-generated resumes were only one step in a longer workflow. The bigger pain was not having anywhere to track what had been sent, to whom, and what needed follow-up.
- Therefore, we changed
Repositioned ApplyOS as a 4-module operating system for the internship process: Resume Studio, Application Tracker, Dashboard, and Internship Collective. AI became one accelerating capability inside a larger workflow, not the product itself.
- We assumed
React state was enough for an early version. Persistence could wait until the workflow was proven.
- We found
Beta feedback confirmed this directly, users lost tailored resumes, tracker state, or full portfolio setups to a refresh or cache clear. That was not an edge case, it was a trust problem, users stopped relying on the tool for anything they could not afford to lose.
- Therefore, we changed
Adopted Supabase for persistent storage and planned authentication as the next release, treating reliability as a prerequisite for the product to mean anything, not a later polish step.
- We assumed
The product was a resume and tracking tool. Anything else was scope creep.
- We found
No single beta user asked for a Collective by name. But across the beta conversations, the same missing category kept surfacing from different angles, interview experiences, recruiter contacts, company-specific tips, resume benchmarks, a general sense of everything scattered. Several different complaint labels, one real gap.
- Therefore, we changed
Built the Internship Collective as a dedicated section rather than folding requested content into the dashboard, treating the pooled signal as one roadmap item instead of several small feature requests. It has since grown to 120+ resources across 10+ categories, driving network-effect growth as more students contribute.
- We assumed
Every shared resource could live as a card on the homepage, the same way the first few did.
- We found
That pattern does not scale. A homepage cannot hold a growing, searchable knowledge base without becoming unusable, and dashboard clutter was already one of the most cited complaints in the same beta round.
- Therefore, we changed
Split the Internship Collective into a homepage preview, featured content and search, and a dedicated page with full filtering, sorting, and a table view for the complete database.
The product
ApplyOS has four connected modules. A resume studio that scores a resume against a real job description and returns an ATS score with a section-level breakdown. An application tracker that replaces the spreadsheet the whole project started from. A dashboard that summarizes the pipeline, applications, interviews, offers, response rate, at a glance. And the Internship Collective, a searchable, filterable base of resources contributed by students, not owned by one person.
The resume tailoring workflow
The Internship Collective grew out of a pattern in the beta data, not a single request. Students keep finding useful resources, resume templates, recruiter contacts, interview notes, that disappear into private notes, WhatsApp groups, or a single LinkedIn post nobody can find again later. ApplyOS turned that into a shared, searchable base instead of private knowledge.
Hypotheses
Students don't need another resume builder, they need a better application workflow. Most already have Google Docs, Overleaf, Canva, and existing templates, so the real friction isn't creating resumes, it's managing everything around applying. 20+ conversations consistently pointed toward tracking applications, remembering deadlines, and repeated tailoring as bigger pain points than resume design. Validated: ApplyOS became a workflow platform rather than a document editor.
AI should reduce repetitive work, not replace decisions. Instead of generating a resume from scratch, AI identifies missing keywords, tailors existing experience, and speeds up editing, while the user still owns the final resume. Validated: AI became one feature inside the workflow rather than the product itself.
Community knowledge is more valuable than static guides. Students rarely trust generic blog posts, they ask seniors, friends, Discord, Reddit, WhatsApp groups. The best information already exists, it's just fragmented. This directly led to the Internship Collective, now at 120+ resources across 10+ categories.
Students prefer one workspace. Instead of moving between Docs, LinkedIn, a spreadsheet, ChatGPT, Reddit, GitHub, a resume PDF, and email, they should stay inside one application. That became the long-term vision.
Tradeoffs
- We assumed
Authentication (Google login) should ship early to make the product feel complete.
- We found
Before validating the core workflow, authentication only adds friction. A single-user, local-first workflow was enough for early versions.
- Therefore, we changed
Postponed authentication until the Internship Collective required persistent, per-user contributions, at which point it became necessary rather than optional polish.
- We assumed
A Chrome extension to save internships directly from LinkedIn would be a strong differentiator.
- We found
It would dramatically increase engineering complexity before the core workflow itself was validated.
- Therefore, we changed
Deferred to a later automation phase of the roadmap.
- We assumed
Automatic internship aggregation via job scraping would make the product more valuable on day one.
- We found
Scraping requires ongoing API maintenance and carries legal considerations disproportionate to early validation needs.
- Therefore, we changed
Focused instead on organizing opportunities users already found, rather than sourcing new ones automatically.
- We assumed
One-click apply would be a flashy, demo-friendly feature.
- We found
Every company runs a different hiring system, making this heavily dependent on third-party ATS behavior for comparatively little validated demand.
- Therefore, we changed
Rejected for now. Kept engineering effort on the core tracked-and-tailored workflow instead.
Other ideas intentionally postponed for the same reason, keeping the core workflow focused before adding surface area: browser autofill (different ATS systems behave differently, high maintenance burden), collaboration and shared trackers (most users work independently, doesn't solve the primary pain point), notifications for deadlines and interviews (core workflow needed validation first), and a native mobile app (research showed students primarily apply from laptops, so desktop-first made more sense).
Principles
A few rules held across every stage of building this. AI accelerates, it does not replace judgment, the tailored resume and the ATS score are a starting point a person still reviews. The surrounding workflow usually creates more value than the AI feature itself. Start simple and postpone what is not load bearing yet, authentication waited until persistence was proven necessary, not the other way around. Every feature traces back to an actual pain point, ideally one confirmed across more than one user conversation and in more than one way.
Results
Validation
Across 20+ user conversations, the same bottleneck kept surfacing independent of who was asked, students weren't struggling to write resumes, they were struggling to manage the process around applying. That signal is what drove the pivot from a single-purpose resume tool to a 4-module operating system, and it's reflected in the product's 38% retention among beta users.
The strongest signal wasn't any single request. It was that unrelated user segments, IIT SWE aspirants, Tier-3 college designers, PM aspirants, kept independently describing the same structural gaps, fragmented resources and no persistence, in completely different language. That convergence across dissimilar users is what justified treating both as roadmap items rather than one-off fixes.
The largest recurring theme was resource discovery, interview tips, company information, recruiter data, and a general sense that everything was scattered. Dashboard clutter and navigation came up repeatedly as well. Pooled together, resource discovery, community sharing, interview experiences, resume benchmarking, and recruiter data, several distinct complaint labels all pointed at the same missing category, which became the Internship Collective.
Learnings
Deployment deserved as much attention as development. Builds that succeeded locally failed in production over missing environment variables, and a PDF generation bug only surfaced on Vercel because the response needed to be returned as a proper Buffer, not the format that worked fine on localhost.
The bigger lesson came from reading the feedback side by side instead of reacting to each conversation individually. No user asked for a Collective. No user asked for persistent storage by name. But when several different complaints kept tracing back to one structural gap, and multiple unrelated users independently lost trust in the product over the same technical shortcut, that pattern was more reliable than any single request, and it's the difference between shipping a feature list and shipping a roadmap.
Notes
- Beta feedback collected from 20+ users across structured conversations and a rating distribution. Full dataset available on request.