DEV Community: Kim

How to Format Your ChatGPT Resume into a Clean PDF (Free, No Sign Up)

Kim — Wed, 18 Mar 2026 03:15:19 +0000

You asked ChatGPT to write your resume. It gave you great bullet points, a strong summary, maybe even a cover letter.

Then you pasted it into Word.

And spent 20 minutes fighting margins, spacing, and font sizes. Changed one bullet point and the whole second page broke. Tried Google Docs instead — different problems, same frustration.

Sound familiar? You're not alone. This is the gap nobody talks about: AI can write your resume, but it can't format it.

The Problem with "Free" Resume Builders

Your first instinct was probably to Google "free resume builder." You found Zety, Resume.io, or Resume Genius. You spent 30 minutes entering your info section by section. It looked great.

Then you hit Download.

"Subscribe for $24.95/month to download your resume as PDF."

Your only free option? A plain text file. No formatting. No columns. Just the text you already had.

This isn't a bug — it's their business model. Let you invest time, then charge you to get your own work back.

What You Actually Need

You don't need a resume builder. You already built it — ChatGPT did the hard part. You need a resume formatter.

Something where you can:

Paste your text
See it formatted instantly
Download the PDF
No login, no email, no credit card

OhMyDoc: Paste, Format, Download

OhMyDoc does exactly this. Here's the whole process:

Copy your resume text from ChatGPT (or wherever you wrote it)
Paste it into OhMyDoc
See a formatted preview instantly
Click Export PDF

That's it. No account. No email. No "free trial." The PDF is yours.

It's also open source — your resume text never leaves your browser. Nothing is stored on a server.

Is It ATS-Friendly?

Yes. OhMyDoc outputs clean, single-column PDFs with standard fonts. No images, no columns that confuse parsers, no invisible text boxes. The kind of format that ATS systems can actually read.

If you've been using Canva for your resume — stop. Canva resumes look beautiful but ATS systems can't parse them. (Ask any recruiter. They'll tell you the same thing.)

When to Use OhMyDoc vs. Other Tools

Your Situation	Best Tool
"I need help writing my resume"	ChatGPT, Claude, or a career coach
"I have text and need it to look good"	OhMyDoc
"I need a creative/design resume"	Canva (but know ATS won't read it)
"I need a full resume management system"	Teal, Reactive Resume

The 2-Minute Resume Workflow

Here's what I recommend for anyone job hunting right now:

Write your resume with ChatGPT or Claude (use the job description as context)
Format it with OhMyDoc — paste, preview, export
Check the PDF by uploading it back to an ATS checker
Apply

Total time from AI draft to submitted application: under 5 minutes.

No accounts created. No subscriptions. No fighting with Word margins.

Try It

ohmydoc.vercel.app — paste your resume, get a PDF. That's the whole pitch.

I Let AI Agents Build My Entire Side Project — Here's What Happened

Kim — Sun, 15 Mar 2026 06:45:01 +0000

I had a simple problem: every "free" resume formatter online requires an account, upsells you to a paid plan, or rewrites your content with AI. I just wanted to paste text, make it look decent, and save as PDF.

So I did something weird — I let AI agents build the entire thing.

The Frustration

Here's what happens when you google "free resume formatter":

Canva — free to format, $12.99/month to export without watermark
Resume.io — free to build, paywall on download
Zety — 14-day "trial" that auto-charges
Google Docs — actually free but requires opening Google Docs (the horror)

Every single one wants your email. Most want your credit card. None of them just... format text and let you save it.

The Experiment

I gave Claude Code a simple prompt: build a web app where I paste my resume as plain text on the left, see it formatted on the right, and can export to PDF.

The result is OhMyDoc.

What the AI Built

The core flow:

Left pane: paste your resume or cover letter as plain text
Right pane: instantly see it with clean, professional typography
One click: export to PDF via the browser's print dialog

The surprise feature — XML editor:
This is the part I didn't ask for but love. When AI generates your resume content (ChatGPT, Claude, etc.), you always want to change a few words before sending. Most tools force you back through the AI. OhMyDoc has an XML editor that lets you tweak specific text directly in the document structure.

Why is this useful? Because when an AI writes "Spearheaded cross-functional synergies" and you want to change it to "Led the project," you don't need another AI round-trip. Just edit it.

What it doesn't do:

No login or signup
No email capture
No AI rewriting your content ("Your content has been formatted but not rewritten")
No data leaves your browser
No freemium upsell — it's genuinely, completely free

The Technical Reality

ClaudeCode built the entire thing as a Next.js app deployed on Vercel:

Framework: Next.js
Hosting: Vercel (free tier)
Database: None — everything runs client-side
Monthly cost: $0
AI involvement in runtime: Zero — the AI built the app, but the app itself uses no AI

That last point is important. OhMyDoc doesn't use GPT or Claude to format your document. It uses deterministic parsing and CSS. Same input, same output, every time. The AI wrote the code; the code does the work.

What I Learned About AI-Built Projects

It's fast. The initial version was functional in under an hour. Styling, layout, PDF export, sample templates — all generated.

It over-engineers. The XML editor? I didn't ask for it. Claude Code decided the app needed it and built it. Turns out it was right — it's genuinely the most useful feature.

It under-designs. The visual design is competent but not memorable. An AI can build a clean UI but it won't build a distinctive one. Every AI-built app has the same Tailwind energy.

It ships. This is the part that matters. The app works. It solves the problem. It's live, it's free, and it took negligible human effort to build.

Try It

OhMyDoc — paste your resume, get a clean PDF. Try the sample to see it in action.

The entire source is on GitHub.

If you've built something interesting with AI coding agents, I'd love to hear about it in the comments. Especially curious about projects where the AI surprised you with features you didn't ask for.

Built by AI agents. Maintained by a human who just wanted a simple PDF.

How I Built a Personal Trainer Matching Algorithm (That Actually Works)

Kim — Sat, 14 Mar 2026 03:26:50 +0000

Most people find their personal trainer the same way they find a plumber: Google Maps, check a few reviews, and hope for the best.

I thought we could do better.

The Problem Nobody Talks About

Here's what happens when you search "personal trainer Toronto":

Google shows you whoever paid for ads
Yelp shows you whoever has the most reviews (correlation with quality: questionable)
Instagram shows you whoever posts the most shirtless photos
Your friend recommends whoever they like — which might be a terrible fit for you

None of these answer the actual question: will this trainer's coaching style work for me?

A powerlifter who wants someone screaming at them during sets needs a very different trainer than someone recovering from an injury who wants gentle guidance. Both are valid. Neither will be happy with the other's trainer.

The Hypothesis

What if we could match people to trainers the same way dating apps match people — not on location or price, but on compatibility?

I built FitMatch to test this. It's a 60-second quiz that scores you against 30 real Toronto personal trainers across 5 dimensions.

The Five Dimensions

After researching what actually matters in a trainer-client relationship, I landed on five scoring dimensions:

Dimension	Weight	Why It Matters
Training Goal	30%	A bodybuilding coach and a rehab specialist are different species
Coaching Style	20%	Drill sergeant vs. supportive guide — this is the #1 mismatch
Feedback Style	20%	Some people want data and metrics. Others want 'great job, keep going'
Programming Structure	20%	Rigid periodized plans vs. flexible 'let's see how you feel today'
Check-in Frequency	10%	Daily accountability vs. weekly touchpoints

The weights aren't arbitrary. Training goal gets 30% because if a trainer specializes in marathon prep and you want to powerlift, nothing else matters. Check-ins get 10% because it's the easiest dimension to adjust.

The Scoring Math

Each dimension produces a score from 0-100 based on how closely the user's answer matches the trainer's profile.

fitScore = (goalMatch × 0.30) +
           (styleMatch × 0.20) +
           (feedbackMatch × 0.20) +
           (structureMatch × 0.20) +
           (checkinMatch × 0.10)

For each dimension, matching works like this:

Exact match: 100 points
Adjacent preference: 50-75 points (e.g., 'structured' trainer with a 'somewhat flexible' user)
Opposite ends: 0-25 points

The result is a score from 0-100 for every trainer, which maps to labels:

🟢 75-100: 'Strong fit' — your styles align
🟡 50-74: 'Decent fit' — could work with some adjustment
🔴 Below 50: 'Different styles' — probably not your person

Why Not Use AI/ML?

I hear you. 'Why not throw embeddings at this?'

Because the dataset is 30 trainers, not 30,000. Machine learning on 30 data points is just overfitting with extra steps. The weighted scoring approach is:

Transparent: Users can understand why they matched
Debuggable: When a match feels wrong, I can trace exactly which dimension caused it
Tunable: Adjusting weights based on user feedback is trivial
Fast: No model inference, no API calls — runs entirely client-side

Sometimes the boring solution is the right solution.

The Cold Start Problem

The tricky part wasn't the algorithm — it was getting trainer data. Trainers didn't sign up for this. I had to:

Research 30 real Toronto trainers manually
Infer their quiz answers based on their websites, social media, and client testimonials
Build profiles that honestly represent their coaching style

This is the uncomfortable truth about two-sided marketplaces: someone has to go first. My bet is that trainers will opt in after they see 'someone took a quiz and matched with you as a Strong Fit — want their contact info?'

That email pipeline isn't wired yet. Right now, FitMatch is a discovery tool: take the quiz, browse your matches, visit their websites directly.

The UX Decisions

A few things I got right (I think):

One question per screen. Early versions showed all 6 questions on one page. Completion rates were terrible. One-per-screen with tap-to-advance felt more like a personality quiz and less like a form. Completion jumped immediately.

No account required. Zero friction to results. You can take the quiz in 60 seconds and see every trainer ranked. Email capture is optional ('let your top matches know you're interested').

Show all 30 trainers. My instinct was to show only the top 5. But users want to scroll. Seeing a trainer ranked #22 with a 45% fit score actually increases trust in the algorithm — 'oh, it's not just showing everyone as a perfect match.'

The Stack

Nothing fancy:

Next.js — pages + API routes
Vercel — hosting and edge functions
No database — trainer profiles are static JSON (for now)

Total infra cost: $0/month.

What I'd Do Differently

Weight validation. The 30/20/20/20/10 split was my best guess based on research. I should have A/B tested different weight distributions from day one.

Trainer opt-in first. Bootstrapping with inferred profiles was pragmatic but creates a trust gap. If I were starting over, I'd cold-email 10 trainers first and build profiles collaboratively.

Fewer dimensions. Five dimensions might be over-engineering it. I suspect goal + coaching style alone (two dimensions) would get you 80% of the matching accuracy. The other three add precision but also add quiz length.

Try It

If you're in Toronto and looking for a trainer (or just curious), take the quiz. It's free, takes 60 seconds, and doesn't require an account.

If you're a developer building a matching/recommendation system: weighted scoring is underrated. It's simple, interpretable, and works surprisingly well at small scale. Save the ML for when you have the data to justify it.

I'm building this as a solo side project. If you want to follow along or have feedback, drop a comment — I'm actively iterating based on what I hear.

I Analyzed 17 Popular GitHub Repos — Here's What Their Codebases Are Actually Made Of

Kim — Sat, 07 Mar 2026 04:21:13 +0000

I wanted to answer a simple question: what are popular open source projects actually made of?

Not what their README says. Not what their marketing page claims. What does the code itself reveal?

So I pointed RepoCrunch — a deterministic repo analyzer I built — at 17 well-known GitHub repositories and collected the data.

Here's what I found.

🦀 Rust is quietly eating JavaScript tooling

This was the biggest surprise. Three "JavaScript ecosystem" tools have significant Rust codebases:

Project	You'd think it's...	Actually...
Next.js	JavaScript	13.5% Rust
Tailwind CSS	CSS/JS	16.0% Rust
Deno	JavaScript runtime	59.4% Rust

Next.js — the React meta-framework — is 13.5% Rust. Tailwind CSS is 16% Rust. These aren't Rust projects. They're JavaScript tools that have quietly moved performance-critical paths to Rust.

And then there's Deno: marketed as a JavaScript/TypeScript runtime, but it's actually a Rust project (59.4%) that happens to run JavaScript.

Meanwhile, uv — Python's fastest package manager — is 98.1% Rust. A Python tool with essentially zero Python.

The pattern is clear: Rust is becoming the systems language behind dynamic language ecosystems. If you're building dev tools in 2026, Rust is the performance layer you reach for.

📦 Dependency counts tell very different stories

Project	Direct Dependencies	Stars
Django	3	87K ⭐
FastAPI	5	96K ⭐
Flask	6	71K ⭐
NestJS	19	75K ⭐
Express	28	69K ⭐
VS Code	49	182K ⭐
Angular	104	100K ⭐

Django runs on 3 dependencies. The most popular Python web framework, powering Instagram and Spotify, depends on just three external packages.

Compare that to Angular's 104 direct dependencies. That's not inherently bad — they're a full framework with more surface area. But it's a fundamentally different philosophy: own everything vs. compose from parts.

The Python ecosystem clearly leans minimal. FastAPI (5 deps) and Flask (6 deps) follow the same pattern. Node.js frameworks consistently pull in more.

🏥 Open issues don't mean what you think

Project	Open Issues	Stars	Ratio
Flask	3	71K	1 per 23,777 ⭐
NestJS	42	75K	1 per 1,783 ⭐
Tailwind	84	94K	1 per 1,118 ⭐
FastAPI	145	96K	1 per 662 ⭐
Angular	1,131	100K	1 per 88 ⭐
Prisma	2,505	45K	1 per 18 ⭐
uv	2,716	80K	1 per 30 ⭐
Rust	12,155	111K	1 per 9 ⭐
VS Code	14,704	182K	1 per 12 ⭐

Flask has 3 open issues. VS Code has 14,704.

Does that mean Flask is better maintained? Not exactly. Flask is a mature, stable project with a narrow scope. VS Code is an IDE used by millions — every edge case becomes an issue.

Issue count scales with surface area and user base, not with code quality. Rust (the language) has 12K open issues because building a compiler for millions of developers generates a lot of edge cases.

The interesting outlier is Prisma — 2,505 open issues against just 45K stars. That's one of the highest issue-to-star ratios in this dataset. It suggests either a broader surface area than its star count implies, or maintenance challenges.

🧬 TypeScript won — but not everywhere

Primary Language	Projects
TypeScript	Angular, VS Code, NestJS, Vue, Prisma, Supabase
JavaScript	React, Svelte, Express, Next.js
Python	Django, Flask, FastAPI
Rust	uv, Deno, Rust-lang

TypeScript is the plurality leader for large-scale projects. But look more closely:

React is still primarily JavaScript (68.1%) — Facebook's flagship UI library hasn't fully migrated
Svelte is 71.8% JavaScript — Rich Harris chose to keep the compiler in JS
Vue went all-in on TypeScript (96.6%) — a deliberate rewrite choice for v3

The JS-vs-TS split often comes down to project age and rewrite ambition. Vue rewrote from scratch for v3 → TypeScript. React is incrementally migrating → still mostly JavaScript.

👥 Who actually builds these things?

Project	Contributors	Age (years)
Rust	8,257	15.7
Next.js	4,060	9.4
Django	3,405	19.1
VS Code	2,940	10.4
Angular	2,577	11.5
React	1,971	12.8
Supabase	1,852	5.6
Express	377	14.6
Tailwind	344	8.5
Prisma	355	5.7

Express — the backbone of Node.js servers — has been maintained by just 377 contributors over 14.6 years. Compare that to Next.js with 4,060 contributors in under 10 years.

Supabase stands out: 1,852 contributors in just 5.6 years. That's community velocity.

And Tailwind CSS — used on millions of websites — has just 344 contributors. A small team can build something with massive reach.

How I got this data

All of this came from RepoCrunch — a tool I built that analyzes GitHub repos into structured JSON. No AI, no LLMs, fully deterministic.

pip install repocrunch
repocrunch analyze vercel/next.js --pretty

It parses real repo data — languages, dependencies, CI setup, health metrics — and gives you structured facts. I built it because I was tired of asking ChatGPT "what's this repo built with?" and getting hallucinated answers.

It also works as an MCP server, so your AI coding assistant can look up real repo data instead of guessing.

The raw data is what it is. Next.js is 13.5% Rust. Django has 3 dependencies. Flask has 3 open issues. These aren't opinions — they're measurements.

What surprised you most? I'd love to hear what repos you'd want to analyze next.

Originally published at getjustgo.com

I Analyzed 8 Popular Frameworks — Here's What Their Codebases Are Actually Hiding

Kim — Fri, 06 Mar 2026 17:54:39 +0000

GitHub tells you the "primary language" of a repo. That label is... incomplete.

I've been building a tool that pulls structured data from any GitHub repo — language breakdown, dependencies, health metrics, CI setup, security signals — and decided to point it at some of the most popular frameworks on the planet.

A few things caught me off guard.

The Data

Framework	Stars	Open Issues	Contributors	Hidden Detail
Next.js	137.6K	3,298	4,037	13% Rust (Turbopack)
Go	132.3K	—	—	5.4% Assembly (runtime)
FastAPI	94.9K	168	886	Only 5 direct dependencies
Django	86.7K	405	3,383	Zero Docker config
Flask	71.1K	3	862	3 issues. That's it.
Express	68.7K	183	373	100% JavaScript
Rails	58.2K	1,457	6,906	Most contributors of any framework
LangChain	—	407	3,631	3,631 contributors in 2 years

The Surprises

Next.js is 13% Rust

Not a typo. Turbopack — the Rust-based bundler — accounts for a significant chunk of the Next.js codebase. GitHub labels it "JavaScript" because that's the plurality language, but the reality is JS (56%) + TypeScript (30%) + Rust (13%).

If you're evaluating Next.js as a dependency, "it's a JavaScript framework" is technically true but practically misleading. Turbopack means Rust compilation is part of your build chain.

Flask Has 3 Open Issues

Three. On a 71,000-star project.

Compare that to Next.js (3,298) or Rails (1,457). The Pallets team runs the tightest ship in open source. Some people see low issue counts and think "dead project." Flask proves that's wrong — it's just aggressively managed.

Express Is Still 100% JavaScript

No TypeScript migration. No Rust rewrite. No drama. Sixteen years, 68K stars, pure JavaScript.

Every new Node framework launches in TypeScript these days. Express just... doesn't. And it works fine. Sometimes boring is the feature.

Go Is 5.4% Assembly

Makes total sense for a language runtime and compiler, but GitHub's language bar rounds this away. You'd never know from the repo page that a meaningful chunk of Go is hand-written assembly for the garbage collector and runtime.

FastAPI Has Only 5 Direct Dependencies

For a full-featured web framework, that's remarkably lean: Starlette, Pydantic, typing-extensions, typing-inspection, annotated-doc. Minimal dependency surface = fewer supply chain risks.

Rails Has the Most Contributors by Far

6,906 contributors — nearly double LangChain (3,631) despite Rails being 18 years old. That's not just open source; that's a civilization.

How I Got This Data

I built RepoCrunch — a Python CLI that analyzes any GitHub repo and returns structured JSON. No AI, no hallucination, just deterministic data from the GitHub API.

pip install repocrunch
repocrunch analyze vercel/next.js --pretty

It returns everything you see above: language breakdown, dependency count, CI setup, maintenance status, security signals.

Why Structured Output Matters

The real reason I built this: I wanted my AI coding tools to have factual repo data instead of guessing. RepoCrunch has a built-in MCP server:

repocrunch mcp

Add it to your Claude Desktop or Cursor config, and your AI assistant can answer "is this repo safe to depend on?" with actual data instead of its training weights.

Sample output (FastAPI):

{
  "summary": {
    "stars": 94912,
    "license": "MIT",
    "primary_language": "Python"
  },
  "tech_stack": {
    "framework": "Starlette",
    "package_manager": "pdm",
    "key_deps": ["starlette", "pydantic"]
  },
  "health": {
    "open_issues": 168,
    "contributors": 886,
    "commit_frequency": "daily",
    "maintenance_status": "actively_maintained"
  }
}

What's Next

I'm thinking about running this against the top 50 Python packages and publishing the results. If there's interest, I'll do a follow-up with more repos and more surprising findings.

Curious what metrics you'd actually want to see when evaluating a dependency. Stars? Commit frequency? Something else entirely?

Links:

GitHub: kimwwk/repocrunch
PyPI: pip install repocrunch
MCP mode: repocrunch mcp (for Claude/Cursor integration)

My AI Agent Kept Recommending Abandoned Repos. So I Built RepoCrunch.

Kim — Thu, 19 Feb 2026 04:42:05 +0000

I've been building AI agents that evaluate GitHub repos — picking dependencies, reviewing codebases, comparing tools. The problem? They hallucinate.

Ask an LLM "is this repo well-maintained?" and you'll get a confident answer based on vibes. Not data. My agent kept recommending packages that were archived, had 2 commits in the last year, or had open CVEs.

So I built RepoCrunch — a CLI tool and MCP server that gives AI agents ground-truth GitHub intelligence.

What it does

Point it at any public GitHub repo and get deterministic, structured JSON:

Tech stack detection — languages, frameworks, build tools
Dependency analysis — what it uses, version info
Health metrics — stars, issues, contributors, commit frequency
Security indicators — CI/CD setup, known vulnerability patterns
Architecture signals — project structure, patterns used

The key word is deterministic. Same repo, same output. No interpretation, no hallucination.

Three ways to use it

1. CLI

pip install repocrunch
repocrunch analyze https://github.com/fastapi/fastapi

2. MCP Server (for AI agents)

repocrunch mcp

Drop this into your Claude Desktop, Cursor, or any MCP-compatible client. Your agent gets real repo data instead of guessing.

3. REST API

repocrunch serve

Why MCP matters here

The Model Context Protocol lets AI agents call external tools. When your agent needs to evaluate a dependency, it can call RepoCrunch and get facts — not generate them from training data.

This is the difference between:

❌ "FastAPI appears to be well-maintained based on my knowledge"
✅ "FastAPI has 847 contributors, 12.3k commits, last push 2 hours ago, MIT license, CI passing"

The real use case

I built this for my own AI agent workflow. When my agent evaluates whether to use a library, it runs RepoCrunch first. The structured output feeds directly into the decision — no guessing.

But it works for anyone who needs repo intelligence:

Dependency auditing — are your deps actually maintained?
Due diligence — evaluating repos before adoption
Portfolio monitoring — tracking health of repos you depend on

Try it

pip install repocrunch
repocrunch analyze https://github.com/your-favorite-repo

GitHub: github.com/kimwwk/repocrunch
PyPI: pypi.org/project/repocrunch

Open source, MIT licensed. Feedback welcome — especially from folks building MCP toolchains.

Built this as a solo dev scratching my own itch. If you're doing anything with AI agents + code evaluation, I'd love to hear how you're solving the hallucination problem.