ResumeCrank Has a Front Door Now
ResumeCrank is not a finished product yet, but the domain is live, the holding page has personality, and the build workflow is getting more real.
ResumeCrank has a public front door now.
That is not the same thing as launching a product. There are no users, no revenue, no resume upload flow, no account system, and no resume-generation engine yet.
But resumecrank.com is no longer just a domain sitting in a registrar account or a name floating around in planning notes. The DNS is configured, the site resolves, and there is a real holding page online.
That matters because the project has crossed a small but real threshold: it is visible.
What changed
Today I manually configured the DNS path through Netlify and AWS Route 53. After that, resumecrank.com started resolving correctly and showing the coming-soon page.
I also gave the AI tools access to both sides of the project:
- the blog / archive repo
- the product repo
The blog and project-memory work live with andrewchyde.com. The product site lives separately in the ResumeCrank repo.
That split is intentional. The product site should stay product-facing. The blog is where I can document the build process, the agent workflow experiments, the mistakes, the course corrections, and the actual engineering decisions behind the thing.
The holding page has a little personality now
I had Codex add a retro flying-Windows-style screensaver effect to the ResumeCrank coming-soon page, except the flying objects are resumes instead of windows.
That does not make the product useful yet. It does not prove the business. It does not solve the hard resume-tailoring problem.
But it does make the placeholder feel less dead.
There is also now a footer link back to the blog, so anyone who finds the product page can follow the build story without the product site itself becoming a messy build log.
That is the line I want to keep: the product can point to the story, but the product should not become the story.
Agents need memory, not just prompts
One of the less visible things I worked on was the project context layer.
I added a root AGENTS.md file to the blog/archive repo so future AI agents, coding assistants, and ChatGPT/Codex sessions have a clear starting point. That file points to the role-specific agent instructions and the durable project memory under docs/resumecrank/.
This sounds administrative, but it is the kind of thing that matters if the goal is to build with AI tools over time instead of just having one-off chats.
A single prompt is not enough. The project needs durable memory:
- What was decided?
- What is still uncertain?
- What should not be revisited unless something changes?
- What repo owns what?
- What is product-facing and what is blog-facing?
- What has actually been verified?
Without that, every session starts with a context guessing game.
What this is not
This is not a product launch.
It is not an MVP.
It is not proof that ResumeCrank has a business model.
It is not proof that AI agents are a durable differentiator by themselves.
The product still needs the hard parts: a clear first user, a narrow MVP, privacy constraints, a resume/job-post workflow, output quality checks, and a reason to exist beyond being another AI resume tool.
The open question is still the important one: what makes ResumeCrank meaningfully different from generic resume generators?
Why I still count this as progress
I count this as progress because the project is less abstract than it was yesterday.
There is now:
- a live product domain
- a visible holding page
- a product repo
- a blog/archive repo
- a root agent entrypoint
- a link between the product surface and the build story
- a clearer next step
That next step is not more placeholder polish. The next real work is deciding the first useful MVP scope.
The immediate questions are:
- Should the first wedge be high-fidelity
.docxpreservation? - Should the first target user be software developers tailoring resumes for remote roles?
- Should the first prototype use pasted text before accepting uploads?
- What privacy rules need to exist before handling real resumes?
- What is the smallest workflow that would be useful enough to test?
That is where the project needs to go next.
For now, ResumeCrank has a front door.
The product comes next.