Choosing a Smaller MVP for ResumeCrank

The ResumeCrank MVP got smaller today.

That is probably a good sign.

The tempting version of this product is ambitious: upload any existing resume, preserve its exact Word formatting, tailor it to a job posting, and get back a polished .docx that looks like nothing broke.

That is a great promise. It may still be worth chasing later.

But it is not the right first promise.

The hard part was hiding in the formatting

At first, high-fidelity .docx preservation felt like the obvious wedge. Generic AI tools can write resume text. A better tool could preserve the actual professional document.

The problem is that arbitrary Word documents are not simple. They carry styles, spacing, bullets, tables, headers, fonts, section breaks, and layout decisions that may not be obvious from the text alone.

Trying to support every resume format on day one would turn the first MVP into a document-formatting project before the actual workflow had been proven.

That is too much surface area.

The smaller version

The better first version is more constrained:

1. Extract the resume content.
2. Parse it into structured fields.
3. Show the user what the system thinks it found.
4. Let the user correct anything it misunderstood.
5. Tailor the structured content against a job posting.
6. Render the result into a controlled ResumeCrank template.

That changes the product promise.

Instead of:

Upload any resume and ResumeCrank preserves the exact format.

The first version becomes:

ResumeCrank turns resume content into structured, editable sections and generates a clean tailored .docx from controlled templates.

That is less magical.

It is also more buildable.

Controlled templates are not a cop-out

A few good templates may be enough for the first version.

The point is not to win a design contest. The point is to create predictable, editable, job-specific output that does not silently mangle the user’s resume.

If the system controls the templates, the product can test them. It can verify expected sections. It can generate consistent .docx files. It can avoid spending the first month fighting random layout edge cases.

That matters more than pretending version one can handle every document ever created in Microsoft Word.

The correction step matters

The parser will make mistakes.

The model will make mistakes.

That does not automatically kill the product. It just means the product should not hide the interpretation step.

If ResumeCrank extracts a resume into structured fields, the user should be able to edit those fields before generation:

• contact information
• summary
• skills
• experience
• bullet points
• projects
• education

That correction step is not just a UI feature. It is part of the safety model.

Opaque generation is risky. Reviewable structure is better.

The boring milestone: tests first

The other thing that happened today was less visible but important: the product repo now has baseline test infrastructure.

Codex added the initial setup for:

• Astro checks
• Vitest unit tests
• Playwright smoke tests
• GitHub Actions CI

That is not the product.

But it is the foundation the product should be built on. If ResumeCrank is going to generate documents, handle structured data, and make claims about preserving correctness, it needs tests before the clever parts get too clever.

Backend is still open

I also spent time thinking through backend options.

The answer is not final yet.

A normal synchronous serverless function may not be enough if tailoring takes longer than a minute. A local Ollama worker could be useful for a free internal prototype, but Ollama is not something I can just run inside a Netlify function. A paid model API is cleaner but costs money. Netlify Background Functions may work for an async MVP if the workflow uses job IDs, status polling, and stored results.

That decision is still open.

Privacy is also still open. Resume data is sensitive. Before ResumeCrank accepts real user material through a public workflow, I need clear rules for what is stored, logged, retained, deleted, and sent to any model provider.

What changed today

The project has a sharper first-MVP direction now:

• structured resume data
• controlled templates
• user correction hooks
• test-backed implementation
• backend and privacy still to be decided

That is not a launch.

It is not a working MVP.

But it is a better direction than trying to solve arbitrary document preservation before proving the core workflow.

The next work is to choose the backend/privacy path and turn this into a focused implementation handoff.

The MVP got smaller today.

Good.