Career Craft.ing

I had one of those solo-builder weeks where the correct answer was obvious.
Spend more time on distribution.

But the product kept showing me small rough edges that were close enough to fix.

So I split the week between both.

What I shipped

I published and refined comparison pages so careercraft.ing is easier to understand against tools like ChatGPT, Claude, Notion, Teal, Career Capital, and BragBook.

That sounds like marketing work, but it forced a useful product question:
;what is this thing actually for?

The answer kept coming back to the same point.

careercraft.ing is not trying to be a generic writing assistant or another place to store notes. It is meant to help engineers preserve career evidence while the details are still fresh.

I also worked on:

• a memory quality model

• a memory assistant rail

• consolidated enhancement actions

• cleaner create actions in the app header

• mobile navigation for the marketing site

• homepage hero and evidence section updates

• marketing-site performance cleanup

• public report rendering refactored into proper components

Not all of that is launch-worthy by itself, but together, it made the product feel more aligned with the promise.

What I published

The public message this week was: weak career outcomes often come from weak evidence, not weak work.

I posted around that idea on LinkedIn and X:

• why I started building careercraft.ing

• why engineering impact decays if you do not capture the context early

• why managers cannot defend vague work in calibration

• why better self-review bullets start before you open the review form

• why solo building keeps pulling me between distribution and product polish

The strongest line for me was this: same work, better evidence.

That is the whole product in four words.

What worked

The product work and the content finally started reinforcing each other.

If I say "same work, better evidence," the app needs to help someone actually get there.

So a raw note like:

Helped with auth cleanup.

should move closer to:

Reduced auth-related support escalations by making failure states explicit and easier to debug.

That is the standard I want the product to hold.

What did not work

I still feel the pull toward polishing. Some of it was useful. The comparison pages, homepage work, and memory UX improvements all made the product clearer.

But some of it was probably a way to avoid the harder work of distribution.

That is the uncomfortable part of building alone.

You can always find one more product improvement that feels just close enough to justify.

Next week

I want to keep the product sharp, but make the weekly update loop more systematic:

• what shipped

• what got published

• what I learned

• what I am doing next

And I want to get better at deciding when a small product improvement is genuinely high leverage, and when it is just a more comfortable task than talking to people.

How do you decide when to polish the product versus forcing yourself back into distribution?

This week I shipped something that made careercraft.ing feel much more like a real MCP App.

Until now, the memory flow was functional, but still a bit too tool-shaped.

You could create a memory.
You could save it.
But the experience around that step was not yet good enough.

So in Week 5 I focused on turning that into a proper preview flow thanks for the MCP Apps integration.

Now the app can generate a memory preview, render it in a custom UI, show suggested tags, and let the user explicitly decide whether to save it.

That sounds like a UX improvement.
It is. But it also changed the product boundary in an important way.

I do not want memory capture to feel like:
"send text in, hope the server did something sensible, check later."

I want it to feel like:
"here is the draft, here is what the system understood, now confirm it."

Under the hood, that meant:

• a KV-backed preview/save flow

• a custom MCP App UI for previewing memories

• cleaner loading and error states

• tighter workflow documentation

• a better separation between preview generation and final persistence

And almost immediately after that, another issue became obvious:
once the UX gets better, the data path underneath it has to be tighter too.

So the current follow-up PR is focused on reliability:

• reducing memory lookup and hydration query fanout

• hardening tag creation/sync to avoid duplicate or race-prone associations

• improving fallback behavior when the preview app is not available

That second part is less visible, but probably just as important.

A polished preview is nice.
A preview that saves the wrong thing, duplicates tags, or makes too many DB calls is not.

I like this kind of week because it feels honest:
not a huge launch, not growth theater, ljust turning a promising interaction into something more trustworthy.

Next step is to finish the optimization pass, keep tightening the memory workflow, and make the whole loop feel fast enough that you would actually want to use it repeatedly.

https://youtu.be/QCV0OMlLfdw

Another week came by and the launch date is getting closer. This week I worked on something that is not very glamorous, but felt necessary before I push harder on distribution.

I rebuilt the public waitlist flow so it feels like a real product surface instead of just "enter email and disappear into a generic next step."

I still have no real traction yet. Traffic is low, subscribers are at zero, and that is obviously the uncomfortable part of writing these updates publicly.

But product work is moving well, and I am close to finishing a feature that could open a new distribution channel for the project. So I thought this was the right moment to improve the first impression a potential user gets when they show interest by leaving their email address.

So I focused on making the post-submit experience feel more deliberate.

Before, a new signup could land too quickly in the rewards area, which did not feel right for someone who had just joined.

Now the flow is clearer:

- first-time signup goes to a proper success page
- returning users are handled differently
- the share step feels intentional instead of bolted on afterward

That may sound like a small UX change, but I think it matters a lot.

If someone gives you their email this early, the product has to respond with clarity. It has to confirm what just happened, what they should expect, and what they can do next.

And about what they can do next: I implemented a set of platform-specific share-ready messages that users can copy with one click and post on the social network of their choice.

I also spent time making the system itself more solid than it probably needed to be for this stage:

- cleaned up the waitlist response handling so errors and success states are parsed consistently
- tightened the metadata so I was not leaking query-param junk into shared URLs
- made the flow distinguish properly between first-time signups and existing subscribers
- improved the success page so sharing the product feels more natural

This is probably a mild case of over-engineering for a waitlist that still has no audience 😅

But I also think early acquisition systems are exactly where sloppiness compounds. If the first people I convince to check the product get a confusing flow, that costs more than the extra effort I spent tightening it.

## What is next:

I know UI/UX improvements never sound that exciting, and since I am a Frontend Engineer it could look like I am playing from the comfort zone. But that's not entirely true...

This week I have also been working on a feature that I will share properly in the next update: a custom UI that lets users preview and save a memory into the system, making the server feel more like a real MCP App. I want to fix a few UI inconsistencies with the main platform first and prepare a proper video, so I would rather show it once it is ready.

But I have not only been thinking about the product side of the project. I also decided to do something outside my comfort zone to let more people know this project exists.

Look, I am all in when we talk about organic content marketing and SEO. But these strategies take time, and even if they are the most cost-effective to implement, they cannot be the only thing I rely on if I want to reach real users.

So I decided to start some outreach. Right now I am trying a mix of old and modern strategies: manually sending connection requests and following up with a cold DM once accepted, plus using my dashboard to surface relevant conversations happening around the web.

Let's see if next week, besides the new feature, I will also have some numbers to share 😊

This week was slower than I wanted because I was on a work trip, so I did not have much time for social or for pushing promotion hard.

Still, I closed one important piece of product work: a full onboarding rewrite.

The old onboarding worked, but it still felt too generic and too form-heavy.

So this week I focused on making the experience feel more guided and more intentional:

• clearer progression across the flow

• nicer entrance animations

• a quote/interstitial moment to keep people engaged

• a stronger first-memory step so the value clicks earlier

• removal of the heavier card style so the whole thing feels lighter

This is one of those updates that is easier to understand visually than through text alone, so I also prepared before/after images to show the rewrite properly.

I also published a new article: Why memory fade kills promotions.

That still matters because it sits underneath a lot of the promotion pain I keep writing about. People remember that they worked hard, but the evidence disappears: the metrics, the decisions, the tradeoffs, the invisible work, the context.

And once that fades, the review conversation gets rebuilt from partial memory.

That is a terrible way to defend a promotion case.

What I worked on:

• finished the onboarding rewrite and prepared before/after images to show it

• published the Memory Fade article

• rewrote the homepage copy so the product is explained more clearly

• kept the distribution queue moving even in a slower week

What feels important about this week:

• the onboarding now feels more like a guided product experience, not just a form flow

• the homepage messaging is in a better place before I push harder on promotion

• Search Console is indexing more pages, which is encouraging even if traffic is still very low

What still feels weak:

• I did not have enough time to be as active on social as I wanted

• the week was thinner on visible output because of travel

• the distribution system still needs more consistency from me, not just better drafts

What is next:

• publish the onboarding before/after images across channels

• push harder on promotion now that onboarding and homepage messaging are stronger

• finish the Memory Fade distribution chain and keep building the launch narrative week by week

If you are building in public, do you also get these weeks where the most meaningful progress is product experience work that does not look like growth yet?

I've been quietly building my project for a while. Even though I don't feel ready, I decided to start the marketing activities around it too.

My first marketing experiences were back in the "Inbound Marketing" days. So even if short-form video dominates now, starting with long-form content makes sense for me.

Besides social posts like this one; where I talk about my building experience, choices, and discoveries along the way; I've decided to write articles too.

For someone like me who always feels like what they share is never enough, having full articles to pull ideas from is priceless.

Too early for numbers. I don't even track them properly, I rely on Cloudflare Web Analytics (not the request, by the way) because the focus isn't optimizing processes yet.

I still have to create them.

That said, I find it genuinely useful to just write and talk openly about the experience. If you're also building in public, I'd love to hear how you approach it.

I have a couple of months before I start pushing hard on promotion. So I'm playing the slow and steady card: building domain authority before the product is ready to sell.

Why SEO and not X or YouTube?

I'm a father of two working full-time. My spare hours are limited, and I need them to compound. Social platforms reward relentless engagement: posting daily, replying to threads, being in everyone's replies. That works if you can sustain it, but for me it would produce zero lasting value for this project.

A well-ranked article, on the other hand, keeps working while I'm changing diapers.

I've done this before. I ran a profitable elearning platform built entirely on inbound marketing. Plant seeds strategically, and sooner or later you have a body of ranked pages pulling traffic (and AI mentions) that pays off big time.

So I started writing.

My first article covers the XYZ framework, a structured way to present accomplishments so they're actually understandable outside your team. It's a topic with plenty of existing posts, but I knew I could add my own angle and optimize for both SEO and AEO.

But here's what surprised me: writing one detailed article unlocked an entire week of content.

A single long-form piece gave me talking points I can excerpt and share across platforms: a tweet here, a LinkedIn snippet there, a Reddit comment that actually adds value instead of fishing for clicks.

That feels much better than staring at an empty text box trying to come up with something to say.

The funny part? I'm doing all of this with the help of some SKILL.md files, prompt templates designed for people like me who know marketing but don't have the time to process everything by hand.

Wanna know more about that? I'll cover it in a future update.