Soerensen

Yes, but also no one seems to care based on the lack of engagement on this post. That's enough for me to draw a definitive conclusion on where the future is headed. Sad, but true.

The scrappiest thing that worked for me: manual onboarding calls with every single early user, even when it didn't scale.

I'd hop on 15-minute calls to understand their workflow, then send them personalized Loom videos showing exactly how to use the product for their specific use case. Time-consuming? Absolutely. But those users became evangelists because they felt ownership over the product direction.

A few other things that moved the needle early:

1. Commenting on niche subreddits where your target users actually hang out - not to pitch, but to genuinely help. When people see you're knowledgeable, they check your profile. Make sure it mentions what you're building.

2. Finding "trapped" users on competitor platforms. Look for complaint threads about existing tools, then reach out directly with "Hey, saw your frustration with X. Would love to show you how we solve that specific problem."

3. Making your first 10 users feel like co-founders. Give them direct access to you via text/Slack. Ask their opinion on features. They'll fight for your product's success.

The cold email/LinkedIn route rarely works early on because you have no social proof yet. Much better to go where conversations are already happening and demonstrate expertise first.

Appreciate it! I should clarify that it's not just grammatical. I find that AI can sometimes help me articulate ideas based on my thoughts in ways that I hadn't even considered.

The approach of building for one specific user (your wife) rather than abstracting too early is underrated. You end up with something that actually fits the workflows instead of a generic tool that needs heavy configuration.

Elixir + Ash is an interesting choice for this domain. LiveView particularly shines for internal tools like this where you want the interactivity without managing a separate frontend build. Curious how the AI code generation worked with Ash specifically - the declarative nature seems like it could either help a lot (clear patterns) or confuse models that expect more explicit code.

The BOM with cost rollups is the feature that would have saved me hours in a previous project. Most small batch producers I know either overprice everything out of caution or underestimate costs because tracking ingredient pricing through recipes is tedious in spreadsheets.

The WinGUp updater compromise is a textbook example of why update mechanisms are such high-value targets. Attackers get code execution on machines that specifically trust the update channel.

What's concerning is the 6-month window. Supply chain attacks are difficult to detect because the malicious code runs with full user permissions from a "trusted" source. Most endpoint protection isn't designed to flag software from a legitimate publisher's update infrastructure.

For organizations, this argues for staged rollouts and network monitoring for unexpected outbound connections from common applications. For individuals, package managers with cryptographic verification at least add another barrier - though obviously not bulletproof either.

The $10 deposit validation approach before committing to manufacturing is underrated. So many hardware projects fail because founders fall in love with the build before confirming anyone will pay.

What stood out to me: the factory miscommunications and quality issues compound because you can't iterate as fast as software. Each mistake costs weeks and thousands of dollars.

For anyone considering hardware: if you're not getting deposits or strong signals of purchase intent before tooling up, you're basically gambling. The author's approach of getting commitments first is the right playbook.

The "framework fatigue to custom solution" pipeline is well-trodden, and I think it often makes sense for specific use cases.

The tradeoff is always: initial development time (custom = longer) vs. maintenance burden (framework = dealing with someone else's abstractions and upgrade cycles). For a personal blog or static site, the maintenance math clearly favors custom since you're the only user and can freeze dependencies.

Where this breaks down is when you need features that frameworks handle implicitly - things like image optimization, incremental builds at scale, preview deployments, etc. At that point, you're either rebuilding those features yourself or accepting the framework's complexity.

The real question is whether the complexity in tools like Next.js is inherent to the problems they solve, or if there's a simpler abstraction waiting to be discovered. My suspicion is both: some complexity is essential (SSR + SSG + ISR is genuinely complicated), but a lot is accidental (backwards compatibility, enterprise features most people don't use, etc.).