Milo Delgado

Occasionally the growth problem is the offer itself. Usually clients come to us because they're already growing and need help. One existing client, a startup, wasn't growing much yet. They run a marketplace for local produce farmers in San Diego. You can buy berries straight from one farmer, which is cool. The trouble is a shopper wants more than berries. They want bread and everything else too, and the marketplace made that confusing. My suggestion was to try a box. Prepackaged, with organized pickups. The town I live in now does exactly that, and picking up a box is a much simpler experience. That's closer to business advice than marketing advice. The best growth recommendation can be a change to how you package what you sell.

A guy on X bragged that he'd burned through 18 billion tokens. More than the team building OpenCode. The OpenCode team's response was basically: with all those tokens, why haven't we heard of you? It made me laugh because token spend gets treated like a scoreboard. Spend tells you how much you used the tool. What you built with it is a separate question. One talk I saw put it well. Give the best programmer in the world Claude and give the worst programmer in the world Claude. You already know who gets the better result. Eighteen billion tokens and nobody's heard of you is an expensive way to learn that.

Linus may have been the first "vibe coder". His "agents" were just open source contributors he benevolently dictated (and his feedback was considerably less polite). I take the same approach. Hire smart people. Give them clear goals. Trust them to choose their tools and share them openly Hold them accountable for what they ship.

I was a drummer before I was a developer. High school band, then guitar with friends who had nicer gear than me. People are surprised that a creative kid ended up writing code for a living. I'm not. Early web work was closer to making music than people think. Flash sites (remember those?) had rhythm, timing, a narrative you walked someone through. Rather than just building logic, you were building something a person would feel. The best engineers I know all have something they make that has nothing to do with a screen.

Every time a new developer inherits your product, the clock resets. A developer who's been inside your product for two years carries knowledge that isn't documented anywhere. They remember decisions that shaped the architecture and edge cases that cost months to surface. When they leave a new person starts from zero. Hiring directly isn't any better. You have to take on recruiting and onboarding. Managing someone day-to-day takes more. And when they eventually leave (which they do) you absorb the full cost of starting over. At Fetchly Labs the team keeps going. Same people and PM. The knowledge of what you're building stays in place. If someone on our side moves off the engagement, the replacement steps into a team that already knows the product. Onboarding is faster. And the clock doesn't reset. If a developer transition cost you more than you expected, DM me. Happy to share what we've learned from it.

A junior developer shipped me clean-looking code last a few months back that he couldn't explain. An AI wrote it. He pasted it. It worked, until it didn't. The day it broke, he couldn't do a thing for one simple reason: You can't debug what you never understood. AI coding tools are incredible. We use them every day. They also create a new kind of risk nobody warns you about. Speed without comprehension. If your team ships code they can't reason about, it's borrowed speed. The bill comes due at the first real bug. Hire people who understand the work, then hand them the tools.

The hiring tech stack is a graveyard of point tools. One app posts your jobs. Another screens resumes. Another runs the interview. Another designs the code challenge, another reviews and scores the code. Each one is good at its own thing. The problem is that you end up having to send links manually. Then, scheduling is done in a separate tool. You copy scores into a spreadsheet, only to duct-tape it all together with Zapier or worse, a vibe coded solution. The integration work costs more time than the hiring itself. I stopped thinking about features and decided to focus more on the seams. A candidate should move from applied to hired through one funnel. If you're evaluating hiring software, count the handoffs between tools before you count the features.

Everyone optimizes remote hiring for skill. I did too. India, Ukraine, Latin America. Great engineers from all over. But it's the time zones that kill you. When you're 10 hours apart you get two options. And both are bad. Option 1: The midnight sync nobody wants to take. Option 2: All in on async. You send a question, video it, think you cover every edge case. Wait a full day for the answer. They hit a snag, send a reply. Wait another day. Everything moves at the speed of a telegram. Talent in your time zone changes the whole game. You're cracking jokes in Slack by day three and your building actual culture. If you're hiring remote, solve for overlap before you solve for skill.

The only software lessons that stick are the ones that cost you money. My first SaaS, NIGHTOUT, sold concert tickets. Big artist goes on sale at 10am. Thousands of people waiting. Limited inventory. Everyone knows the exact second it drops. Your servers either hold or they don't. When they didn't, that was people's money on the line and a furious client. Ecom under that kind of pressure makes you a better builder because there's nowhere to hide. You learn to plan for the worst-case scenario rather than the happy path. Was there a project that made you better the hard way?e

I hired on my gut for years even though it was only right half of the time. I'd get a read on someone in the first two minutes and decide from there. Growing a team from 15 to 160 people ended that habit fast. When hundreds of people apply to one role, you start skimming. You miss strong candidates because you're tired. The weakest part of hiring is the human doing the judging. We get biased and rushed. We give the person who reminds us of ourselves a longer look. I trust a structured process over my first impression now. My hires got better the day I admitted that. The team is spread across Latin America. This is some of us out in Rio. A few of the best people here are ones I might have scrolled past. So glad I didn't.

Founders are always caught off guard by our contract term. Thirty days. Not because long agreements are wrong. Sometimes they make sense. But I have never believed a partnership should require a leap of faith. You should be able to work together, see how the team communicates, how they execute, and whether they are the right fit. If it works, great. If it doesn't, both sides should be able to move on. That changes the conversation. Instead of asking, "What if this doesn't work?" Founders start asking, "Why wouldn't we give it a try?" The best partnerships are earned month after month, not locked in on day one. If you're comparing development partners, I'd be happy to walk you through how we structure ours.

I think the tech industry is holding onto two outdated words. Nearshore & offshore. Those terms made sense when moving factories and supply chains. They make a lot less sense when the product is software. If everyone works remotely, geography matters a lot less than people think. What actually matters? Time zone overlap. Clear communication. Strong English. A team that feels like an extension of your own. For many US companies, Latin America checks every one of those boxes. In some cases, the time zone overlap is better than hiring elsewhere in the US. Founders should stop asking whether a team is nearshore or offshore. They should ask whether the team can build alongside them. If you're evaluating engineering partners, I'd be happy to share what we've learned building distributed teams over the last decade.

I had one of the most interesting requests from a client: "The perfect fit would be a Python developer who's also has his a Pilot License." They were building software for planes and thought posting the job and running it through an ATS would surface someone. I told him the truth. That person might not exist, and if they do, software won't find them. Someone has to hunt that human down and convince them to leave the cockpit. Hiring tools are strong when the talent already exists and you need to sort signal from noise. But they're useless when you're chasing a ghost. Knowing which problem you actually have saves you months. A lot of failed searches are just the wrong tool pointed at the wrong problem.

Not too many people can say they met their co-founder in high school and built a company together 15 years later. I grew up in Santa Barbara. My dad took a job out there, so I spent middle and high school in the cold, which is its own character-building exercise for a California kid. That's where I met Huey. We went separate ways for years. He stayed in the technical world. I wandered through art and freelancing. Got together with a group of founders and built a ticketing startup. We reconnected when he interviewed at my company looking for a Rails job. Years later we'd be co-founders. The relationships that matter rarely announce themselves when you make them. Keep the good people close. You never know who you'll be building with in a decade.

The best product I've built started as a tool we made for ourselves. We had to hire 30 people at our agency and no tool on the market could keep up with that volume. So we built our own system to handle screening, interviewing, and scheduling. We used it on our own hires for over a year before it was even a product. Building for yourself first is an unfair advantage. You feel every part that's broken because you live with it. By the time you sell it, it's already survived its harshest user. The tools that solve a real pain usually start as someone scratching their own itch.

When you start on Shopify go as vanilla as possible. Shopify handles what you need at that stage. Off-the-shelf tools cover the edge cases. The goal is growth and profitability. Custom software slows that down early on. You've outgrown vanilla when you have a customer problem that standard tools can't solve. We saw this happen with the bundler for Oats Overnight. Customers wanted to swap individual products inside a subscription box. Shopify with Recharge didn't handle that natively. The customer service problem BECAME a software problem. And we built for it. That's when custom investment starts to make sense. As Oats grew, the operations started pushing past what Shopify handles natively. Deep inventory insights across multiple warehouses. A purpose build OMS for their unique fulfillment and shipping needs. Each layer built on the last. The risk we see on the Shopify side is plugin accumulation. Teams add plugins to solve individual problems. Over time nobody knows what each one does or won't remove it in case something breaks. By then, the decision about when to invest in your own platform is overdue. Build tech you can build on top of.

LinkedIn is wild. Should we be agreeing with our own posts now?

AI made it easy to build. Getting people to care about what you built is still just as hard as it was before. There are more builders now than ever. A year ago, having a working product was enough to stand out. Now everyone has one and the hard part moved downstream. I see this a lot at Fetchly Labs. People will have something they built using AI. It works. They're proud of it. Then the question becomes: who is this for and how do I get it in front of them? That's product-market fit. You still need to figure out a funnel and test the messaging. All while learning what makes someone actually buy. AI didn't make any of that easier. If anything, there's more noise to cut through because everyone else shipped something too. We're built a growth team at Fetchly for exactly this reason. Many of our e-commerce clients need help making ad spend work and moving conversion rates. The barrier to building software may have dropped. But the skills that move the product will always be valuable.

At Rails World last week, I sat in the room as DHH announced that 37signals had gone "pencils down" on writing code by hand. His argument was blunt: "Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers." The mood at the conference was mixed. For a room full of people who have spent their careers writing code, it was a lot to take in. I wasn't sure how I felt about it either. Especially when the very next talk dove into the internals of Active Search. Code? What is this?!! I thought we were pencils down now?? Pencils back up, people!! I've had a few days to think on it. And he's probably right. The next valuable skill may be crafting agents that write code for us. But even that window closes eventually. The agents keep improving. The interfaces change. More of the process disappears behind another abstraction. Separating perishable skills from durable ones was what settled it for me. Syntax is perishable. Framework knowledge ages the same way. Even the agent workflows that feel current right now won't outlast the next wave. Judgment is harder to route around. You still need to know what good looks like, and you need to catch when the machine is confidently wrong. The job shifts to knowing what should be built, and whether it actually works. Was that what programming was always about? Time will tell. Watch the full keynote here: youtube.com/watch?v=vDjW_dRy…

Michael JL Huey and I reconnected because he was looking for a Rails job. We'd known each other since high school in Minnesota but had kind of lost touch. He actually interviewed at NIGHTOUT toward the end before we sold it. Then the pandemic happened. Life changed. I visited him in Austin. Immediately thought "This place is pretty sweet." and I moved there. He had this agency and a new business model he was playing with. I started consulting part-time. Helped sell and set up architect deals. Enjoyed it. He brought me on as a partner. We grew it 50% year over year for three years. That Rails job turned into a partnership that grew a 15-person agency into a 160+ team.