• their clients don’t understand agile
• don’t know how to scale their code
• struggle to even debug properly

A few years ago, this would sound absurd.

Today, it’s becoming normal.

We spent years worrying about technical debt.

Now we’re entering a world of cognitive debt.

AI is making it incredibly easy to ship code, connect systems, and automate workflows.

But something subtle is happening:

• teams understand less and less of what they’re actually running

Not because they’re not smart —

but because the system grows faster than their ability to reason about it.

What used to be:

· messy architecture

· inefficient infrastructure

Is becoming:

· unclear logic

· hidden dependencies

· bloated (and expensive) systems nobody fully understands

Lately, I’ve been dealing a lot with cluttered and over engineered systems.

Some of it created by humans.

Some of it accelerated by AI.

But in both cases, the result is the same:

• too many layers
• too much noise
• not enough clarity

And that’s where things start breaking.

Because you can optimize technical debt.

But cognitive debt?

That’s when:

· decisions slow down

· debugging becomes guesswork

· scaling becomes fragile

The real work now is not just building faster –

it’s removing the clutter and restoring simplicity.

• Most of what matters is below the surface.

If you’re seeing this too – curious how you’re dealing with it.

The post I just got off a call where someone told me: appeared first on Elad Levy.

My life fit into 2 large suitcases.

My son needed 2 more.

My wife and baby… about 12

But the idea stayed the same.

Growing up, my dad always pushed one thing:

• keep things lean

Less stuff

Less weight

Less dependency

That mindset stayed with me.

I apply it the same way when building companies:

fewer moving parts

smaller, stronger teams

infrastructure that earns its cost

systems that are easy to operate

It’s not just about efficiency.

It’s about survival.

Staying lean is what allows you to:

go through tough periods

adapt faster

make decisions without friction

I’ve seen companies struggle not because they lacked resources —

but because they had too much of the wrong things.

More tools

More people

More complexity

Lean isn’t about having less.

It’s about needing less.

If things feel heavier, slower, or more expensive than they should be —

they probably are.

If you’re trying to simplify your platform, team, or infrastructure,

you can reach me here: https://lnkd.in/dBZ8xjEa

The post After 20 years in Argentina, we moved to the US. appeared first on Elad Levy.

In Part 1, I wrote about infrastructure waste.

In Part 2, subscription and tool sprawl.

In Part 3, teams and throughput.

(You can find the full series on my profile.)

Now the deepest layer: architecture.

Most companies don’t realize that architecture decisions are financial decisions.

Every shortcut compounds.

Monoliths that should have been modular.

Databases overloaded with business logic.

Over-engineered microservices with no traffic justification.

Legacy components nobody wants to touch.

Vendor lock-in that quietly increases switching cost.

Technical debt isn’t just a developer inconvenience.

It’s a margin multiplier.

Bad architecture increases:

• Infrastructure cost
• Development time
• Bug frequency
• Hiring difficulty
• Migration risk

And the longer it sits, the more expensive it becomes to fix.

Sometimes the highest-leverage move isn’t adding features.

It’s simplifying what already exists.

I’ve seen cases where refactoring a heavy stack reduced compute usage significantly — not by adding more hardware, but by removing structural inefficiency.

Architecture isn’t about elegance.

It’s about sustainable leverage.

Before adding new services or features, ask:

Is our architecture compounding cost — or compounding speed?

Hidden margin often hides in structural design.

If you’d like to review your architecture through this lens, you can book time here:

https://lnkd.in/dBZ8xjEa

The post Part 4 of The Hidden Margin Framework: Architecture & Technical Debt appeared first on Elad Levy.

In one company, we were deploying to production almost every day.

Sometimes twice a day.

On paper, it looked impressive.

Velocity was high.

Features moved fast.

Roadmap items closed quickly.

But instability increased.

Bugs increased.

Support load increased.

And eventually, churn increased.

At another company, we ran disciplined 2-week sprints.

Clear scope.

Strict definition of done.

Integrated testing.

Controlled releases.

We shipped slower.

But stability was exceptional.

And retention was stronger.

In 2026, with AI accelerating development, it’s easier than ever to generate and ship code quickly.

But customer trust doesn’t scale with velocity.

It scales with reliability.

Instability is a silent tax on growth.

Every production bug is a small withdrawal from customer trust.

Speed matters.

But sustainable speed matters more.

Curious – how often do you deploy to production, and how do you protect stability?

The post Shipping Faster Isn’t Always Winning appeared first on Elad Levy.

Last week I wrote about infrastructure waste.

This week: subscriptions.

When I start working with a company, I don’t begin with architecture diagrams.

I ask the CFO or accounting for the last 12 months of company credit card subscriptions.

That alone usually reveals where hidden margin is hiding.

What I typically find:

• Datadog (or similar) full APM + logs + RUM for a product that only needs basic uptime monitoring
• Google Workspace Enterprise for the entire company when Business Standard would be more than enough
• Enterprise GitHub / GitLab seats for inactive users or teams that qualify for free tiers
• Premium CI minutes wasted on inefficient pipelines
• Multi-region storage replication nobody can justify
• Separate BI platforms solving the same problem
• Paid staging/testing environments running 24/7 with near-zero usage
• Enterprise CDN tiers for modest traffic volumes

Individually, none of these look dramatic.

Collectively, they quietly add 5–15% to annual burn.

No migration required.

No rewrite required.

No layoffs required.

Just visibility and discipline.

Most companies review revenue weekly.

Very few review subscriptions with the same rigor.

When was the last time you looked at your company credit card subscriptions and asked whether they still make sense for the size and actual needs of the business?

If you’d like to review your tool stack through this lens, you can book time here:

https://lnkd.in/dBZ8xjEa

The post Part 2 of The Hidden Margin Framework: Tool Sprawl appeared first on Elad Levy.

I think that framing is wrong.

SaaS isn’t dead.

Undisciplined SaaS is.

For years, companies were rewarded for:

• Shipping more features
• Growing headcount and cost ahead of revenue
• Optimizing for narratives instead of margins
• Treating cloud spend as a future problem

That worked in a world of cheap capital.

That world changed.

What’s being re-rated now isn’t software — it’s operating models.

In most companies I see, the real issues aren’t:

• Talent
• Tools
• Product ideas

They’re:

• Over-engineered systems
• Architecture disconnected from business reality
• Infrastructure costs with no clear owner
• Teams optimized for speed, not sustainability

AI accelerates this shift, it doesn’t cause it.

When features become easy to generate, execution discipline becomes the moat.

The companies that will quietly win from here are the boring ones:

• Fewer moving parts
• Clear ownership
• Intentional cost
• Technology that earns its keep

If your platform is live and things feel heavier, slower, or more expensive than they should — that’s usually fixable without a rebuild.

Most of the work is subtraction.

The post I saw headline lately claiming “the era of pure SaaS is dead”, often pointing to valuation drops in public companies lik… appeared first on Elad Levy.

I also share the same feeling of VCs losing their core values and am personally frustrated with the fact that many amazing founders and great companies struggle to raise funds compared to “storytellers”.

And yes, like Jonny said I do angel investments as those actually help me connect directly with the founder as opposed to being a passive LP

The post I normally do not repost on LinkedIn but this time I wish to make an exception. appeared first on Elad Levy.

Behind every startup story — win or lose — is a team that gave it everything.

After my Playtika exit, I had that team, that dream — and we still failed. This is a story of a company that I tried building BEFORE DIVE (my current company) and it didn’t work out.

I saw an opportunity: game studios were struggling with backend infrastructure. So I built a strong team and set out to create a backend-as-a-service platform.

Here’s the catch: when a CTO becomes a founder, the temptation is to focus too much on tech. That’s exactly what we did.

We made one big, dangerous decision: go 100% bootstrapped.

On paper it sounded smart — raise later, keep more equity.

In reality, it nearly guaranteed failure.

We had world-class people and world-class tech — but we lacked one critical thing: a real product leader. After more than a year of building, we burned through our cash. We tried to pivot, expanded the team, and only burned more. In the end, we had to shut the company down.

What I learned (the hard way):

• Choose your partners wisely.
• Traction is priority #1. Always.
• Keep things lean — stretch every dollar.
• Know your audience: B2C and B2B are completely different games.
• Even at the very beginning, having a few angel investors matters — not just for capital, but for validation, credibility, and momentum when raising the next round.

That failure was painful — but it was also tuition. Today, every decision I make as a CTO and founder is shaped by those lessons, and it’s how I help CEOs avoid the same mistakes.

Share your story with me here: https://lnkd.in/dBZ8xjEa

And even more important. As a result of this failure I’ve started Dive – bootstrapped from 0 to processing data every month for 100 million active users. So never give up

#Startups #Leadership #Entrepreneurship #FractionalCTO #Founders

Here’s the team that gave it everything. The dream ended too soon — but the lessons live on.

The post From $100M CTO Exit to a complete failure. appeared first on Elad Levy.

I keep hearing this line in consulting calls:

“We NEED to migrate to microservices.”

Here’s the truth: you don’t “need” anything.

• For non-tech folks:

A monolith = one big house where everything is under one roof (simple, fast).

Microservices = an apartment building where every unit has its own kitchen, plumbing, and wiring (flexible, but a nightmare to maintain early on).

Which one do you build first if you’re just starting out with little money?

Why Monoliths Win Early On

• Faster to build & ship
• Less overhead for small teams
• Customers don’t care about your architecture — only the product

Years ago, I learned this lesson the hard way.

I built a beautiful, scalable system… but the market didn’t want it. After a year, we had to shut it down.

• Takeaway: prioritize revenue, not architecture.

Monolith vs Microservices (Quick Breakdown)

Monolith = speed + simplicity early on, pain later.

Microservices = complexity upfront, payoff only at scale.

• Start simple. Scale later.

Bottom line:

Microservices won’t save your startup. Revenue will.

Are you team Monolith or team Microservices? Drop your answer below

Also, if you wish to talk about architecture, feel free to book a slot here: https://lnkd.in/ddk578gp

The post Over-Engineering Will Kill Your Startup (Microservices) appeared first on Elad Levy.

The post Great place to get advice for founders. appeared first on Elad Levy.