Fun gets users in.
Fairness keeps them.
Built ClusterClear Duel: a 1v1 turn-based puzzle game.
Most of the work wasn't the UI. It was making sure every turn resolved the same way for both players — every time, even on reconnect.
#BuildInPublic
The goal isn't "users know we're secure."
It's "users never had a reason to doubt it."
That's ambient trust. And it's a product design problem as much as an engineering one.
What security pattern have you seen improve UX?
#BuildInPublic
Users shouldn't have to think "this feels secure."
They should just feel safe using it.
Security that announces itself is usually security that wasn't fully thought through.
The best auth flows, permission models, and access rules are completely invisible when they're working.
"Service is up" ≠ "users are having a good time."
That's the gap between monitoring and observability.
Infrastructure-facing vs. product-facing.
What do you track that actually predicts user pain?#BuildInPublic
Dashboards are only useful if they tell you what users are about to feel.
The three signals that actually predict user pain:
→ p95 latency (the tail users are real)
→ queue depth (backlog becomes delay)
→ retry rate/min (dependency degrading before it fails)
Queues decouple the failure surface.
One slow consumer stops hurting the producer.
One spike gets absorbed, not passed upstream.
One failed dependency recovers without a cascade.
Design for failure before failure designs your roadmap.
What changed your architecture thinking the most
#BuildInPublic
Every sync dependency looks fine until traffic hits.
Then one slow service makes every upstream service slow.
One failing service makes every service in the chain fail.
That's not bad luck. That's architecture.
Retrying blindly isn't resilience. It's optimism.
If 5 services all retry a struggling dependency at the same time, same interval — you've built a distributed denial of service out of your own error handling.
Backoff. Jitter. Isolation.
Resilience doesn't fail loudly when it works.
It fails loudly when it wasn't built.
What resilience pattern has saved you the most in production?
#BuildInPublic
Reliable products are full of invisible decisions users never notice.
That's the point.
A retry policy that saves a session.
A circuit breaker that prevents cascade.
A queue that absorbs a spike without data loss.
No demo. No applause. Just trust.
Those costs don't show up as line items.
They show up as meetings that didn't need to happen and sprints that got derailed by questions you already answered six months ago.
Shared language ships faster.
What decision has your team re-made the most?
#BuildInPublic
Speed isn't typing faster.
It's arguing less about solved problems.
The cost of no design system isn't ugly UI.
It's the sprint review arguing border radius.
It's the two-hour meeting about red vs. outlined-red.
It's onboarding that takes weeks instead of days.
When a component handles focus, keyboard nav, and close semantics correctly — every time — users stop thinking about the interface.
They start thinking about their task.
That's the actual goal.
Do users notice consistency, or only its absence?
#BuildInPublic
Consistency isn't decoration.
It's a trust signal.
Users never see your design tokens.
They feel it when three screens use three slightly different shades of blue for the same interactive intent.
That gap is a system gap — not a design gap.
The real cost of no system isn't ugly UI.
It's institutional knowledge that lives in people — and leaves when they do.
What breaks first on a product with no real system?
#BuildInPublic
Design systems = shared memory for teams.
Consistent language for users.
Not a component library.
A record of decisions your product doesn't have to re-make.
Without one, every new screen is a negotiation.
With one, it's a conversation that already happened.
Built the CMS for https://t.co/p7Zawo4Ixj around one question:
What does updating this look like on a Tuesday evening, six months from now?
Schema that fits how I think.
One-session publishing.
Preview before commit.
Smooth updates keep products alive. #BuildInPublic
DX isn't just for dev teams.
Even personal publishing needs good workflows.
If updating your portfolio means:
open codebase → edit template → run build → debug deploy
…it won't happen consistently.
And inconsistency is how personal brands quietly die.
The hard design constraint:
one surface, three reading modes, zero confusion.
Clarity isn't a nice-to-have.
It's the primary deliverable.
Who do you design your portfolio for first? #BuildInPublic
A good portfolio answers three questions:
1. What do you build?
2. How do you think?
3. Why should I trust you?
Different audiences read for different ones.
Recruiters scan for #1.
Clients linger on #3.
Collaborators read everything looking for #2.