Week 9: I kept choosing between distribution and making the product sharper
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?
