If you are the technical co-founder or early engineering lead at a startup, and you want to talk about your microservices, hand-rolled CI/CD, in-house monitoring stack, or any other unique part of your stack, I will say: Cool. Let’s riff. Take me deep, I’m ready.

But there’s something I’m likely to tell you in return, something I’ll probably insist you’re overlooking and need to internalize as soon as possible: Your technology stack is not the product.

It’s easy to get too focused on our tech and tools. Sometimes we think it’s our competitive advantage, other times it’s merely personal fascination and intellectual stimulation. This post is a good reminder:

A mindset of technology being the means, not the end, is uncomfortable. But it will help you stay focused on what matters most (the product and your customers), avoid wasteful misadventures, and maximize the company’s chance of success.

Stephan Schmidt warns: “We have invited complexity through the door. But it will not leave as easily.”

One way to simplify your stack and reduce the moving parts, speed up development, lower the risk and deliver more features in your startup is “Use Postgres for everything”. Postgres can replace - up to millions of users - many backend technologies, Kafka, RabbitMQ, Mongo and Redis among them.

He then goes on to list nine things you can use Postgres for that replace more specific solutions: fulltext search, geospatial queries, etc.

Matt Welsh:

I hesitated writing this post, because I don’t want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I’ve had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I’d like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important.

The learning curve and hiring difficulties seem to be the major culprits, in Matt’s experience.

Dendron founder, Kevin Lin:

PMF is not just your only job but it is the job that only you, the startup founder, can do. Your investors can help introduce you to relevant people, successful founders can tell you how they found PMF, but ultimately, you are the only person that can determine PMF for your company.

And don’t forget to talk your users along the way!

Jean Yang:

There’s clearly a lot of programmer pain. But why we don’t see more tech transfer of these “deep” technologies from research into industry is something I have been thinking about since I was in college, when I decided I wanted to spend my life making programmers’ lives better. Many other fields, from robotics to databases, have clearer paths to commercialization. But when it comes to new programming languages or software analyses, the path of tech transfer is often decades-long, if it exists at all.

She goes on to describe a few factors that are in the way of “deep tech” dev tools investing, how some of those things are changing, and how others still need to change.

Here’s Paul Graham with some wise advice he’s learned from YC’s users — this also tees up a large conversation on this Friday’s episode of The Changelog (talk to your users).

I recently told applicants to Y Combinator that the best advice I could give for getting in, per word, was. Explain what you’ve learned from users.

Here’s why that makes sense.

That tests a lot of things: whether you’re paying attention to users, how well you understand them, and even how much they need what you’re making.

But giving this advice made Paul consider what he has learned from YC’s users (the startups they’ve funded). This one is almost cliché at this point, but still quite true.

Focus is doubly important for early stage startups, because not only do they have a hundred different problems, they don’t have anyone to work on them except the founders. If the founders focus on things that don’t matter, there’s no one focusing on the things that do.

Devon Zuegel draws a comparison that I would’ve never thought of:

Pirate crews developed a surprisingly similar approach to compensation in the 17th century. Just like many startups, they also balanced equity incentives with other mechanisms that would be familiar to a startup employee today, such as bonuses.

These surprising similarities offer an interesting frame through which we can reflect on why startup equity and bonuses are structured the way they are. We can learn a lot about the theory of compensation in modern companies by looking at how pirates designed incentives to organize and motivate their work.

Maybe it’s time to stop hiring “frontend wizards” and start looking for “frontend pirates” instead, matey.

A very cool case study of Segment’s long journey to creating a product that people would actually pay money to use.

By now they burnt $500K and were left with only $100K. They wanted to tryout something for one last time with the $100K. One of their Co-Founders suggested that they try to productise their open source library. Peter, the Co-Founder & CEO didn’t like that idea at all. This open-source library had only 580 lines of code, compared to the other 2 products which had 100x more lines of code and a very grand vision on how to define an industry.

Side note: what is this bip.so thing that’s hosting the content?!

Most of our audience knows that we operate on the mantra “Slow and steady wins,” and yet there’s lessons to be learned by reading a post adjudicating the need to “Move fast or die.” Let me explain…

There’s a key phrase that sets this post and its lessons apart from us here at Changelog Media — it’s “Here’s how we did it at Facebook.” Clearly, we are not Facebook, so we should not operate on advice that’s focused on Facebook. However, we can learn something.

Of the the five lessons shared, each can be appreciated, but one in particular stands out.

We embraced asking for forgiveness, never for permission.

This, to me, is synonymous with “Hire people smarter than you,” because it assumes everyone can bring something to the table that former wisdom might not. It gives permission to try something new and see if something beautiful comes as a result. That’s a good thing.

It is a very good thing for Salesforce to be more focused on Heroku’s future, but the glaring detail shared by Bob Wise today is the era of free on Heroku is over.

Here’s what they announced:

• They launched an interactive product roadmap on GitHub
• They are focusing on mission critical and will discontinue free product plans and delete inactive accounts
• They are starting a program to support students and nonprofits
• They will continue to contribute to open source projects, notably Cloud Native Buildpacks and offering Heroku credits to select open source projects through Salesforce’s Open Source Program Office (OSPO)

Greg Kogan:

I used to think being swamped was a good sign. I’m doing stuff! I’m making progress! I’m important! I have an excuse to make others wait! Then I realized being swamped just means I’m stuck in the default state, like a ball that settled to a stop in the deepest part of an empty pool, the spot where rainwater has collected into a puddle.

Good analogy. Better sentiment. Reminds me of Woody Zuill’s thoughtson productivity vs effectiveness.

Only 5% of Indie Hackers products make $100k/year…

A sobering statistic, but with a caveat: this only accounts for the 937 products that have their revenue verified by Stripe. The 5% is low, but that’s for a high bar of $100k/year. It gets worse:

A prevalent thinking is that making money as an indie developer is hard and most of the products end up with no revenue at all. Products on Indie Hackers seem to confirm this as more than 54% of the products are not making any revenue at all.

The post also breaks down the best performing product categories. ‘Wearables’ looks like a good one.

(We love the Indie Hackers community and know how hard it is to make it on your own. This post is not intended to denigrate anyone, just provide information.)

Building products is a difficult and time-consuming effort. Figuring out what the problems, finding a potential solution to that problem, and then building that solution all take a decent chunk of time and effort. It’s due to this process that the minimum viable product was born. The motivation for building an MVP is still valid. Build something small and easy to test, launch quickly, and pivot or trash it if it doesn’t perform as desired.

There is another, less selfish way.

I read an article by Jason Cohen a few years ago which changed the way I think about product development. Instead of building MVPs, we should be building SLCs. Something Simple, Loveable, and Complete.

I like the thinking behind SLCs. So simple, so loveable, so…

Hat tip to Henry Snopek for linking this up in the #gotimefm channel of Gophers Slack! When it comes to thinking about your projects, Henry says:

I like to use MVP for fast projects, and SLC for “effective” projects…

Yeah, I like that framing too. So simple, so loveable, so…

Ken Kantzer was part of ~20 code audits of companies that had just raised their A or B rounds of funding:

It was fascinating work – we dove deep on a great cross-section of stacks and architectures, across a wide variety of domains. We found all sorts of security issues, ranging from catastrophic to just plain interesting. And we also had a chance to chat with senior engineering leadership and CTOs more generally about the engineering and product challenges they were facing as they were just starting to scale.

In this post he shares some of the more surprising things he’s learned from the experience. There’s a lot to digest in this post, but I’ll highlight my favorite to whet your whistle:

Simple Outperformed Smart. As a self-admitted elitist, it pains me to say this, but it’s true: the startups we audited that are now doing the best usually had an almost brazenly ‘Keep It Simple’ approach to engineering. Cleverness for cleverness sake was abhorred. On the flip side, the companies where we were like ”woah, these folks are smart as hell” for the most part kind of faded.

A ranty story from Kitze on a time when he didn’t ship the app he was working on and somebody else did!

It’s not their fault. I was just slow. I didn’t ship on time. I’m gonna go ahead and tattoo “JUST SHIP IT” on my forehead. Nah I wouldn’t be able to see it there. On my arm maybe. Nvm, let me go back to scrolling their landing page.

Josh Stella:

For those who haven’t used Emacs, it’s something you’ll likely hate, but may love. It’s sort of a Rube Goldberg machine the size of a house that, at first glance, performs all the functions of a toaster. That hardly sounds like an endorsement, but the key phrase is “at first glance.” Once you grok Emacs, you realize that it’s a thermonuclear toaster that can also serve as the engine for… well, just about anything you want to do with text.

Big news from our friends at Hugging Face:

Hugging Face is now the fastest growing community & most used platform for machine learning! With 100,000 pre-trained models & 10,000 datasets hosted on the platform for NLP, computer vision, speech, time-series, biology, reinforcement learning, chemistry and more, the Hugging Face Hub has become the Home of Machine Learning to create, collaborate, and deploy state-of-the-art models.

What will they spend the money on? Good stuff:

Thanks to the new funding, we’ll be doubling down on research, open-source, products and responsible democratization of AI.

GitLab’s Sid Sijbrandij shares 12 strategies managers can use to support their team and prevent burnout. One of his standout strategies that I doubt rarely gets put into use is reduce the number of hours worked by agreeing to reduce effort

Supabase CTO Ant Wilson walks through the pros & cons of open sourcing your startup and why he believes the answer to the question in the headline is (probably) “yes”

Open-sourcing Supabase ended up surprising us in many ways. Many people imagine that maintaining your business in public might be burdensome - but the opposite is true. There are many unexpected upsides that have made building Supabase - the product and the company - easier.

While some of this advice comes from our lens as a Dev Tools or PaaS company, most of it will apply to any software company.

DuckDuckGo and Bing are not true alternatives – they’re just worse versions of Google.

The next Google can’t just be an input box that spits out links. We need new thinking to create something much better than what came before.

In the last few years, different groups of people came to the same conclusion, and started working on the next generation of search engines.

For this new generation, privacy is necessary, and invasive ads are not an option. But that’s where the commonalities end. Beyond that, they’ve all taken the idea of a search engine in very different directions.

The post goes on to describe & detail a whole new wave of search engines. I had no idea so many people were working on this problem. Exciting!

Chris does a great job answering what will surely be the most common question about this acquisition in his announcement post:

1. What happens to CSS-Tricks?
2. Will you still be running CSS-Tricks?
3. Why now?

The amount of value this team has given to the web world over the years is immeasurable.

I sincerely hope DigitalOcean turns out to be a worthy new steward of this precious resource and the site’s best years are ahead of it. 🤞

Jean Yang:

Should you move to serverless? Is GraphQL the answer to your API woes? Should you follow the latest DevOps playbook to increase your system reliability? In the world of tech tools, there’s a lot of buzz. But it doesn’t always reflect the daily reality of programmers.

As the founder of a developer tools startup, I’ve talked with hundreds, if not thousands, of software developers over the last few years in the course of routine user research. The common theme in these conversations, even bigger than the need for the product we were building, was an overarching need that is currently underserved: building for real developers, or what I like to call the 99% Developers.

Good stuff to be reminded of. That reminds me: You are not Google/Amazon/LinkedIn.

The criteria for inclusion is as follows:

1. Its product is strongly based on an open source repo
2. It has a well-known closed-sourced competitor, solving a similar business problem
3. It is a private for-profit company, founded in the last 10 years
4. Its repo has 100+ stars on GitHub

I’m seeing lots of Changelog guests & friends in this awesome list. 😎

Rauno Metsa:

I’m a developer and I love to write code. I enjoy watching my brain come up with creative solutions for complex problems.

So, I often find myself with a blog post that’s ready to be submitted to Hacker News, or a tweet that’s ready to be sent, but postponing it.

Sound familiar? If so, read the story to learn how he got over it and started benefiting from his new-found confidence.

Alexey Milovidov, announcing the formation of a (VC funded) corporation around ClickHouse, an open source analytics DBMS:

Today I’m happy to announce ClickHouse Inc., the new home of ClickHouse. The development team has moved from Yandex and joined ClickHouse Inc. to continue building the fastest (and the greatest) analytical database management system. The company has received nearly $50M in Series A funding led by Index Ventures and Benchmark with participation by Yandex N.V. and others. I created ClickHouse, Inc. with two co-founders, Yury Izrailevsky and Aaron Katz. I will continue to lead the development of ClickHouse as Chief Technology Officer (CTO), Yury will run product and engineering, and Aaron will be CEO.

ClickHouse wasn’t always a business. It also wasn’t always open source.

Making ClickHouse open source was also not an easy decision, but now I see: doing open source is hard, but it is a big win. While it takes a tremendous effort and responsibility to maintain a popular open-source product, for us, the benefits outweigh all the costs. Since we published ClickHouse, it has been deployed in production in thousands of companies across the globe for a wide range of use cases, from agriculture to self-driving cars.