Building ResumeCrank: Async First, Cheap First

Today I made a small but important architecture decision for ResumeCrank: the first backend should stay Netlify-native, and the document-processing work should be asynchronous from the beginning.

That sounds less exciting than saying I built an AI resume product. It is also much more accurate.

ResumeCrank is still not launched. It does not have users, accounts, payments, public uploads, or production resume automation. Right now the useful work is narrowing the product until the first version is small enough to build and honest enough to test.

The backend decision

The current direction is to build the MVP as cheaply as possible. Since the product site is already on Netlify, the first backend path will use Netlify backend functions instead of introducing a separate backend too early.

The important part is not just “use Netlify.” The important part is how the work should flow.

Resume extraction and controlled template generation should not be treated as one simple upload-and-return request. They should be treated as jobs.

The first shape should look more like this:

create job -> process in background -> poll status -> retrieve result

Normal Netlify Functions can handle job creation, validation, status checks, and result retrieval. Netlify Background Functions, or a similar Netlify async pattern, can handle extraction and document generation.

Why async now?

The tempting first version is straightforward:

1. Upload a .docx resume.
2. Parse it.
3. Generate a new .docx.
4. Return it immediately.

That is easy to picture, but it bakes in a risky assumption: that document work will always be fast and predictable.

Maybe the first few test documents are fast. Maybe mammoth extraction is fine. Maybe docxtemplater generation is fine. But resume processing will eventually include larger files, imperfect documents, status reporting, template generation, and probably job-specific tailoring. Later, AI may help with rewriting, unsupported-claim checks, and verification notes.

That kind of work should not pretend to be instant.

Starting async adds a little structure up front, but it avoids redesigning the flow when the product gets more realistic.

Cheap-first is not no-architecture

I am trying to keep ResumeCrank cheap. That does not mean I want the backend to be accidental.

A separate backend, database, queue, worker service, or paid model dependency may make sense later. But adding those before the MVP proves it needs them would create cost and complexity before the product has earned either.

The current rule is simple:

Stay Netlify-native until the MVP proves it needs more.

That gives the project a practical constraint. It also defines the next implementation slice much more clearly.

What this means for the MVP

The ResumeCrank MVP is still template-constrained structured resume tailoring.

The first document pipeline remains:

uploaded .docx -> mammoth extraction -> structured resume parser -> docxtemplater controlled template -> generated .docx

The product is not trying to preserve arbitrary uploaded Word formatting in version one. It will treat the uploaded resume as a content source, extract the information, let the user correct structured fields, and generate a clean .docx from controlled templates.

The backend decision means that extraction and generation should fit into a job flow from the start.

That makes the first implementation slice something like:

• create a job
• validate the input
• process the job asynchronously
• update job status
• return structured results
• later generate a controlled .docx

Before any public resume upload exists, I still need to define privacy and data-handling rules. Resume files and job-application material are sensitive. The product should not casually store them, log them, or send them around without clear rules.

The next hard part

The backend path is narrower now, but it is not done.

The next decisions are more specific:

• What temporary storage should the first async Netlify implementation use?
• What gets retained, and for how long?
• What should never be logged?
• What is the first structured resume schema?
• What are the first controlled templates?
• How much correction UI belongs in the first slice?

That is the useful shape of progress right now. Not a launch. Not a big AI claim. Just one more constraint that makes the next piece easier to build.