• SaaS valuations dropped. The narrative is simple: AI lets anyone build anything, so why pay for software? They’re calling it the SaaSpocalypse.

    I think part of it makes sense. But a big part of it doesn’t.

    You don’t buy code, you buy decisions

    When you buy a piece of software you’re not just buying the code. You’re buying the decisions that shaped that code. What to build, what not to build, how to model the domain, which tradeoffs to make. Those decisions were valuable before AI and they are still valuable today.

    This is why I think we’re entering the era of product managers. They are the ones making those decisions. And those decisions require deep domain knowledge. Gaining that domain knowledge is not trivial.

    The Fusion test

    Let me make this concrete. I do 3D design for 3D printing. It’s a hobby, not my life’s work. I use Autodesk Fusion.

    Should I vibe code my own 3D design tool instead?

    Vibe coding something equivalent would cost far more in my time and token spend than the Fusion subscription. But cost isn’t even the main problem. The main problem is that I don’t know the domain.

    Fusion has a specific set of tools for creating 3D designs. It starts with parameterized 2D sketches, from which you build parameterized 3D shapes. Choosing the right set of primitives to manipulate 3D geometry inside a computer — flexible enough to be useful, constrained enough to be learnable — is not trivial. It probably took the industry years of trial and error to get here. I remember the primitive AutoCAD of the 90s. We came a long way. I would have to replicate that trial and error, and that is not cheap.

    Technically, I could ask an AI to clone Fusion. But that is only possible because Fusion exists. You could argue that’s fine, it exists today. But next year, Fusion will have evolved. Without Fusion pushing the domain forward, there is nothing to clone.

    And no matter how good I am at building Fusion with AI, the people at Autodesk would be better at it. They have the same AI tools, but more domain knowledge.

    This generalizes

    Pick any domain and you’ll find the same thing. I wouldn’t want to vibe code my accountancy software, or my email client, or my calendar. Don’t believe me? Think about how you would represent recurring calendar entries where each recurrence can be individually rescheduled. This is not a trivial problem.

    For some tools, the domain is trivial, and the code was the moat. That moat is gone. The drop in valuation for those companies makes sense. But when the moat is decisions, taste, or domain knowledge, it’s still there.

    The real SaaSpocalypse

    The real SaaSpocalypse is not customers vibe coding their own tools instead of buying them. It’s the new startup that vibe codes a competitor.

    The real danger to Autodesk is not me building my own Fusion. It’s someone who dedicates their life to 3D design building a competitor with AI.

    That newcomer would have an AI-friendly codebase from day one. If they invest in keeping it that way, they would add features much faster than Autodesk can on top of decades of tech debt.

    The real SaaSpocalypse is that you can now catch up to and surpass incumbents with less effort, fewer people, less investment. And the incumbents, to fight that off, will need to rebuild their internals to be AI-friendly. At some point — as crazy as it sounds — it might be faster to start from scratch than to evolve an old, tech-debt-laden codebase.

    Buy vs. build still applies

    At work we recently needed a tool. It was going to cost us tens of thousands of dollars. An engineer proposed we vibe code it instead. I seriously considered it. We understand this domain much better than I understand 3D design, and for internal tools you can move fast when security constraints are lighter.

    But it would have taken us 2 to 3 weeks. And during those weeks we would not have been developing our core product. Our unique differentiator is our own product, not a tool we can buy and use off the shelf. Our competitors can buy that same tool and have it running in hours. We shouldn’t spend weeks to get there. Focusing on our core product was the right call.

  • I’m sure this is not my idea, so I’m not claiming it to be. I’ve been wanting to do a sort of continuous AI eval in production for a while, but the situation never presented a work. It was a mixture of having the data to do the eval off line, and wanting to avoid the risks of doing it in prod. But now I’m going to do it for a side project.

    I don’t want to reveal what my side project is yet, so I’ll keep it vague. I’m very excited about this part, so I wanted to share it early. And I’m hoping that the Internet will tell me if, as it usually does, if this is a bad idea.

    I have a task that will be done by an AI and I can measure how successful it was done but only 2 to 7 days after the task was completed and seeing it out there, in the world. I will gather some successful examples to use as part of the prompt, but I don’t have a good way to measure the AIs output other than my personal vibes which is not good enough.

    My plan is to use OpenRouter and use most models in parallel, each doing a portion of the tasks (there are a lot of instances of these tasks). So if I go with 10 models, each model would be doing 10% of the tasks.

    After a while I’m going to calculate the score of each model and then assign the proportion of tasks according to that score. So the better scoring models will take most of the tasks. I’m going to let the system operate like that for a period of time and recalculate scores.

    After I see it become stable, I’m going to make it continuous, so that day by day (hour by hour?), the models are selected according to their performance.

    Why not just select the winning model? This task I’m performing benefits from diversity, so if there are two or more models maxing it out, I want to distribute the tasks.

    But also, I want to add, maybe even automatically, new models as they are released. I don’t want to have to come back to re-do an eval. The continuous eval should keep me on top of new releases. This will mean a fixed percentage for models with no wins.

    What about prompts? I will also do the same with prompts. Having a diversity of prompts is also useful, but having high performing prompts is the priority. This will allow me to throw prompts on the arena and see them perform. My ideal would be all prompts in all models. I think here I will have to watch out for the amount of combinations making it take too long to get statistically significant data about each combination’s score.

    What about cost? Good question! I’m still not sure if cost affects the score, as a sort of multiplier, or whether there’s a cut-off cost and if a model exceeds it, it just gets disqualified. At the moment, since I’m in the can-AI-even-do-this phase, I’m going to ignore cost.

  • A company’s overall goals can shape its culture. Take the popular “Employee of the Month” idea, when employees see it as meaningful, it becomes ingrained in the culture and can motivate higher performance.

    But these goals need to be achievable, and sometimes making them achievable is a small matter of phrasing. Let me show you an example. For Canva, where I work, tenure is important. One way to celebrate tenure would be by marking when people joined. For example, a company can choose to give hoodies like this:

    Person wearing a gray hoodie with 'CLASS OF 2023' printed in white on the front, standing against a plain background.

    The problem with this approach is that it would be impossible for someone to improve in this dimension. Anyone that was hired in 2024 will never achieve having been hired in 2023 no matter what they do.

    Instead, Canva celebrates Canvaversary (your anniversary of having joined Canva). It still transmit the same information: “tenure is valuable, tenure is important”. But the big difference is that every time you see someone display a Canvaversary badge with a number bigger than yours, it is a badge that you can acquire by staying around long enough. It is an achievable goal.

    My laptop now has these stickers:

    Stickers on a laptop showing '1' and '2' for Canvaversary celebrations, along with a Pexels logo.

    And I also have this beautiful pin:

    A commemorative Canvaversary badge featuring the text 'Happy Canvaversary' and the number '2', displayed on a blue background with decorative designs.

    Oh, and at the five year mark they make a poster of you. They are really good. I’m looking forward to my 5 years at Canva poster.

  • Bring your own keys into an affiliate relationship

    I’m starting to observe a problem where a lot of LLM-enhanced apps are starting to pop up. For coding you have Cursor, but now there’s also a terminal called Warp and it costs $15/month. For individuals, consultants, small and even medium sized companies, this isn’t a workable pricing model. All apps were already turning into subscriptions and the cost of LLMs is accelerating that.

    What compounds the problem is that, because everyone feels uncomfortable with the potential surprise high bill of pay-for-what-you-use, many of these apps are charging a single monthly fee. A simple single flat fee, except that the cost of the LLMs is not flat. It grows linear with usage. This means having to throttle the LLM usage to stay within the margin of the flat fee and have a chance at a profit. That means using cheaper models, which yield worse result on average.

    I think this is why when I compare Cursor to Claude Code I find Claude Code to be better: I’m giving Anthropic a lot more money than Cursor. But also, I’m happy with that, because I can use Claude in many other ways, where Cursor is a single-use application.

    I think from now on, for each LLM powered application, I either want to be able to put my own keys in, or have pay-as-you-go with a lot of transparency. When I need it to work, I want it to work well. When I’m not using it, I want it to cost nothing.

    There’s another solution though. LLM providers could have affiliate systems where other companies get a commission for the token usage they generate. Using Warp as an example, Warp wouldn’t ask me for $15/month. Warp would ask me for my Claude API key. Warp would identify all those requests as caused by Warp, and then Anthropic would pay Warp a proportional fee for the usage generated.

    This is a win-win-win: Anthropic gets more token usage (more customer expansion), Warp gets more customers (I’m not paying $15/month, but I would plug in my key), and the user gets to have another LLM tool that otherwise they would not.

  • How Your Response Determines Your Growth

    I work at a pretty amazing company, Canva, that has a culture of feedback. I think I have given and received more feedback in the two years I’ve been here than in the rest of my professional life put together. It has taught me something critical about the importance of a growth mindset. Managing several teams also gave me a lot of perspective here.

    I always thought a growth mindset would have an effect on what happens when you receive feedback, but now I’ve discovered it also has an effect on the frequency and complexity of the feedback. When I have a piece of feedback to give to someone, if that person has a growth mindset, I just give it.

    For the people with a fixed mindset, I know I’ll have objections, challenges, push backs, defensiveness. In those cases, for the feedback to be accepted, I need to collect evidence. I may need one clear case to base my feedback around but then further ones to display the pattern. It takes a lot more work and effort, and at a time when my calendar is back to back meetings and my to do list keeps growing.

    What naturally happens, even if I try to fight it, is that for people with a growth mindset, I give feedback frequently, and for people with a fixed mindset, I drop the frequency. A side effect of that is: the size of the feedback stays lower the higher the frequency is. This means the pain of receiving that feedback is lower. Let’s not pretend that receiving growth feedback is not painful.

    I think a chart showing the two growth paths would help:

    A line chart illustrating the growth trajectories of individuals with a growth mindset (represented by green) versus a fixed mindset (represented by pink), showing significant divergence in progress over time.

    The lesson here is that gracefully accepting feedback has a massive impact on how much of it you will get, and if feedback is a source of growth, then it’s extra valuable to be graceful. Possibly even when the feedback is not correct: saying “Oh, interesting point, I’d like to think about it” is not that costly. This is a lesson I’m still learning.

  • I’ve been thinking about this one for a while. Imagine you are the CEO of a company and your competitors are getting ahead of you because they started to use ChatGPT to build their tech. You ask the CTO what’s going on and the CTO says “ChatGPT was not on my job description, so I ignored it”. How would you feel as the CEO? Would you think “Ok, fair enough for not putting it in the job description” or would your thoughts be a bit more… colorful?

    The CEO has no job description other than: “Making the company successful“. The CEO is responsible for everything. If tech fails, it is the CEO’s fault, if accounting is done wrong, it is the CEO’s fault, if marketing wastes money, it is the CEO’s fault. The buck stops there for everything.

    The CTO’s role is exactly that, but just the tech part. The job description should be “Do anything and everything in the tech domain to make the company successful“. Are the servers down? It is the CTO’s fault. Marketing doesn’t have the features they need for a campaign, it is the CTO’s fault. Ransomware destroys operations, it is the CTO’s fault. Tech is spending too much money, it is the CTO’s fault. Too much technical debt, too little, not delivering fast enough, having the wrong kind of skills on the devs, devs are unhappy. Again… it all falls on the CTO’s shoulders. At least this is how I take on the role when I carry the title of CTO.

    This means the CTO is responsible for problems that nobody ever assigned to them. That’s one of the reasons this role is hard. And to be able to do such a role, the CTO needs autonomy, information, access, etc.

    Autonomy is achieved through budget authority. The CTO presents a budget to the CEO and CFO, who approve it and then executes on it. Ideally, then the CTO receives periodic updates from the CFO comparing expenses to budgets, and whether the company has the revenue to back that budget up. If the CTO overspends beyond the tech budget, that’s a problem, but if the company shrinks, that’s a problem too. In both cases the CTO should be proactively thinking about how to cut cost and manage the expenses (before hitting a wall, having a massive layoff, etc).

    Information and access is achieved through having a strong exec team. An exec team that is all on the same page. Including a clear vision from the CEO, a clear understanding on how all other departments are achieving their goals, and how tech helps or hinders them.

    So if there is a job description at all, it should be not for the role of the CTO, but rather for the company itself: what it means to achieve, and how it behaves to empower its C-Suite to further their ambitions.

  • When I was 16 years old or so, one day, my computer didn’t boot. I got a blue screen with some white text-mode error. Something was broken with the file system. This was after being utterly disappointed by Windows 95 and before I became a Linux person, so I was running Windows NT 4.0. I was the only person I knew running that operating system, and thus the only person I knew with an NTFS partition.

    What to do now? That was my only computer, thus I couldn’t get online, smartphones wouldn’t be invented for another decade, I had nobody to ask for help and no tools to run checks on an NTFS partition. That filesystem was quite new back then. I could just blank the hard drive and reinstall Windows NT and all the software. But what about my data? my data!!!

    At 16 years old I learned the lesson that the data is the most valuable and important thing inside my computer. Everything is replaceable. I’m sure if I could see that data now I would life, but for 16-year-old-me, that was my life. I started making backups and since that day I had a personal backup strategy that’s more robust than 90% of the companies I talk to. I have yet to lose a file and I hope to keep it that way. My ex-wife recently recovered from a complete computer failure because she’s following the backup strategy I set up for her.

    One of the things I wonder is, should I have to do a total restore of my data, how do I verify it? I have more than 2 million files. Big chunks could be missing and it might take me years to notice. Because I have so much data to backup, keeping my 3 backups all up to date is hard, so it’s possible that I may have to reconstruct my information piecing things together from the 3 of them. Technically my backup software should be able to do it. But… I’m skeptical.

    This is why every night I have an automatic script that generates a list of all of my files in a text file. That text file gets backed up and unless that files gets permanently and historically lost, I can use it to verify a backup restore. I think my friend Daniel Magliola gave me this idea.

    Since I use Windows (shocker, I know, but try building a Mac workstation with 6 screens and play video games and report back to me), I wrote the script in PowerShell, but since I couldn’t find anything like Linux’s find, the script invokes wsl. Here it is, normally I put it in c:\Users\pupeno\.bin\filelist.ps1:

    echo "Creating list of all files in C:"
    
    wsl find /mnt/c/Users/pupeno -type b,c,p,f,l,s > C:\Users\pupeno\.all-files.new.txt
    
    move -Force C:\Users\pupeno\.all-files.new.txt C:\Users\pupeno\.all-files.txt
    
    echo "Creating lists of all files in D:"
    
    wsl find /mnt/d -type b,c,p,f,l,s > D:\.all-files.new.txt
    
    move -Force D:\.all-files.new.txt D:\.all-files.txt
    
    echo "Creating lists of all files in E:"
    
    wsl find /mnt/e -type b,c,p,f,l,s > E:\.all-files.new.txt
    
    move -Force E:\.all-files.new.txt E:\.all-files.txt
    

    And this is how it’s configured in the Task Scheduler to run every night. First run Task Scheduler:

    Once it’s open, create a new task:

    I hope it helps.

  • To convince people to come work for you you offer them, aside from compensation, perks. And you try to have better perks than your competitors (other employers). Brainstorming with my friend Justin a few years ago I came up with what I believe is the ultimate perk and since then I’ve been desperatly trying to find a place to deploy it. I haven’t found a place where I feel even comfortable bringing it up, that’s how far I am from deploying it, so I’m sharing it with the world. If I was running my own company, I’d deploy it in an instance, not giving it a second thought.

    This is the perk: every developer gets a confidentiality-bound personal assistant. There wouldn’t be one PA per developer, because they don’t need nor have enough work that can be delegated to keep one person fully occupied. Instead there would be one for all of the developers (or two, or three… or whatever you need depending on how many devs you have).

    First, I don’t think this would be a very expensive perk, because actually delegating work to a PA is a skill that you have to learn and most developers will not have it. Most developers will not know where to start. But most developers will likely enjoy saying “I have a PA” or “I have a secretary”. Having said that, I would actually run courses for the developers to learn to delegate because…

    It’s a perk that pays for itself. You might think you are paying for extra employees or contractors, but your developers are likely the most expensive salaries in your books. So if they can pass a task to someone else, you are saving money, not spending money. Let’s say a developer needs to arrange a call with a vendor to discuss a technical mater. They have to search for the right person, their contact details, go back and forth over emails. Imagine if the developer just tells their PA “Can you arrange that call?” over a Slack message and that’s the end of it. Back to coding!

    Think about making reservations, making doctors appointments, running errands, making phone calls in general (this is why they should be confidential). Developers tend to hate phone calls. Imagine if they could delegate to someone complaining about a flight ticket that got canceled! I once had a coworker who spent half a day on hold while pretending to code.

    It’s a perk that generates retention: you know why Google pays for food, haircuts, laundry, doctors on-site, etc? It’s because that generates a lot of retention. When you quit Google, you not only need a job, you also need to find a hairdresser, a place to clean your clothes and make doctor’s appointments. They treat you like children and you became as dependent as you were on your parents. I’m not exactly sure where the ethical boundary is here, but offering a free PA feels on the good side of things.

    It’s unique: nobody is doing and I bet nobody will start, even after it’s been proven successful. It’s like private offices: we have the studies to prove that developers need silence to focus and yet we cram them in open office buildings. Private offices, and PAs, are for the three-piece suit executives, not for the lowly developer, so it’s not a perk likely to get devalued when everybody picks it up, because nobody will.

    It’s loud. Imagine when the developer is hanging out with other developers and jokingly says

    Have your people call my people to arrange it

    Oh… you don’t have people? I do… this email address and phone number is my PA, just call them… and if you want a PA, come work for us.

    I’d love to try this some day… 

  • You should not send rejection emails to job candidates when there was no interaction. For example, in the case of rejecting someone just from the application, without a screening call.

    There’s a mantra that good recruiters and hiring managers take on the difficult task of sending rejection emails instead of just ghosting candidates. But I don’t think this should be a black and white decision. Do you agree? Disagree? Please leave a comment with your point of view, I’m intrigued.

    When you had a screening call with the candidate, then the candidate will likely be wondering about the next step, so if the rejection happens at this or any other later stage, then yes, ghosting is extremely rude and you should always send a rejection email and possibly some feedback for the candidate to improve. More on that later.

    If there hasn’t been any interaction, you shouldn’t have your only interaction with the candidate be a rejection. The reason for this is that most of us have, at some point, been desperate, and started applying to lots of jobs hoping that someone would pay us some attention, hoping we may accidentally open a door, and because being homeless is worse that shotgunning job ads. And actually, when the job ads are anonymous bland indistinguishable walls of text, there’s not a lot you can do other than hit apply and move on, so don’t hold it against the candidate.

    The problem is that then this candidate might have hundreds of applications that result in tens of rejections emails. Rejections for roles the candidate forgot about 10 seconds after hitting apply (how long can you remember a non-descript job post about an anonymous company anyway?), so all you are doing by sending the rejection is reminding the candidate that they didn’t get something they forgot they tried to get. When you get tens of these, one after another, it’s emotionally debilitating. It’s no wonder that a candidate might snap at one too many rejections.

    Oh, and about feedback: if you have nothing to say, don’t say anything. If you are going to give feedback, give actionable feedback. Giving someone impossible feedback is a slap in the face. For example, for a few years, I’ve been wanting to have an engineer manager position at a big scale-up or at a big company. When I get rejected and I ask for feedback, most of the time it boils down to “You haven’t been an engineer manager at a big company before”. What am I going to do with that? They might as well tell me “Have you tried being a different person? Have you tried having been born in a different country?” It’s useless and infuriating.

  • I just got an Icom IC-750 with the goal of going out in the open and the first thing I did is try to configure it with my computer because it’s what’s most convenient for me. I like keeping backups of various configurations and being able to go back to them. I’m also working on a project to help set up repeaters in this and others radios.

    Unfortunately, I encountered the error:

    Connected transceiver is not compatible model.

    Check the following:

    • Appropriate programming software for the transceiver is being used.
    • The revision number of the transceiver

    What was confusing is that the CS-705 was correctly seeing my connected IC-705:

    I tried a few things, but long story short, my IC-705 had firmware version 1.31 and I was running CS-705 version 1.11 when only version 1.20 supports firmware 1.31. Now that I upgraded everything works:

    And for the record, I’m running the USB driver version 1.12.

    I find the Icom’s website to download the different versions of the software a bit confusing (especially the interactions between Icom UK and Icom Japan), but you can find it searching there