AI erased most product-level moats. So defensibility now comes from things that are intentionally hard to replicate.

• brand & distribution

• being a “compound startup”

• vertical integration

• migration pain

Brand & distribution

The obvious one. Having an existing distribution is a game changer. Think Microsoft pushing terrible MS Teams to their existing user base to beat Slack’s usage numbers.

Building a trusted brand perceived to be building quality products is priceless today. Your brand’s reputation takes years to build yet it’s trivial to lose.

Being a “compound startup”

Launching multiple tightly integrated products solving different problems for the same customer. Single product startups might be easier to build and faster to grow initially, but they’re a lot more vulnerable to competitors too.

“Compound startups” leverage that billing, reporting, authentication, onboarding, support, data models are all shared across multiple products, and you only need to build them once.

Being “a compound startup” means you can use product bundling to your advantage: you can compete on margins where it hurts your competitor but it doesn’t hurt you. Every company now pays for 30+ SaaS vendors. The bar for being the 31st is higher than ever, but selling one more product to existing customers? Easy!

But man building a compound startup is complicated! Different products mean different customers constantly pull you in different directions. If you found building a single product difficult, multi-product is a different level.

Vertical integration

How many new startups are building their own data centers today? Close to zero.
How many are hosting data in Supabase? Most.

There are things you can do with data in your own data center that you can’t do with Supabase. You can tailor your hardware to your software, not the other way around. You could optimize costs and capex/opex.

It’s an insane pain to host your own servers though. But that’s the point.
If it brings you a real benefit, it might be worth it even if super painful.

Migration pain

Can you make your product easy to onboard while being difficult to rip out?

I don’t care if a vendor sells me on a slightly better or a cheaper product if I need to change workflows of an existing team or migrate a ton of data. Switching costs are not just technical; they are social, operational, and political.

The point is there’s “no quick wins” anymore

If you launch an obvious & easy to build idea today, you’ll wake up to 17 competitors on Product Hunt tomorrow. AI removed most “easy” moats. The only durable ones left are the hard ones.

Aiming to build a lasting business? It might be easier to work on a hard problem than an easy one today.

Assumptions:

• typical European 4 weeks paid time off

• 10 public holidays excluding weekends

• and 5 sick days per year

A typical employee in a corporate job putting in 6 work hours per day in a ‘chill mode’ clocks about 1,356 hours per year.

What about others?

With vacations being ‘an email with a view', working on the weekends, public holidays, and Christmas Eve, founders put in 3-4x more work hours per year than the average corporate employee.

Essentially doing the work of at least 4 corporate employees.

“Ok Juraj, but I work smart, I don’t need to work hard”

Imagine a competitor of yours somewhere in the world who’s exactly like you.
But they operate in ‘Founder mode’ while you’re working on your business in ‘Chill mode’.
They’ll run twice as many experiments per year as you will! How will you win?

“That just makes you a workaholic”

Sort of. Think of startups as a high-performance sport. Would you tell an Olympian chasing a gold medal “chill out you’re training too much!”. Most people wouldn’t.

“Ok, but input ≠ output. You can’t be productive if you work for 12-16 hours a day” [*]

It’s the output of your effort that counts.

The more hours you put in, the faster you learn. The faster you see what works and what doesn’t. The faster you master a skill.

The effort compounds. Since you’re a lot more experienced because of working more, you’re able to get *more* done in a single hour of work over time, not less.

It’s a marathon, but you sprint the entire time

YC preaches ‘eat, sleep, build product and talk to your users’. This is fun for 3 months, but imagine keeping this up for 10 years straight. You have to love the game, otherwise any sensible person would quit.

It’s actually good news: this is how you start

Do you want to start a business, but you don’t have savings?

This is how you get your break: “Work 9-5, spend a couple hours with the family, and 7pm to 2am in the morning is plenty of time to do the damage. […] Everybody has time. Stop watching fucking Lost.”

Just be self-aware and understand what it takes.

[*] the Better Stack team works regular hours

…“Feels like opening iterative pull requests, waiting 10 mins for CI, and deploying a +10/-7 PR is already outdated”

So are programmers already out of a job? Are the best practices for shipping software such as continuous integration and pull request reviews already irrelevant?

Here’s my 2 cents as of March 2025.

Day-to-day impact of LLMs on software engineering

In the last 2 years alone, software engineering changed more drastically than in the prior 20 years.

Starting with the obvious, Claude Sonnet 3.7 is insanely good for 1. debugging errors, and 2. prototyping initial concepts. Stack Overflow & internet forums are dead. Your marketer is no longer hiring $5 fiverr gigs, they create the scripts they need themselves with Claude.

Devin is a great concept, but the error rate is still too high for most tasks. This is where we’re going though — you simply tag your virtual colleague in Slack and wait for them to open a pull request.

Cursor’s CMD+K with Claude Sonnet is the single most important practical change in day-to-day engineering workflows since GPT-3.

If you’re a full-stack engineer and you haven’t incorporated CMD+K into your workflow you will soon become irrelevant. (It’s fascinating that existing IDEs like JetBrains are struggling to keep up!)

Starting a new project? Cursor’s composer mode is useful, too. Although it becomes impractical as you cross 5-10k lines of code and the dependencies become too complex.

Where we’re going

SWE Agents by GitHub will likely shake things up next thanks to their tight integration with GitHub pull requests & having the entire codebase.

New models come with very large context windows. Gemini Flash 2.0’s 1 million context window means that entire small codebases can be now completely included in a single prompt, leading to higher quality answers & insights.

Needs of engineering teams are different to cool demos

Most ‘AI coding’ demos focus on 1. single page visual demos, and are 2. built from scratch by the model. And 3. models make many mistakes, so you need multiple attempts of tweaking your prompt before it does what you need.

Software engineering teams deal, on the other hand, with:

1. numerous internal microservices and many repositories

2. millions of lines of existing code

3. they optimize for not breaking things when adding new features

This is why the Devin experience of simply asking an agent to implement a feature in a complex existing codebase is still just a dream today. And why CMD+K in Cursor remains the key game-changer for existing software engineering teams.

There’s one other notable use-case for engineering teams: chatting with code. Imagine you need to integrate with a poorly documented Go library although you never worked with Go. You can ask Cursor Chat to explain the parts of the code base relevant to you: e.g. ask about what’s the structure of the API payload the service expects. This works exceptionally well.

I think there are many existing workflows still waiting to be disrupted by LLMs: automations for triaging bugs and feature requests, code review assistants, UI copywriting assistants, UI convention checkers, QA testing, and workflows for resolving infrastructure incidents faster, to name a few. We’re working on some of these at Better Stack, so if this sounds like an interesting challenge, join us!

So what makes human engineers relevant today?
Experience + Low error rate.

We still need full-stack engineers with 1. a lot of experience, and 2. low error rate.

Experience is both the soft intuition built from years of building and fixing complex systems as well as hard knowledge of the existing systems.

By “error rate” I mean the guard rails an engineer needs around them to be able to ship production-ready features.

Does your company have an army of manual QA testers? Is every pull request introducing a new feature followed by several hotfixes? Both signify an environment with a high tolerance for errors. Devin is coming for your job soon.

“Full-stack engineer” is the main software engineering role still relevant today. If you perceive yourself as just a “Ruby engineer” or just a “JavaScript engineer” then play with Claude, Cursor & Devin and reconsider.

Thanks for reading! Follow me on Twitter & subscribe below for future posts.

In the short-term, they don’t. The rest of the team subsidizes a new colleague when they’re getting up to speed during onboarding.

So when does “short-term” end and “long-term” begin?

That depends on the introductory compensation.

The introductory compensation is the responsibility of the person joining the company. An experienced engineer with 2 mortgages, 3 kids and a dog has different expectations to a fresh grad.

But the higher the introductory compensation, the higher the expectations. And thus the shorter “time to enough value created”.

We could pay you a million a month, but I’d need you to have a tangible impact on the business on your first day.

The long-term compensation, on the flip-side, is the responsibility of the company. And it’s in the company’s best interest to aggressively increase comp when appropriate.

Imagine you have a colleague who’s simply killing it: the last thing you want is for them to start thinking about leaving because of a different company offering them more $.

At Better Stack, we revisit the compensation of every team member twice a year. That doesn’t mean we automatically increase everyone’s comp every 6 months. It means the company opens up the conversation about your comp with regards to your performance, the company’s overall performance, and the outside market, so that you don’t have to.

It’s in our best interests to aggressively increase compensation when appropriate. In the past, we increased the comp of our colleagues by 50%+ in three consecutive bi-annual reviews — effectively increasing the comp by more than 3.4x within 18 months. But at the same time, for different colleagues, we left the comp unchanged over the same 2-3 consecutive reviews. Because the comp should be proportional to the real value people create.

Large bigtech corporations typically have no clue about who is actually creating a ton of value and who is not. But a nimble startup with technical leadership can recognize it & reward it.

Imagine you’re tasked with deriving an equation for the very first time.

You’re *really* focused on getting it done. You spend hours and hours thinking about how to solve the problem.

Yet, you eventually give up.

Who is your go-to person you ask for help?

Would you prefer to ask 100 first graders to help you or 1 university math student?

I’d go with the university student every single time.

Yet, tech journalists, VCs, job applicants, and even tech recruiters ask me regularly: “How many engineers do you plan on hiring this year?”

This question is fundamentally flawed.

Software engineering is remarkably similar to math in the sense that a really great mathematician can solve a thousand times more difficult math problem than an army of first graders.

9 women won’t give birth to a child in a month.

100 Cessna pilots won’t fly a fighter jet.

So let’s stop thinking of software engineers as a commodity. The best software builders are at least 100x more productive than the mediocre ones.

You might not need a team of 50 engineers after all, you might just need a single really awesome engineer.

So how many engineers are we looking to hire at Better Stack?

Every single great one we can.

Things look, work, and mostly *feel* the same.

This is trivial at first when you’re the only developer but almost impossible later as your engineering, design, and product teams scale and new colleagues join.

The following are my 8 recommendations on improving the design of your next product without adjusting the color of a single pixel.

1. Do not introduce new concepts recklessly

“Sign in here” yet “Can’t log in?”.
“Register here” yet “Sign up with Google”.
Different words, same thing.

Do not ever use synonyms for the core product concepts of your app.

Instead, be uncompromisingly boring: either use “Sign in” and “Sign up”; or “Log in” and “Register” but never the other.

Boring is great.

Otherwise, your users will be left wondering: Is “user” the same thing as “customer” and “profile”? What about “team member”, “colleague”, and “teammate”?

2. Period at the end of tooltips, flash messages, and error messages

It’s often the small things that add up: Do tooltips end with a period or not? If some do and some don’t, just pick one and unify them.

3. Date formats

Have a set of defined date formats you use throughout the app.

4. Consistent page layout

All pages ought to belong to one of a few categories:

• landing page

• listing page

• dashboard page

• authentication page

• form page

If none feels right, think twice if you really need to introduce a new behavior to your interface. All pages of the same type should feel and work the same.

5. Short or long-form English? Informal or formal?

Pick a voice and stick with it. I prefer a conversational professional tone:
an informal, friendly, and honest active voice.

✅ “You’ve successfully updated your profile.”
❌ “Profile was successfully updated.”

6. Copywriting 101

7. Grammar mistakes

Your interface needs to sound native to your customers in the U.S.

Not a native speaker? Rewatch Suits on Netflix. Use Grammarly or leverage “Make the following sound native” Chat-GPT prompts.

8. Write it down

Codify your UI conventions by writing them down and make all new engineers, designers, and product managers read all of them before they start contributing.

Focus on engineers. They’re the ones who typically make or break consistency.

No designers or product managers can design every possible error message of every form, so your engineers will have to improvise whether you make them focus on consistency or not.

Recommended resources

• Don’t make me think.

• Refactoring UI.

• Kevin Hale on How to Build Products Users Love.

…or work with us on the next product at Better Stack.

2. Praise publicly, and criticize privately. Schedule a private 1:1 session. Never criticize someone’s work publicly in front of other colleagues.

3. Check on them first. Is everything fine with them at home? It’s your job to know if they need your support outside of work. Remember, work is just work.

4. Have explicit examples. Be ready to discuss specifics. "Remember last Thursday when you did X? I'd really have preferred you to have done Y in that situation because of Z." Have screenshots ready, links to pull requests or Slack conversations you can reference. Nothing is worse than ambiguity when you're criticizing someone’s work.

5. Cover everything in a single session. Once you're giving someone feedback, don’t be half-hearted. Otherwise, they’ll tell you “You didn’t mention that last time” the next time you talk.

6. Is this a repeated mistake? Acknowledge that. "Remember when we were discussing X last week? We agreed that…”

7. Be firm but kind. Never make it personal. Talk about “the work” they've done, not about the person themselves. Do not ever let your emotions get the better of you.

8. Don’t leave anything unsaid or vague. If you’re not explicit enough, you can’t expect them to understand something you barely implied. Over-communicate rather than under-communicate.

9. Reason from first principles. They might be operating on a different set of beliefs than you, for example, saying “That wasn’t my job”. Be ready to dig deep and get down to first principles if you need to: "Look, how would the business function if everyone was doing this?”

10. The discussion takes as long as it takes. The meeting is scheduled for 30 minutes? Great. Make sure both of you have free time in the calendars afterward. Take your time when speaking, use silence to your advantage. It’s completely fine to breathe in and think for 5-10 seconds about what you want to say before you continue talking. If you discuss the issue in-depth enough, they should be able to acknowledge the problem in the end. If they’re not, delve into it with, “It feels like you’re getting a bit defensive. Do you think what I’m saying is not fair?”

11. Be specific about what you want to happen next. Is this the last warning before you need to let them go? Tell them that.

12. Be ready for extreme reactions. Prepare for every possible outcome of the conversation, regardless of how unlikely. They could laugh, cry, shout at you, or quit on the spot. What would you do if they did that?

Don't worry, you’ll do fine. Radical candor is an integral part of a well-functioning team.

Don’t be this guy:

One such distinction is knowing when to flip the switch between the two engineering approaches.

Here's the scoop: Traditional paths like universities, internships, and work experiences at mega-tech companies usually only teach engineers the ways of "polished and perfect engineering".

1. Don't mess things up!

2. You have to be a team player. Stick to a common code style, whip up unit tests, and give your code some good documentation.

3. Your code should be a breeze to maintain and enhance.

4. Long-winded commits and pull request messages? Bring 'em on.

But if programming is your hobby, chances are, you love playing around with the latest tech. You might find yourself churning out 50-100 line scripts just to test that shiny new API. Or maybe to scrape a list of rentals to snag the perfect apartment... or score the best car deal.

These are throwaway scripts that probably won't see the light of day again.

That's why many self-taught coding enthusiasts often resort to a patchwork approach to make things work... and fast.

There's a common misbelief that the "polished and perfect" style of engineering is always superior. But it's not. Tests for code that's gonna gather dust in some corner are just a waste of your time. Staging environments for pre-release software? That’s ridiculous.

If you're an engineer at an early-stage startup, being able to prototype is a golden skill.

What really sinks startups isn't ugly code. It's the failure to create something people are willing to pay for. That's why being able to prototype quickly, especially in the early stages, is super important.

The crème de la crème of engineers can do both: whip up quick and dirty prototypes, validate their concepts at breakneck speed, and then spin those ideas into top-notch production code.

Engineers often overlook how adding a feature impacts all future changes from that point on. Here's the truth:

Not all features are created equal. Some can literally tank your future productivity.

"All of our competitors have dark mode, let's add it!"

"Let's translate our dashboard into other languages to break into European markets. How hard can it be?"

"Should we launch the responsive web app as a hybrid iOS app as well?"

"Don't forget about Android!"

"Could we convert parts of the web app into an Electron desktop app?"

These suggestions sound harmless until you realize that every single feature added from that point on needs to accommodate all versions of your app.

Light & dark, web & iOS & Android & Electron, English & German... that's 16 versions of the same page right there.

Since it's not practical to check all page versions when adding a new feature, you'll end up with a user experience prone to errors and inconsistency, as well as a significant slowdown in development speed.

So the next time you're about to implement a feature, pause and ask yourself: could this be a work multiplier? Is it really worth it?

P.S. We’re hiring at Better Stack.

Picture that: creating more value in a single day than a big-co engineer creates in 3 months.

The examples are everywhere

Google's initial team had just three people. Apple's crew was only 25-strong when they introduced the Apple II. At the point of its acquisition by Facebook, WhatsApp was serving 600 million users with a team of roughly 50 engineers. Instagram's tale is quite similar, boasting 30 million users with a mere 13 engineers at its $1 billion acquisition. And Basecamp? It began as a humble side project.

Similarly, at Better Stack we had only 3 software engineers writing code back in the day when we crossed $2 million in ARR, coupled with double-digit monthly growth. That's an impressive "revenue per engineer" ratio, if you ask me.

It’s the art of doing less

Imagine a "1x engineer" as a fresh university grad who, given enough time, could build any software from scratch.

Then the "10x engineer" is a seasoned pro with a refined intuition that helps them identify the part of code that should be implemented using an existing open-source library instead of building it from scratch. This doesn't mean they write superior code or type faster. Rather, they understand the immense time-saving potential of plugging in an existing open-source work rather than re-inventing the wheel. The key here, of course, is choosing the right library.

Who’s the mythical “100x engineer” then?

A "100x engineer" has a comprehensive understanding of the product roadmap, business model, competition, and common customer issues as well as a detailed knowledge of the work needed to implement a feature. As a result, they can judge the cost/benefit ratio of a feature better than the product manager. 100x engineers push back on feature definitions. They’re able to cut the right 5% of the feature to simplify its implementation by 100x.

100x engineers aren’t necessarily better at writing code. They better understand the context of everything absent in the task description.

They’re able to take a second to judge the cost/benefit ratio of a feature before they jump into implementation. They can often do so better than the product manager or the CEO.

In the end, it's about everything an engineer doesn't have to do.

Yet, pragmatism and thinking from first principles can be surprisingly rare among engineers. We've all been guilty of over-engineering, premature scaling, recreating existing libraries, and blindly following industry "best practices".

But when you manage to find a few of these 100x engineers, you're in for some real magic.