we make and run software

Profitable software lives, unprofitable software dies.

Profitable software gets appropriate attention, maintenance, and improvements; unprofitable software rots and decomposes until it's dead. Unprofitable software will always lose attention to profitable software. No rational actor will ever allocate time, effort and resources to software that's not making money – especially if the alternative is building software that does make money. The default state of software is dying, not living – all software needs resources just to stay alive. Those resources can only be allocated if the software is making enough money to justify the efforts.

It's in the best interest of all parties (users, developers, employees) that software is and stays profitable. The incentives are perfectly aligned so that the more money a piece of software makes, the better it is for everyone involved – users more than everyone else. The highest the growth rate, the more profit, and the best product for the users.

Making money is #1, everything else is secondary. There's no problem a software startup can have that revenue cannot fix. Traction trumps everything.

Be wary of free products, because they either are not going to be around for much longer, or are harvesting you in ways you're probably unaware of. Some software may not have a price tag in order to serve some other tangential business goals, like marketing, branding, traffic, all that stuff. But at the end of the day, all software ties to some measurable, revenue-generating activity; and if it doesn't, it's probably not good software.

The worst software is software no one cares about.

People are selfish and self-centered. I am selfish and self-centered. You are selfish and self-centered. We only care about our own problems. We only care about problems that affect us directly. Not about imaginary problems someone else might or might not have.

The fastest way of making bad software is making software that doesn't speak directly to people's problems – which is punished with irrelevance. If no one is using your software, chances are you're not solving any problem for anyone.

All good software solves a problem for a user. If the software didn't exist, the user would be using something else to solve the problem – either a competitor, or a hacky solution.

Good software needs to constantly be tested against real users. Test in production, with real production traffic: no battery of tests will guarantee your product solves user needs. Ship early, ship fast, improve immediately.

Good software is bold and unapologetic.

Good software does one thing very well, and one thing only. Good software knowingly and purposefully leaves things on the table. Good software knows everything it doesn't do and why exactly it doesn't do it.

The latent space is infinite. Diving deep into the latent space means going down a deep rabbit hole, but that's only valuable if you extract something of value from it.

The creative process only works because every divergence phase is followed by a convergence phase. Ideas are fractal. When you explore ideas, every new door you open will lead you to a corridor with an infinite number of doors to open, each of which will lead you to an identical corridor. You will always be able to find a feature idea to add next. If you do this, your to-do list will keep growing forever, and you'll get nothing done. At some point you need to start saying no – ruthlessly. The scope of software needs to be limited somehow, or it will limit you. The best way to limit scope is to time-box things strictly. Goals without deadlines are just wishes. Bringing things into actuality means killing most of their potential in the process. Creating means choosing, and choosing means leaving most things out. And that's precisely what makes software bold.

Nobody likes it when software forces you to call a random number to cancel a subscription.

Unfortunately, software nowadays is full of dark patterns like this. But that precisely is what sets mediocre software apart from good software. Good software is built on trust and transparency. No dark patterns, no hidden fees, no tricks. Things should be as straightforward as they possibly can. Cancellations should be one or two clicks. Refunds should be self-served. Error on the side of trusting your users too much: deploy countermeasures only when specific bad actors abuse that trust. The winning strategy for the long-run is tit-for-tat: trust first, but respond firmly to breaches of that trust.

Honesty naturally leads to authenticity. And in an age of fake online personas and distorted digital reality, authenticity will always win. But authenticity cannot be faked. Humans can spot something fake in milliseconds. Our brains have evolved to do so.

Being authentic means not having fear to offend people. Authenticity cannot be faked. The reason why texts written by ChatGPT look like texts written by ChatGPT is because they're bland. They're not authentic. They offend no one. You can tell this text has been written by a human because it has something. It has soul. It's bold. It may be wrong – and the person behind it may be willing to fight back to defend it when questioned. Without that, it would be full of clichés, corporate jargon, and all sorts of business bullshit that try to appeal everyone but convince no one. The reason you can tell this is the case is because this text comes from a place of honesty. We really believe all this. Without honesty, all things –software included– feel fake, devoid of life, soulless. And people can tell that, almost instantly. There are no shortcuts to this.

Software is a means to an end. Software is not a thing in itself – no one writes code just for the sake of writing code. Software needs to serve a bigger purpose, a task to do, a problem to solve. At the end of the day, either the task is done – or is not.

Software is valuable only in so far it does the thing it needs to do. Good software achieves that goal no matter what: through pragmatism. Nothing matters as long as the job is done.

Good software is no-bullshit, it just focuses on getting things done. We personally found Ruby on Rails to be the best language and framework to embody this philosophy. We believe Ruby is, in fact, the best gateway language to meet interesting people. Most Ruby developers share our business-savvy, action-oriented mindset. But technology is irrelevant at the end of the day.

Nobody cares what programming language you used to write your software. Nobody cares about your sophisticated Kubernetes cluster. People only care about what problem you solved for them. The most elegant code in the world means nothing if it doesn't deliver value to users. Pragmatism means being ruthlessly focused on outcomes. It means choosing boring technology that gets the job done over exciting new tools that might break. It means shipping a product that solves the core problem instead of waiting for perfection. Good software makers don't get caught up in technical purity or architectural elegance – software serves a business purpose first and foremost. While there's value in exploring new technologies and frameworks, they should never get in the way of shipping working solutions.

Perfection is the enemy of good.

Bad software makes you think. Good software thinks for you.

This doesn't mean avoiding complexity – this means simplifying complexity. Simplicity is what makes software truly premium.

There was an Argentinian magician named René Lavand. He lost his right hand when he was a kid, so he had to learn how to do magic one-handed. In his routines, he always made reference to "the beauty of simplicity", the core concept that vertebrated all his artistic work. He used to say what he did was "simple, but not simplistic". Even though what he was doing was extremely complex (try doing card tricks with your left hand while your right hand stays in your pocket), he always made it look smooth and easy to the audience. He didn't choose to make simplistic, bland tricks; instead he put in extra work to reduce perceived complexity and make things look simple. Good software does exactly this.

Making simple, elegant software is harder than making complex software. Anyone can add features and clutter an interface. The real craft is in knowing what to leave out. Overengineering is the enemy of good software. Software doesn't need more features, but the right features.

Like good typography – it's invisible when done right, but you immediately feel when it's wrong. It's a sort of "quiet excellence". True premium software isn't about complexity or fancy animations, but about having the taste to build things that just work without overloading the user's cognitive bandwidth.

Be the Dieter Rams of software: good design is as little design as possible, but every decision that remains needs to be just right.

Writing code is a creative act. Code should be elegant. Writing software should feel like writing poetry. Other peers reading your code should go like "damn, that's clever, how did you come up with that?"

Bad code looks ugly. Senior developers can smell spaghetti code from miles away.

This is not just an aesthetic matter – aesthetics always precede function. Things that are ugly don't usually work well. Things that are beautiful reflect care and thought put into them, which usually correlates with good function. Aesthetics are not complementary – they are central. Good software IS beautiful. Understanding software as art means beautiful software serves a functional purpose, not a purely decorative one.

Messy writing indicates unclear thinking. In the same way, clear ideas are simple and elegant, and lead to beautiful code. Ugly code is a red flag for unclear thinking. Unclear thinking is a red flag for not understanding something well enough.

Quality cannot be faked.

Good software should be delightfully obsessive. Good software should look and feel top-tier. Good software puts a lot of effort into tiny details, because tiny details make all the difference. Mediocrity and conformism are the enemy. If you want to attract top-tier clients, you need top-tier software. Game recognizes game. Good software gets organic recognition, not because someone is pushing for it, but because it's just so good people naturally talk about it. Good software gets automatically press coverage without anyone writing any emails to any journalists. Paid marketing is the price mediocre companies pay for making mediocre products. Good software has word-of-mouth built in.

Good software is conversational, casual, and fun. Good software feels like having a conversation with a friend. Bad software feels like being on hold at the phone for 40 mintes to do a simple bureaucratic transaction.

Good software needs to be fun to create and run. If something is not fun, just automate the non-fun parts. There's no point in putting all your heart and skills into something if you're not having fun with it. Writing software shouldn't feel like just connecting pipes and moving things around – writing software should feel deeply engaging. It should be an adventure, not a chore. If it feels repetitive and boring, it probably should be automated by an LLM. Human time will be much better spent elsewhere.

This mindset creates an environment of playfulness. Playfulness is a prerequisite for genius. Creativity can't flourish under any other setup. The software development environment needs to be forgiving enough for mistakes to be both frequent and inconsequential. Outliers can't explore the vicinities of known territory if they don't have certainty they won't be punished for doing so. Good software must go thorugh cycles of explorative divergence first, and cycles of obsessive, ruthless convergence later. That's how software breathes, that's how innovation happens.

You can't have simple, beautiful, pragmatic software if you are not lean and independent.

Venture capital, board members, advisors... all that introduces interests not aligned with the software end users. They misalign incentives and fuck up users. All of a sudden your company is focusing on "generating bigger returns for the shareholders" instead of making the product better for the users.

Simple, straightforward teams win complex cap tables every day of the week. Scaling up via bureaucracy and unnecessary people on the board won't help you create good software – on the contrary. It will slow you down and turn you mediocre. It will make you vulnerable to good software makers that kept lean and stayed independent.

This is not to say your software product shouldn't scale. Products can scale to hundreds of millions without all that corporate crap. Good software can be run at big scales without the need for big teams (think of Telegram, who serves almost 1 billion monthly active users with only 30 employees – 1000x less than Meta)

You don't need more employees, you need better team members. Genius always comes from single, exceptional, disproportionally talented individual contributors, not teams. Teams keep things stable and running; only individuals create and improve. Not managers, not consultants, not teams: only individuals create disproportionate value. All the rest do is introduce bureaucracy and fuck up the agile, quick reaction capability individuals have. You need to be lean enough to quickly react to market trends and to user feedback. Bugs should be fixed in hours, not months. Staying lean is a moral duty for making good software. Having small, mostly flat structures of highly talented individuals that can own entire things and play with them with full creative liberty is the only recipe for success. It has been proven time and time again, and outperforms traditional large structures by a factor of thousands.

Good software is made by skilled people, not more people.

AI is not the enemy.

We're living in the middle of one of the biggest –if not the biggest– technological revolutions humankind has ever seen. And in this very special moment in time, we constantly see very senior engineers complaining daily about AI and the slop it generates. As if AI degraded the quality of the industry by generating subpar code, or something like that. They're miserably missing the point.

AI is just another word for automation. Automation creates leverage. In this case, what's leveraged is developers' time. AI is already multiplying developer productivity on a daily basis. Things that used to take a week now can be done in 1-2 days: if you haven't experimented it yourself in first person yet, you're already behind. The best part is this productivity multiplier is likely to keep growing fast. And there hasn't been a single time in the history of mankind where an increase in productivity hasn't resulted in a net win for all humans in the long run.

The end result here is that AI will end up commoditizing software. AI will allow more and more people to write code. But the code LLMs write is often incomplete, full of bugs, or needs a human expert to put it into production to deliver actual value. AI will flood the market with low-quality, unmaintainable software.

In a world where code is commoditized, human judgement will become the key differentiator. This flood of mediocrity is what brings the opportunity: when everyone can generate basic code, true software craftsmanship and expert know-how become exponentially more valuable.

In the age of automation, smart craftsmanship is the answer. Casio sells $10 quartz watches; Patek Philippe sells the same good but 10,000x - 100,000x more valuable. Both are good, and both leverage automation. The difference? Patek understands exactly where human judgment and expertise creates exponential value – and that's where they focus their master craftsmen's time. Some of their hand-finishing processes take weeks worth of their finest, more skilled human experts. Low-skilled, low-value developers that currently write repetitive code in bulk will probably be automated relatively quickly; highly-skilled developers with a love for fine craft and an exceptional understanding of software in broad terms will probably skyrocket.

This doesn't mean doing things manually just for the sake of it. This means being clever about what to automate, and what not to. You don't want to be the guy selling and maintaining horses in the midst of the engine revolution. You want to be the Fords and the Teslas – deploying human genius to implement automation where it needs to be implemented, keeping creative human exceptionality at the driving wheel.

The future belongs to the generalist masters who can architect entire systems, who know exactly where to deploy automation and where human creativity creates exponential returns. These craftsmen won't avoid AI – they'll wield it as their tool, knowing that automation isn't the opposite of craftsmanship; it's a core component of modern craftsmanship. These modern craftsmen fly the flag of techno-optimism every occasion they can. In a world drowning in mediocre AI-generated code, they'll be the ones building systems that actually work, scale, and endure.

As software makers, it's our moral duty to automate everything that needs to be automated. Always monitor and keep a human in the loop to ensure the quality of the automation, but good software needs to automate everything it can – to free ourselves from the repetitive tasks that don't add value and focus on what really matters.

The opportunity cost of not doing it is just too high. In this new world we need to be ruthlessly conscious of where we're putting our efforts. Misplacing our skills in the wrong tasks exposes us to the risk of being automated by AI; but nailing it down gives us the biggest leverage that has ever existed.

Automating goes beyond AI. Don't use customer support for things that can be solved with automation. Customer wants a refund? Offer a way they can get a self-served refund, with only a few clicks, without any human intervention. Customer support gets one request or complaint often? Build its fix into the product instead of overloading customer support. The end goal is not creating better FAQs, the end goal is deleting FAQs altogether because everything has been automated into the product itself. Good software takes no human input to run well and delight users.

You can't have a good product if you don't use it yourself every day and feel in your own skin the pain of using it when things don't work well.

That's the most powerful force that can drive a developer, a maker, a software creator, to prioritize tasks, improve the product, and fix what's broken. Products don't need monitoring a thousand business metrics – they need the founder using it daily.

Dogfooding means forcing yourself and your developers to use the product to feel the pain points. It means developers doing customer support and interacting directly with customers, because how the fuck else are they going to get any real grasp over what customers really want? Through a project manager? An intermediary who most likely doesn't know anything about technology and is only going to add noise, bias and their own bs to the raw, unfiltered message? Good luck finding examples where adding tech-illiterate intermediaries helped built better software.

Interacting with the end customer is a pre-requisite for creating good software – not for just developers, but for any role.