Supabase has had 22 outages across 24 components in the last 30 days. Two of them landed yesterday and the day before. If your MVP runs on it, you felt that. Yesterday it twas a pgBouncer config issue hitting the Dedicated Pooler and Storage on Project versions 15.1 and older. Today the fix was still rolling out at 1am UTC. Older projects took the hit hardest. The takeaway isn't "don't use Supabase." I ship on it. The takeaway is that a managed backend is a rented apartment, and you still need someone who knows where the fuse box is. Most pre-seed teams I talk to have one full-stack founder and a Supabase project on a version they haven't touched since seed. When Storage stops responding at 9pm before a customer demo, nobody on the team can read the pooler logs. That's the gap a short engineering spike closes. Not to rip out your stack. To upgrade the Postgres version, move auth off the default settings, and leave a runbook so the next outage costs you an hour, not a customer. We're giving away a free runbook for this situation; DM me so that we can make it tailored to your team.

A developer contributed to an open-source project for 2 solid years. Solid work, consistently merged. Then, 2 years in, he committed something with a backdoor hidden inside it. The way it was discovered was crazy. Someone at an enterprise company noticed a specific process running a few milliseconds longer than expected.  That was it. A fraction of a second on a performance measurement, and someone was paying close enough attention to realize. That level of patience is the thing that should concern every team maintaining a production codebase. The attack surface has shifted. Increasingly, it lives in time: - Who has been in your codebase - How long they've been there - What they left behind Stay safe out there.

The Drift team was robbed of $285 million. What’s even crazier is that the people who robbed them showed up to their in-person events and shook their hands. North Korean attackers spent years building genuine relationships with the team before executing.  Real conversations, real appearances, real trust built over time.  Then they got the team to sign pre-signed malicious transactions and handed over admin control. The attack was entirely operational. Relationships, physical presence, manufactured trust over many months.  The technical component was almost secondary. Security is shifting. The vulnerabilities that will cost your organization the most live in how your team builds trust and who gets handed the keys. It’s not just about solid encryption anymore.

We built Slopless to catch vulnerabilities in AI-generated codebases. Then Claude shipped a security plugin that does most of what Slopless does. As you can imagine, that stung a bit. Months of engineering hours, iterations, and pivots, now competing with a feature from the same company whose model powers the tool. What I've been sitting with since: building fully automated security vulnerability scanners might just be a fool's errand.  When Claude can handle the scanning for free, the question becomes where your edge actually is.  For us, that means combining traditional static analysis with AI: using the clues that deterministic tooling surfaces and letting the model filter the noise. That's an approach we've had success with before. Three or four months ago, memory persistence in agents was still an open question. But not anymore.  The pace of change in this space means yesterday's hard product is today's built-in feature. You either catch up to where the ecosystem is heading and find your alpha along the way, or you fall behind.

Most AI startups are building tools around the way we work. I’d suggest a different approach. The companies that matter will be the ones building on top of what businesses actually do.  Software alone has never been enough. The real leverage comes from the combination of what a business operates on, how it operates, and where software can meaningfully speed that up. Horizontal tools get commoditized fast.  A workflow optimizer or a smarter to-do list can be replicated in a model update.  But a product that understands a specific domain deeply and makes the business faster is harder to replace. With very few exceptions, most horizontal AI startups are cooked. It’s just a matter of how long until they realize it.

Every integration you add multiplies your blast radius. That's the security calculus most people skip when they're connecting tools.  When one environment gets compromised, the attacker gets everything it touches.  Add enough integrations, and you've built a fast lane from any single breach to every critical system you run. My approach is to keep environments as separate and minimally integrated as possible.  I use Notion for most things and Notion AI for Notion-related work. Any breach there stays with Notion.  A billion-dollar company getting compromised is a manageable problem. That same breach cascading through everything else I run is a different category of problem entirely.

These are 3 questions I ask before adding any new tool to my stack: - What permissions is it actually requesting, and do those make sense for what it does? - Does it touch any existing systems I rely on, and what happens to my data if that connection gets compromised? - Can I get the same result from a platform I'm already using, or do I actually need a new trust relationship here? Most tools get added the same way: something looks useful, you click through the permissions screen without reading it, and it's in your stack.  That process is fine until it isn't, and "until it isn't" usually means a breach you didn't see coming. The diligence takes 10 minutes. The cleanup takes months. Stay safe out there.

A Vercel employee installed a third-party tool called Context AI for what was probably a routine engineering task. That one decision led to a highly sophisticated attacker compromising Vercel's Google Workspace, accessing environment variables across their infrastructure, and triggering one of the more alarming security postmortems I've read this year. The attacker used the access that employee had already granted the tool.  That’s all it took. This is the part of the AI tooling conversation that almost nobody is having. We're in fast fashion land right now with apps.  The volume of new tools being released is enormous, and the cultural expectation is to move fast, try things, and iterate.  What that culture doesn't make room for is actually reading what you're granting access to when an app requests permissions to your Google Drive, your GitHub, or your email. Most users only have one question when they pick up a new tool: can it do what I need?  Important question. But the question that matters more is what does this thing touch in my existing systems, and what happens if someone else gets to it before I do. That's the question the Vercel employee skipped.  It's also one that the majority of founders skip every week.

Hiring a head of growth is one of the highest leverage moves I've made at XORS. I used to think distribution was something you figured out yourself. Grind the outreach, work the network, show up to things you already knew about. What I didn't account for is how much you don't know what you don't know. Our head of growth has made introductions I never would’ve made, gotten us into rooms I never would’ve found, and brought us to events that weren't even on my radar. Amazing doesn’t even begin to describe it. If you're around for ETH NYC or a16z tech week in New York, hit me up on X. Would love to connect with founders and builders in the space.

Would love to have folks here! Our first studio IRL event.

I recently saw this post from a founder that they were going to build an app every single day for a year. 365 apps. 365 days. Imagine saying something like that even just 12 months ago? Insane. But my first reaction wasn't "impressive." It was: how are you going to maintain 365 apps? We're in a weird era. Models are faster, vibe coding has lowered the bar to ship, and the culture is just: get it out, iterate in public, move fast.  Because shipping is the easy part now, but maintaining is still hard. It still requires forethought, testing, documentation, and someone who actually cares when something breaks. The result is a growing graveyard of apps that technically launched but can't survive contact with a real user. Speed isn't the liability. Shipping without the intent to maintain is. PMF isn't found by shipping 365 things. It's found by shipping something worth maintaining. I’m not suggesting the shotgun approach doesn’t work. But the spread on your shotgun needs to be just a bit tighter. My opinion.

The engineers I respect most have surprisingly vanilla workflows. No elaborate AI orchestration or month-long sprint to find the perfect stack. Too much setup replaces raw skill with delegation. And delegating to a tool you haven't benchmarked is just organized guessing. My approach: try one thing, see if it beats the baseline, and take the next best step.  It’s simple, iterative, and honest about what's working. The most sophisticated workflow isn't the best workflow. The one that actually makes you sharper is.

I don't have a driver's license. Most people find that surprising. Maybe even a downright bad life decision. But the way I think about it, you completely eliminate a class of problems by not opting into them in the first place.  No car means no insurance, no maintenance, no parking tickets. Generally speaking, the more stuff you “own” the more it ends up owning you. That’s the way I see it, anyhow.

This might be the most underrated aspect of Claude. One of our clients started using it to iterate on product specs before handing them to us. They'd describe how their business operated, what data they needed, what the system should do, and let Claude help them structure it into something an engineering team could actually build from. By the time it landed with us, the spec was tighter than anything we'd seen from a non-technical team. How awesome is that? Domain knowledge is the variable Claude can't invent. When someone who deeply understands their operations and shares it with Claude, that’s incredibly helpful to us. At the end of the day, everything relies on the quality of our prompts. As obvious as that seems, it’s easy to forget.

4 dead giveaways of AI-generated code: - Dead/stale comments referencing old commits or bugs that no longer exist - API calls hard-coded to fetch exactly 100 results with no pagination logic - "God files" running 2,000+ lines instead of separated components - Tests nowhere to be found: 3,000 lines of changes, barely any coverage Most engineers don't catch these at review because they look plausible at a glance, hard-coded round numbers feel like reasonable defaults, and missing tests feel like a time constraint someone meant to fix. But each one compounds. Stale comments get re-ingested by the next AI session and treated as ground truth.  God files also become unmaintainable fast. That’s why the cleanup process of AI code is so important.

A lot of non-technical founders think Claude Code is what you get when you point the Claude API at a task. I’d disagree. Claude Code is a heavily engineered product, built on top of things the raw SDK doesn't give you: - Context compaction - Session maintenance - Hidden system prompts - A defined file path for session context that lives entirely outside the chat history None of that ships out of the box. Every piece of it was built deliberately by Anthropic's engineering team. The reason this matters is that I keep running into non-technical founders who look at what Claude Code can do and then ask why the AI feature in their own app doesn't perform at the same level.  What they’re experiencing lives in the engineering layer around the model, not inside the model itself. This is one of the most underappreciated advantages of working with an actual engineering team.  We can sit across from a founder, explain exactly why the behavior they're seeing is happening, and walk them toward a realistic path forward. A raw API integration can't do that.

This might seem harsh, but I’d argue otherwise. A founder came to me last month asking if they should bring on an offshore team to hit a 14-day ship deadline before their next funding round. My answer was no. The framing was: these developers are cheap, they're fast, and it's just to get something functional for the raise.  But quality is king, and you get what you pay for. Speed without execution quality is a liability you're deferring. You pay for it right when it matters most: in a demo, in due diligence, the first week a real user touches it. The value of a dev shop is execution you can trust under pressure.  If the execution isn't there, you don't actually have a timeline. You have a countdown.

Everyone evaluates the idea.  Very few evaluate the people behind it. I get it. Ideas are easy to compare, and traction is easy to measure. You can put a number on MRR, but you can't easily put a number on judgment, or grit, or how someone operates when things go sideways. But here's what I've learned running XORS: a dev shop is a people company first. So is a product shop. The idea is just the vehicle, while the team is the engine. The best clients we've worked with wanted to understand how we think, communicate, and whether we'd tell them the truth when it wasn't what they wanted to hear. That's the stuff that actually determines outcomes. Bet on the people. The idea will evolve anyway.

Awesome product release!!

Saw this and had to react… This is one of the most insane agent decisions I've seen posted publicly. Give an agent full access to a clone of production? Still kind of suspicious since production data might contain sensitive user information… but sometimes that's how you find out what it's actually capable of. Give an agent full access to actual production? That's a single bad tool call away from a company-ending incident. The lesson from "it made the agent 10x more useful" is that your sandbox wasn't realistic enough. Fix the sandbox. Don't remove the guardrails. xitter.cf/snowmaker/status/20596…