The Product Isn’t Live Yet, But the Operating Loop Is

ResumeCrank is not launched.

There is no polished product demo yet. There are no users. There is no revenue. There is not even a real homepage beyond the coming-soon path I am working toward.

But today still felt like a real checkpoint.

Not because the product is done. Because the operating loop started to work.

That may sound like a small distinction, but for this project it matters. ResumeCrank is not only an idea for an AI-assisted resume and job-application tool. It is also an experiment in how far I can get as one experienced engineer using AI tools, agent-style workflows, GitHub, Netlify, and public documentation without pretending the agents are magic.

If that workflow cannot remember what happened yesterday, preserve decisions, separate strategy from implementation, and move work safely through review, then the product idea is almost beside the point.

So today was about making the project easier to continue tomorrow.

The blog is live

I now have andrewchyde.com live again, and I am treating it as the blog for this work.

That matters because I want a clean separation between the product and the build story.

The split is simple:

resumecrank.com = the product site
andrewchyde.com = the blog / build-in-public site

ResumeCrank should eventually be where someone goes to use the thing. AndrewHyde.com is where I can write honestly about building it.

That separation is intentional. The product site should not become a dumping ground for messy planning notes, agent workflow debates, or personal material that does not help a customer trust the product. The blog can be more reflective, more technical, and more honest about the process.

The archive stopped being loose notes

A big part of today was cleaning up the project memory.

That sounds boring. It kind of is. But it is also the difference between a project that survives past a few enthusiastic chats and one that can actually accumulate progress.

Earlier, the project had one large canon file and a first session archive. That was good enough to start, but too much was buried in one place. Durable decisions were mixed into session summaries. Open problems were mentioned but not tracked as their own records. Agent responsibilities existed, but the overall topology was not explicit enough.

So the archive got split into more useful pieces:

• project canon
• brand canon
• workflow canon
• decision records
• open-problem records
• session summaries
• blog-source notes
• handoffs
• status
• backlog
• agent topology

That may be overkill for a normal side project. For this one, I think it is necessary.

The point is not paperwork. The point is continuity.

If I come back tomorrow and ask an AI agent to help, I do not want it guessing what we decided. I want it reading the project state from files.

Agents need memory, not just prompts

One lesson keeps getting clearer: prompts are not enough.

A prompt can tell an agent what to do right now. It does not automatically give the agent durable memory, good judgment, or the ability to distinguish a settled decision from a passing thought.

For ResumeCrank, I am trying to treat the repo as the project memory layer.

The chat is useful, but it is not the source of truth. The source of truth needs to be something future sessions and tools can inspect directly.

That led to an explicit agent topology file. Each agent has a role:

• Archive Agent
• Blog Agent
• Strategy Agent
• Coding Agent
• Review Agent

The important part is not the names. The important part is the boundaries.

The Coding Agent should not invent product strategy. The Blog Agent should not claim features that do not exist. The Archive Agent should not turn every thought into canon. The Review Agent should not rubber-stamp output just because another agent produced it.

This is the kind of structure that feels unnecessary until the first time the project loses context and starts contradicting itself.

A PR, a preview, and a merged cleanup

The archive cleanup was done on a branch, opened as a pull request, reviewed through the normal GitHub flow, and then merged.

Again, not glamorous. But it matters.

That means the project now has a real loop:

conversation → archive/canon changes → branch → PR → preview/review → merge

That is closer to an engineering process than a brainstorming session.

It also exposed a tooling problem: using the ChatGPT GitHub connector for lots of file edits is painful. It behaves more like repeated file-level operations than a normal git workflow. For a multi-file archive update, that means too many separate writes, too much approval friction, and occasional UI hangs.

That is now a known problem to solve later. The better long-term answer is probably a local git workflow, Codex, or some MCP-style tool that can write multiple files, show a diff, commit once, and push once.

For now, the lesson is clear: the current connector is useful for small surgical edits, but bad for heavy archive operations.

The product domain is moving toward a placeholder

On the product side, I cleaned up unused AWS Route 53 hosted zones and pointed the DNS path for resumecrank.com toward Netlify.

Now I am waiting on DNS propagation.

The expected result is simple: resumecrank.com should load a coming-soon banner.

That is not a launch. It is not even an MVP.

But it is still a real step. A domain that resolves to a placeholder is more real than a domain sitting unused. It creates a public surface. It forces decisions. It starts turning the project from idea-space into something with edges.

The next product-side step is to create the private GitHub repo for the product site, likely resumecrank_com, add a tiny placeholder site, and connect it to Netlify.

I almost distracted myself with another domain

I also realized I own spyproperty.com.

That domain has potential. The idea would be a property visibility product: helping landlords or small property managers see what is really happening across scattered rent, maintenance, tenant, and document data.

The “spy” part is not about surveillance. The better framing is more like a nautical spyglass: seeing through fog, finding truth in a sea of data, getting visibility across properties.

That could be a real product someday.

It might even have a higher business ceiling than ResumeCrank.

But it also has a higher barrier to entry: payments, tenant data, maintenance workflows, property-management incumbents, support burden, privacy concerns, and a more complex sales motion.

So the decision for now is simple: ResumeCrank stays the active experiment. SpyProperty goes on the shelf.

That is not because SpyProperty is bad. It is because switching now would be a classic way to lose momentum.

What changed today

By the end of the session, the project had a much clearer shape:

• andrewchyde.com is the blog.
• resumecrank.com is the product site.
• spyproperty.com is parked for later.
• The archive/canon cleanup is merged.
• The agent topology exists.
• The workflow canon is more explicit.
• The project has status and backlog files.
• The session archive now produces handoffs for the next session.
• Netlify visibility and full ChatGPT transcript capture are known workflow gaps.
• The next goal is to get a credible ResumeCrank placeholder live.

That is not the kind of progress that looks impressive in a screenshot.

But it is the kind of progress that makes tomorrow easier.

The real milestone

The product is not live yet.

But the operating loop is starting to exist:

blog → archive → canon → decisions → handoffs → PRs → previews → deployment → next session

That loop is the thing I need before the product can grow without collapsing into scattered notes and half-remembered decisions.

I am still at the beginning. The product differentiator is not fully settled. The first MVP scope is not locked. The Netlify and transcript workflows still need work.

But today made the project more durable.

And for this stage, that counts.