40 people. 3 hours. One topic: how to actually use AI to ship faster.

Not ChatGPT for answering questions.

Not copy-pasting code from a browser tab.

Real AI-assisted development. Terminal-level. Codebase-aware. Production-ready.

We showed two real products built with this approach:

SaaS product A: data analytics platform. took 4 people 18 months the old way. Rebuilt by 1 person in 9 months with AI.

SaaS product B: data monitoring platform. Design to production in 1 month. One developer. Claude Code.

Here’s what surprised me most on the day.

Some of the developers in the room had never used AI in their workflow. At all.

It’s 2026.

I’m not judging, I’m alarmed.

Because while those developers are writing code line by line, somewhere else a team of 2 is shipping what their team of 15 used to ship.

This is exactly what I keep seeing in every company I audit:

Bloated R&D teams. Infrastructure costs 4–6x what they should be. Delivery speed that hasn’t improved in years.

It’s not a talent problem.

It’s not a budget problem.

It’s a tools problem. And it’s fixable.

The developers who came to that training left with a different way of working. Some of them will 3x their output this quarter alone.

The ones who didn’t come, or who resist, will be the first line items reviewed when a founder finally looks at the headcount.

AI doesn’t replace good developers.

But a good developer using AI will replace one who isn’t.

• Is your team using AI the way they should be?

If not, let’s talk: https://lnkd.in/dBZ8xjEa

The post Last week we ran an AI training day for developers. appeared first on Elad Levy.

A CEO called me a few weeks ago.

His SaaS platform was a mess. He needed help sorting it out and preparing for scale.

Normal enough.

Then I asked about the team.

50 people in R&D.

That number alone told me most of what I needed to know.

In 2026, a SaaS platform with a few integrations shouldn’t need 50 engineers. I personally launch full products with 1 senior developer. Maybe 1.5 on a complex day.

Then he told me his monthly infrastructure cost.

My gut said he was paying roughly 6x what he should.

We had a clear path. Month one savings alone would have covered my fee several times over. But my rate felt too high and we couldn’t reach an agreement.

Fair enough. Not every engagement works out.

I was curious what he decided to do instead.

So I asked.

He hired an AI dev team.

He tried to solve an AI-era problem with a pre-AI solution.

That’s the irony.

He heard “AI” and thought it meant adding a new team. A new layer. More headcount wrapped in a trendy label.

AI doesn’t add people. It replaces the need for them.

The companies winning right now aren’t the ones hiring AI teams.

“How few people do we actually need to build this?”

That’s the question worth asking.

Adding headcount to solve a complexity problem is like pouring water on a grease fire.

It feels logical. It makes things worse.

The old playbook is dead.

Most people just haven’t buried it yet.

• Have you seen this pattern in your company or industry?

If your tech feels heavier than it should, let’s talk: https://lnkd.in/dBZ8xjEa

The post AI-Era Problem, Pre-AI Solution appeared first on Elad Levy.

Over the last year I ran technology audits across several companies.

When I got to the people layer, the numbers were hard to ignore:

(downsizing/rightsizing)

Company A: 20 engineers → 5

Company B: 17 engineers → 2

Company C: 17 engineers → 5

Same output. In some cases, better output.

Fewer handoffs. Fewer meetings. Clearer ownership.

This isn’t a theory. It’s what’s already happening.

Google is cutting. Oracle is cutting. Meta already did.

The difference is that large companies have data, benchmarks, and boards pushing them to act.

Smaller companies have none of that pressure — so the bloat stays hidden longer.

It’s 2026. AI doesn’t replace developers.

But 2 senior developers with the right tools and a clear architecture can now do what 15 used to do.

The question isn’t whether your team is too big.

The question is whether you’ve actually looked.

Most founders haven’t.

Not because they don’t care — but because nobody handed them a framework to do it.

• When did you last look at your team structure with fresh eyes?

If you’re not sure where to start, I do a free 30-minute sanity check: https://lnkd.in/dBZ8xjEa

The post Outsourcing and staffing as we knew them are dead. appeared first on Elad Levy.

Still running. Still processing real transactions. Real money.

Nobody on the current team fully understands how it works.

Nobody knows why it was built the way it was.

And nobody has ever asked whether it still needs to exist.

But it costs them. Every single day.

In complexity.

In risk.

In the 4AM calls when it crashes and only one person (somewhere in the world) knows how to restart it.

Here’s the thing:

The people who built it made the right decision.

It was 2002. The tools available then made this architecture completely logical. Smart engineers solved a real problem elegantly (the developer actually wrote his own database connection pooling from scratch in C++ — in 2002. Respect. Also: why is it still here?)

But the world moved on.

The tools changed.

The problem got solved a dozen better ways.

And nobody ever stopped to ask: “does this still need to exist?”

This is how technical debt actually works.

It’s not built from bad decisions.

It’s built from good decisions that were never revisited.

Every company I walk into has at least one of these.

A system, a tool, a process – that made perfect sense once.

That now quietly drains money, slows teams down, and keeps one person up at night.

The most expensive things in your business aren’t the broken ones.

They’re the ones that still work – but nobody questions anymore.

When did you last audit a decision you made 3+ years ago?

If you’re nerdy enough, drop a comment and I’ll send you the full technical breakdown.

Also, If this sounds familiar, I do a free 30-minute sanity check: https://lnkd.in/dBZ8xjEa

The post I audited a platform last week. appeared first on Elad Levy.

In Part 1, I wrote about infrastructure waste.

In Part 2, I covered subscription and tool sprawl.

(You can find both on my profile.)

Now the harder layer: teams.

AI has dramatically increased developer leverage.

Which makes one thing very clear:

Coordination cost now scales faster than output.

Most companies don’t have a talent problem.

They have a throughput problem.

Too many parallel initiatives.

Too much shared ownership.

Too many meetings.

Too much context switching.

Large teams optimized for coordination rarely outperform small senior teams optimized for execution.

In today’s environment, two strong developers leveraging AI can deliver what once required much larger groups.

But only if:

• Ownership is clear
• Scope is tight
• Work is measured
• Output is reviewed against estimates

The goal isn’t ritual.

It’s predictable delivery.

Lean doesn’t mean under-resourced.

It means high leverage.

Before asking, “Do we need more engineers?”

Ask, “Are we structured for speed and accountability?”

Hidden margin often hides in throughput inefficiency.

Curious – how large is your dev team, and how is it organized?

If you want to review your delivery model through this lens, you can book time here:

https://lnkd.in/dBZ8xjEa

The post Part 3 of The Hidden Margin Framework: Teams & Throughput appeared first on Elad Levy.

• How many developers do you really need to scale?

Most founders assume the answer is “a big team.”

I’ve seen the opposite play out.

• The 2-Developer Principle

You don’t need 10 engineers to build scalable systems.

You need 2 senior developers + AI:

•One backend (Go)

•One frontend/mobile (React / React Native)

With the right architecture and guidance, that’s enough to:

• Ship fast
• Keep stability
• Scale to thousands (even millions) of users

• Why it works:

•Small teams move faster than big ones

•Experienced devs + the right stack means fewer rewrites

•AI handles the repetitive work so they focus on solving real problems

The result? Lower burn, faster delivery, and fewer “rebuild everything” disasters.

Hiring more people is easy.

Building with focus and discipline is hard.

That’s why I believe in the 2-Developer Principle:

Most companies need clarity before they need headcount.

I have personally always achieved more and faster when leading a small team and when companies have bloated teams things actually slow down. They don’t get it faster because too many cooks in the kitchen is never a good idea.

What is your ideal number for a dev team ?

The post My secret to dev speed ? appeared first on Elad Levy.

Hiring the right developer is harder than shipping code.

I thought I had found the perfect hire—until the second sprint revealed the truth.

When companies modernize their tech stack, sometimes the hardest part isn’t the code.

It’s the people.

Recently, I hired a developer who seemed perfect:

• Strong experience
• Solved a bug quickly in the interview
• Comfortable with AI tools

But then reality hit…

• First sprint: slow (but expected).
• Second sprint: weak code quality.
• Slack activity was spotty.
• When I asked for a quick call, the answer was: “We need to schedule it.”

Something was off.

After speaking with peers, I learned a new term: “over-employed.”

Developers stacking multiple jobs, juggling them with AI.

On paper, it sounds clever.

In practice, it kills commitment, quality, and culture.

• Great employees grind.
• They push back, they argue, they take ownership.
• They know reputation > quick money.

Lessons I’ve learned from hiring (and firing) hundreds of devs:

• Filter fast—bad hires cost energy.
• Know task timelines—if a 2-hour job takes 3 days, something’s wrong.
• Surprise calls reveal commitment. (Even on weekends !!!!)
• A great hire feels like a missing puzzle piece—they fit fast.
• Motivation matters: hungry builders > money-chasers.

And a quick note if you’re a young developer reading this: stacking jobs may give you short-term cash, but it won’t build a long-term career. The fastest way to stand out? Show urgency, keep learning, and be the teammate people can trust.

Hiring right is harder than coding.

• What are your best tips for spotting great talent?

The post I just got scammed $10,000 by a developer working 5 jobs at the same time. appeared first on Elad Levy.

I have had in my previous company technical developers that werr asked to be team leaders. When you let a talented developer burn his precious time on calls and babysitting instead of writing code then the team and company productivity is hurt. So I took the heat as a cto to burn my time on nonsense calls and sales and marketing meetings. This approach is better because the previous one will result in your best people quitting on you.

Talented developers are getting amazing offers every day and if they are not happy they will quit so the lesson here is:

• when you hire someone for a role just let him work at the role you hired him for and he will be the happiest employee on earth. It’s as simple as that

The post Excelling post. appeared first on Elad Levy.

Here’s the typical early-stage startup flow:

1. Founder has an idea

2. Raises pre-seed

3. Hires a product manager to spec it out

4. Brings in a CTO or dev agency to build the MVP

5. Launch → test → scale (or pivot)

Let’s zoom in on step 4. Traditionally, the CTO or dev lead reads a long spec doc and starts crafting the system architecture.

Now? I gave that same spec to AI.

It returned a full system design in 20 minutes: microservices layout, tech stack, cloud setup, even DB entity suggestions.

It was honestly super impressive—a task that normally takes weeks.

But when I looked deeper, things fell apart:

Misaligned with real user journeys

Bad assumptions about scaling paths

Poor judgment in tech stack trade-offs

Here’s the truth:

AI can’t:

• Hire or manage engineers
• Catch business-specific edge cases
• Make strategic technical decisions based on experience
• AI can:
• Speed up research
• Suggest configs or alternatives
• Help teams move faster—but not smarter

You still need a CTO.

Even a fractional one. AI helps—but doesn’t replace—leadership, context, and judgment.

If you still need a CTO, please book a meeting with me here: https://lnkd.in/ddk578gp

#AI #Startups #CTO #TechLeadership #ArtificialIntelligence

#FractionalCTO #StartupLife #SystemArchitecture

#ProductDevelopment #MVPLaunch

The post Can ChatGPT Replace Your CTO? appeared first on Elad Levy.

Ticketmaster servers crashed after 3.5 billion hits for Taylor Swift tickets.

The Ticketmaster meltdown during the Taylor Swift “Eras Tour” presale wasn’t just bad luck – it was a harsh lesson in failing to modernize old, creaky tech. Here’s how companies can avoid their own “Swiftie” crisis:

Map the Mess:

Figure out every old, slow part of your tech system (databases, payment, login, etc.).

Estimate how much effort it’ll take to fix each one.

Example: Ticketmaster realizing their login system from 2005 couldn’t handle millions of fans at once.

Show Me the Money (Value):

Attach a real dollar value or business impact to fixing each broken part.

Prioritize fixes that bring the biggest return (more sales, happier customers).

Example: A new, robust queuing system prevents crashes, meaning millions more tickets sold and no angry headlines.

Get Everyone on Board:

Bring in all the key players: tech, marketing, sales, execs.

Agree on the upgrade plan together, balancing tech effort with business needs.

Example: All Ticketmaster teams agreeing that scalable infrastructure was vital for brand reputation, not just a “dev thing.”

Know Your Starting Point:

Measure how well your current system performs before you change anything (e.g., users per minute, transaction speed, error rates).

These are your “before” pictures to compare against.

Example: Ticketmaster would know their system’s max capacity for simultaneous users on a typical day vs. the anticipated Swiftie surge.

Iterate Safely (No Big Bangs!):

Dedicated Focus: Have at least one person always working on the upgrade.

Test, Test, Test: Like a concert rehearsal, stress test new systems before launch.

Build in Parallel: Don’t destroy the old system while building the new one. Run both side-by-side.

Backward Compatible: New parts must work with old parts.

Phased Rollout: Start small—send only a tiny bit of traffic to the new system at first.

Monitor Constantly: Watch your performance metrics like a hawk, comparing new vs. old.

Easy Rollback: Always have an “undo” button to switch back to the old system if things go south.

Scale Slowly: Gradually increase traffic only after proving stability. Don’t go from 10% to 100% instantly!

Example: Ticketmaster wishing they had tested their new queue system with a smaller artist first, gradually increasing load instead of going straight to Taylor Swift.

Remember: A system working fine with a few users can totally crumble with a million. Gradual, monitored changes are key to avoiding your own “Eras Tour” tech disaster.

If you are interested in discussing hiring a fractional CTO, please book a meeting with me: https://lnkd.in/dBZ8xjEa

#innovation #technology

The post Ticketmaster Crashed Because of Legacy Software — How to Start Modernizing Before It’s Too Late” appeared first on Elad Levy.