CTO and builder of healthcare platforms. Writing about systems, product decisions, leadership, and the human cost of building software.https://ryannorris.com/en-usFri, 03 Apr 2026 18:16:14 GMThttps://ryannorris.com/product-strategy/build-vs-buy/https://ryannorris.com/product-strategy/build-vs-buy/The hidden costs that make build-vs-buy harder than it looks.Mon, 10 Feb 2025 00:00:00 GMT Every build-vs-buy decision looks obvious in retrospect. But when you're making it, the costs are hidden. **Building is always more expensive than you think.** You're not just building the feature. You're building the maintenance, the support, the compliance, the scale. That "2-week feature" becomes a 2-year commitment. **Buying means accepting their roadmap.** That vendor's priorities aren't your priorities. You'll wait 6 months for a feature that would take you 2 weeks to build. But you won't be maintaining it. **The real question: is this a competitive advantage?** If yes, build. If no, buy. Everything else is rationalization. [Placeholder for framework, examples, and specific decision criteria] product-strategyryan@ryannorris.com (Ryan Norris)https://ryannorris.com/healthcare/healthcare-ai-compliance/https://ryannorris.com/healthcare/healthcare-ai-compliance/Shipping AI features while maintaining HIPAA compliance and audit trails.Wed, 05 Feb 2025 00:00:00 GMT AI in healthcare isn't just a technical challenge - it's a compliance nightmare. **Every AI decision needs to be explainable.** HIPAA doesn't care that your model is accurate. If you can't explain why it made a specific recommendation about a specific patient, you're liable. **PHI can't leak into training data.** Your LLM vendor's Terms of Service probably allow them to use your inputs for training. That's a HIPAA violation waiting to happen. You need private deployments or contractual guarantees. **Audit trails are non-negotiable.** Every AI-assisted decision needs full logging: what data went in, what came out, what version of the model, when, and who reviewed it. This overhead is significant. The companies winning here treat compliance as a first-class requirement, not an afterthought. [Placeholder for specific technical approaches, architecture patterns, and lessons learned] healthcareairyan@ryannorris.com (Ryan Norris)https://ryannorris.com/ai/ai-in-production/https://ryannorris.com/ai/ai-in-production/The gap between demos and production AI systems is wider than most teams expect.Sat, 01 Feb 2025 00:00:00 GMT Everyone has a working demo. Few companies have AI in production that actually solves real problems. The gap between these two isn't technical sophistication - it's understanding production requirements: **Latency budgets are real.** Your LLM-powered feature can't take 30 seconds to respond. Users won't wait. You need streaming, caching, and fallbacks. The demo didn't need any of this. **Cost per inference matters.** That $0.02 per API call adds up fast when you're processing millions of requests. Suddenly you're spending $40K/month on what was supposed to be a feature enhancement. **Hallucinations aren't acceptable in production.** Your demo could get creative. Your production system needs guardrails, validation, and human-in-the-loop workflows for anything that matters. **Compliance isn't optional.** If you're in healthcare or finance, every AI output needs to be explainable and auditable. That changes your architecture significantly. [Placeholder for specific examples of production AI challenges, solutions, and trade-offs] airyan@ryannorris.com (Ryan Norris)https://ryannorris.com/leadership/technical-debt-reality/https://ryannorris.com/leadership/technical-debt-reality/The debt metaphor breaks down when you can't declare bankruptcy.Sat, 25 Jan 2025 00:00:00 GMT Technical debt is a useful metaphor, but it breaks down in practice. **You can't declare bankruptcy.** With financial debt, you can walk away. With technical debt, you're stuck with it. That legacy system from 2015? It's still running your core business. You can't just shut it down. **Interest rates vary wildly.** Some technical debt compounds daily (security vulnerabilities, deprecated dependencies). Some sits dormant for years (that weird edge case in the billing system). **The real cost is opportunity cost.** Every hour spent working around technical debt is an hour not spent building new features. Your competitors aren't carrying your debt. The best teams I've worked with treat technical debt like operational load: measure it, track it, and allocate dedicated time to pay it down. [Placeholder for specific strategies, metrics, and team practices] leadershipryan@ryannorris.com (Ryan Norris)https://ryannorris.com/leadership/staff-engineer-hiring/https://ryannorris.com/leadership/staff-engineer-hiring/What to look for when hiring senior technical leaders.Mon, 20 Jan 2025 00:00:00 GMT Staff engineers are force multipliers. But hiring them is different from hiring senior engineers. **They need to have built the thing you're about to build.** Not something similar. The actual thing. If you're scaling to 10M users, find someone who's already done it. The lessons can't be learned from books. **Look for written communication.** Staff engineers spend more time writing design docs than code. If they can't explain complex technical decisions in writing, they can't scale their impact. **Check for battle scars.** Ask about their biggest production incident. The best staff engineers have war stories and learned from them. [Placeholder for interview approach, red flags, and specific examples] leadershipryan@ryannorris.com (Ryan Norris)https://ryannorris.com/healthcare/scaling-healthcare-platforms/https://ryannorris.com/healthcare/scaling-healthcare-platforms/What breaks when you scale from 10K to 10M patient records.Wed, 15 Jan 2025 00:00:00 GMT When we crossed 100,000 patient records, everything seemed fine. At 500,000, we started seeing query slowdowns. At 2 million, the whole system started creaking under its own weight. Here's what we learned about scaling healthcare platforms: **Data locality matters more than you think.** Patient data isn't uniformly distributed. Some facilities generate 100x more data than others. Your partitioning strategy needs to account for this, or you'll have hot spots that kill performance. **HIPAA compliance adds overhead you can't optimize away.** Every query needs audit logging. Every access needs verification. That 2ms overhead per operation compounds when you're doing millions of operations. **The hardest part isn't the database.** It's the interoperability layer. HL7, FHIR, proprietary formats - they all need to be normalized, validated, and kept in sync. This is where most systems break. [Placeholder for additional detail on specific scaling challenges, architectural decisions, and lessons learned from production incidents] healthcareryan@ryannorris.com (Ryan Norris)