September 2025 - Ivan Turkovic

The Vibe Code Tax

Momentum is the oxygen of startups. Lose it, and you suffocate. Getting it back is harder than creating it in the first place.

Here’s the paradox founders hit early:

Move too slowly searching for the “perfect” technical setup, and you’re dead before you start.
Move too fast with vibe-coded foundations, and you’re dead later in a louder, more painful way.

Both paths kill. They just work on different timelines.

Death by Hesitation

Friendster is a perfect example of death by hesitation. They had the idea years before Facebook. They had users. They had momentum.

But their tech couldn’t scale, and instead of fixing it fast, they stalled. Users defected. Momentum bled out. By the time they moved, Facebook and MySpace had already eaten their lunch.

That’s hesitation tax: waiting, tinkering, second-guessing while the world moves on.

Death by Vibe Coding

On the flip side, you get the vibe-coded death spiral.

Take Theranos. It wasn’t just fraud, it was vibe coding at scale. Demos that weren’t real. A prototype paraded as a product. By the time the truth surfaced, they’d burned through billions and a decade of time.

Or look at Quibi. They raced to market with duct-taped assumptions the whole business was a vibe-coded bet that people wanted “TV, but shorter.” $1.75 billion later, they discovered the foundation was wrong.

That’s the danger of mistaking motion for progress.

The Right Way to Use Vibe Coding

Airbnb is the counterexample. Their first site was duct tape. Payments were hacked together. Listings were scraped. It was vibe code but they treated it as a proof of concept, not a finished product.

The moment they proved demand (“people really will rent air mattresses from strangers”), they rebuilt. They didn’t cling to the prototype. They moved fast, validated, then leveled up.

That’s the correct use: vibe code as validation, not as production.

The Hidden Tax

The vibe code tax is brutal because it’s invisible at first. It’s not just money.

Lost time → The 6–12 months you’ll spend duct-taping something that later has to be rebuilt from scratch.
Lost customers → Early adopters churn when they realize your product is held together with gum and string. Most won’t return.
Lost momentum → Investors don’t like hearing “we’re rebuilding.” Momentum is a story you only get to tell once.

And you don’t get to dodge this tax. You either pay it early (by finding a technical co-founder or paying real engineers), or you pay it later (through rebuilds, lost customers, and wasted months).

How to Stay Alive

Be honest. Call your vibe-coded MVP a prototype. Never pitch it as “production-ready.”
Set a timer. Airbnb didn’t stay in duct tape land for years. They validated and moved on. You should too.
Budget for the rebuild. If you don’t have a co-founder, assume you’ll need to pay engineers once the prototype proves itself.
Go small but real. One feature built right is more valuable than ten features that crumble.

Final Word

The startup graveyard is full of companies that either waited too long or shipped too fast without a foundation. Friendster hesitated. Theranos faked it. Quibi mistook hype for traction.

Airbnb survived because they paid the vibe code tax on their terms. They used duct tape to test, then rebuilt before the cracks became fatal.

That’s the playbook.

Because no matter what the vibe code tax always comes due.

Is AI Slowing Everyone Down?

Over the past year, we’ve all witnessed an AI gold rush. Companies of every size are racing to “adopt AI” before their competitors do, layering chatbots, content tools, and automation into their workflows. But here’s the uncomfortable question: is all of this actually making us more productive, or is AI quietly slowing us down?

A new term from Harvard Business Review “workslop” captures what many of us are starting to see. It refers to the flood of low-quality, AI-generated work products: memos, reports, slide decks, emails, even code snippets. The kind of content that looks polished at first glance, but ultimately adds little value. Instead of clarity, we’re drowning in noise.

The Illusion of Productivity

AI outputs are fast, but speed doesn’t always equal progress. Generative AI makes it effortless to produce content, but that ease has created a different problem: oversupply. We’re seeing more documents, more proposals, more meeting summaries but much of it lacks originality or critical thought.

When employees start using AI as a crutch instead of a tool, the result is extra layers of text that someone else has to review, fix, or ignore. What feels like efficiency often leads to more time spent filtering through workslop. The productivity gains AI promises on paper are, in practice, canceled out by the overhead of sorting the useful from the useless.

Numbers Don’t Lie

The MIT Media Lab recently published a sobering study on AI adoption. After surveying 350 employees, analyzing 300 public AI deployments, and interviewing 150 executives, the conclusion was blunt:

Fewer than 1 in 10 AI pilot projects generated meaningful revenue.
95% of organizations reported zero return on their AI investments.

The financial markets noticed. AI stocks dipped after the report landed, signaling that investors are beginning to question whether this hype cycle can sustain itself without real business impact.

Why This Happens

The root cause isn’t AI itself it’s how organizations are deploying it. Instead of rethinking workflows and aligning AI with core business goals, many companies are plugging AI in like a patch. “We need to use AI somewhere, anywhere.” The result is shallow implementations that create surface-level outputs without driving real outcomes.

It’s the same mistake businesses made during earlier tech booms. Tools get adopted because of fear of missing out, not because of a well-defined strategy. And when adoption is guided by FOMO, the outcome is predictable: lots of activity, little progress.

Where AI Can Deliver

Despite the noise, I don’t think AI is doomed to be a corporate distraction. The key is focus. AI shines when it’s applied to specific, high-leverage problems:

Automating repetitive, low-value tasks (think: data entry, scheduling, or document classification).
Enhancing decision-making with real-time insights from complex data.
Accelerating specialized workflows in domains like coding, design, or customer support if humans remain in the loop.

The companies that will win with AI aren’t the ones pumping out endless AI-generated documents. They’re the ones rethinking their processes from the ground up and asking: Where can AI free humans to do what they do best?

The Human Factor

We have to remember: AI isn’t a replacement for judgment, creativity, or strategy. It’s a tool one that can amplify our abilities if used thoughtfully. But when used carelessly, it becomes a distraction that actually slows us down.

The real productivity gains won’t come from delegating everything to AI. They’ll come from combining human strengths with AI’s capacity, cutting through the noise, and resisting the temptation to let machines do our thinking for us.

Final thought: Right now, most companies are stuck in the “workslop” phase of AI adoption. They’re generating more content than ever but producing less clarity and value. The next phase will belong to organizations that stop chasing hype and start asking harder questions: What problem are we actually solving? Where does AI fit into that solution?

Until then, we should be honest with ourselves: AI isn’t always speeding us up. Sometimes, it’s slowing everyone down.

20+ Years as a CTO: Lessons I Learned the Hard Way

Being a CTO isn’t what it looks like from the outside. There are no capes, no magic formulas, and certainly no shortcuts. After more than two decades leading engineering teams, shipping products, and navigating the chaos of startups and scale-ups, I’ve realized that the real challenges and the real lessons aren’t technical. They’re human, strategic, and sometimes painfully simple.

Here are the lessons that stuck with me, the ones I wish someone had told me when I started.

Clarity beats speed every time

Early in my career, I thought speed meant writing more code, faster. I would push engineers to “ship now,” measure velocity in lines of code or story points, and celebrate sprint completions.

I was wrong.

The real speed comes from clarity. Knowing exactly what problem you’re solving, who it matters to, and why it matters that’s what lets a team move fast. I’ve seen brilliant engineers grind for weeks only to realize they built the wrong thing. Fewer pivots, fewer surprises, and focus make a team truly fast.

Engineers want to care, they just need context

One of the most frustrating things I’ve witnessed is engineers shrugging at product decisions. “They just don’t care,” I thought. Until I realized: they do care. They want to make an impact. But when they don’t have context, the customer pain, the market reality, the business constraints,they can’t make informed decisions.

Once I started sharing the “why,” not just the “what,” engagement skyrocketed. A well-informed team is a motivated team.

Vision is a tactical tool, not a slogan

I’ve been guilty of writing vision statements that sounded great on slides but did nothing in practice. The turning point came when I started treating vision as a tactical tool.

Vision guides decisions in real time: Should we invest in this feature? Should we rewrite this component? When the team knows the north star, debates become productive, not paralyzing.

Great engineers are problem solvers first

I’ve worked with engineers who could write elegant code in their sleep, but struggle when the problem itself is unclear. The best engineers are not just builders, they’re problem solvers.

My role as a CTO became ensuring the problem was well-understood, then stepping back. The magic happens when talent meets clarity.

Bad culture whispers, it doesn’t shout

I’ve learned to pay attention to the quiet. The subtle signs: meetings where no one speaks up, decisions made by guesswork, unspoken assumptions. These moments reveal more about culture than any HR survey ever could.

Great culture doesn’t need fanfare. Bad culture hides in silence and it spreads faster than you think.

Done is when the user wins

Early on, “done” meant shipped. A feature went live, the ticket closed, everyone celebrated. But shipping doesn’t equal solving.

Now, “done” only counts when the user’s problem is solved. I’ve had to unteach teams from thinking in terms of output and retrain them to think in terms of impact. It’s subtle, but transformative.

Teams don’t magically become product-driven

I used to blame teams for not thinking like product people. Then I realized the missing piece was me. Leadership must act like product thinking matters. Decisions, recognition, discussions, they all reinforce the mindset. Teams reflect the leadership’s priorities.

Product debt kills momentum faster than tech debt

I’ve chased the holy grail of perfect code only to watch teams get bogged down in building the wrong features. Clean architecture doesn’t save a product if no one wants it. Understanding the problem is far more important than obsessing over elegance.

Focus is a leadership decision

I once ran a team drowning in priorities. Tools, frameworks, and fancy prioritization systems didn’t help. The missing ingredient was leadership. Saying “no” to the wrong things, protecting focus, and consistently communicating what matters that’s what accelerates teams.

Requirements are not the problem

If engineers are stuck waiting for “better requirements,” don’t introduce another process. Lead differently. Engage with your team, clarify expectations, remove ambiguity, and give feedback in real time. Requirements are never the bottleneck leadership is.

The hard-earned truth

After twenty years, I’ve realized technology is the easy part. Leadership is where the real work and the real leverage lies.

Clarity, context, vision, problem-solving, culture, focus these aren’t buzzwords. They are the forces that determine whether a team thrives or stalls.

I’ve seen brilliant teams fail, and ordinary teams excel, all because of the way leadership showed up. And that’s the lesson I carry with me every day: if you want speed, impact, and results, start with the leadership that creates the conditions for them.

Why AI won’t solve these problems

With all the excitement around AI today, it’s tempting to think that tools can fix everything. Need better requirements? There’s AI. Struggling with design decisions? AI can suggest options. Want faster development? AI can generate code.

Here’s the hard truth I’ve learned: none of these tools solve the real problems. AI can assist, accelerate, and automate but it cannot provide clarity, set vision, or foster a healthy culture. It doesn’t understand your users, your market, or your team’s dynamics. It can’t decide what’s important, or make trade-offs when priorities conflict. Those are human responsibilities, and they fall squarely on leadership.

I’ve seen teams put too much faith in AI as a silver bullet, only to discover that the fundamental challenges alignment, focus, problem definition, and decision-making still exist. AI is powerful, but it’s a force multiplier, not a replacement. Without strong leadership, even the most advanced AI cannot prevent teams from building the wrong thing beautifully, or from stagnating in a quiet, passive culture.

Ultimately, AI is a tool. Leadership is the strategy. And experience with decades of trial, error, and hard-won insight is what turns potential into real results.

Cocoa, Chocolate, and Why AI Still Can’t Discover

Imagine standing in front of a freshly picked cocoa pod. You break it open, and inside you find a pale, sticky pulp with bitter seeds. Nothing looks edible, nothing smells particularly appetizing. By every reasonable measure, this is a dead end.

Yet humanity somehow didn’t stop there. Someone, centuries ago, kept experimenting, steps that made no sense at the time:

Picking out the seeds and letting them ferment until they grew mold.
Washing and drying them for days, though still inedible.
Roasting them into something crunchy, still bitter and strange.
Grinding them into powder, which tasted worse.
Finally, blending that bitterness with sugar and milk, turning waste into one of the most beloved foods in human history: chocolate.

No algorithm would have told you to keep going after the first dozen failures. There was no logical stopping point, only curiosity, persistence, and maybe a bit of luck. The discovery of cocoa as food wasn’t the result of optimization, it was serendipity.

Why This Matters for AI

AI today is powerful at recombining, predicting, and optimizing. It can remix what already exists, generate new connections from vast data, and accelerate discoveries we’re already aiming toward. But there’s a limit: AI doesn’t (yet) explore dead ends with stubborn curiosity. It doesn’t waste time on paths that appear pointless. It doesn’t ferment bitter seeds and wait for mold to form, just to see if maybe, somehow, there’s something new hidden inside.

Human discovery has always been messy, nonlinear, and often illogical. The journey from cocoa pod to chocolate shows that sometimes the only way to find the extraordinary is to persist through the ridiculous.

The Future of Discovery

If we want AI to go beyond optimization and into true discovery, it will need to embrace the irrational side of exploration, the willingness to try, fail, and continue without clear reasons. Until then, AI remains a tool for extending human knowledge, not replacing the strange, stubborn spark that drives us to turn bitter seeds into sweetness.

Because the truth is: chocolate exists not because it was obvious, but because someone refused to stop at “nothing edible.”

This path makes no sense. At every step the signal says stop. No data suggests you should continue. No optimization algorithm rewards the action. Yet someone did. And that’s how one of the world’s favorite foods was discovered.

This is the gap between human discovery and AI today.

AI can optimize, remix, predict. It can explore a search space, but only one that’s already defined. It can’t decide to push through meaningless, irrational steps where there’s no reason to keep going. It won’t follow a path that looks like failure after failure. It won’t persist in directions that appear to lead nowhere.

But that’s exactly how discovery often works.

Cocoa to chocolate wasn’t about efficiency. It was curiosity, stubbornness, and luck. The same applies to penicillin, vulcanized rubber, even electricity. Breakthroughs happen because someone ignored the “rational” stopping point.

AI is far from that. Right now, it’s bounded by what already exists. It doesn’t yet invent entirely new domains the way humans stumble into them.

The lesson? Discovery is still deeply human. And the future of AI will depend not just on making it smarter, but on making it willing to walk blind paths where no reward signal exists until something unexpected emerges.

Because sometimes, you need to go through moldy seeds and bitterness to find chocolate.

When to Hire Real Engineers Instead of Freelancers for Your MVP

Building a startup is a race against time. Every day you wait to ship your idea is a day your competitors could gain an edge. That’s why many founders start with freelancers or “vibe coding” to launch their MVP (Minimum Viable Product) quickly. But this fast-track approach comes with hidden risks. There comes a point when hiring real engineers is no longer optional, it’s critical for your startup’s survival.

In this post, we’ll explore when it’s the right time to transition from freelancers to full-time engineers, and why vibe coding with low-cost freelancers can be dangerous for your MVP.

Why Start With Freelancers?

Freelancers are often the first choice for early-stage founders. Here’s why:

Speed: Freelancers can help you quickly prototype your idea.
Lower Cost: You pay for work done, without the overhead of full-time salaries or benefits.
Flexibility: You can scale the workforce up or down depending on the project stage.

Freelancers are perfect for validating your idea, testing market demand, or building proof-of-concept features. However, relying on freelancers too long can create technical debt and slow your growth when your product starts attracting real users.

The Hidden Dangers of Vibe Coding With Low-Cost Freelancers

Many founders are tempted by freelancers offering extremely low rates. While the idea of saving money is appealing, vibe coding with bargain-rate developers comes with serious risks:

Poor Code Quality: Low-cost freelancers may cut corners, leaving messy, unmaintainable code.
Lack of Documentation: Your codebase may be difficult for future engineers to understand or build upon.
Delayed Timelines: Cheap freelancers often juggle multiple clients, causing unpredictable delays.
False Confidence: Founders may assume their MVP is “production-ready” when it’s not.
Hidden Costs: Fixing technical debt later often costs more than hiring quality engineers from the start.

Using low-cost freelancers is fine for prototyping ideas quickly, but it becomes risky when your MVP starts attracting real users or paying customers.

Signs You Need Real Engineers

Here are the main indicators that your MVP has outgrown freelancers:

1. Product Complexity Increases

Your MVP is no longer a simple prototype.
Features require backend scalability, integrations, or complex logic.
Codebase is hard for freelancers to maintain consistently.

2. Customers Expect Stability

Paying users begin using your product regularly.
Bugs, downtime, or inconsistent updates start hurting your credibility.
You need reliable, professional code that can scale.

3. You Plan for Rapid Growth

You anticipate increasing traffic, user engagement, or data volume.
Your MVP needs a scalable architecture to handle more users efficiently.

4. Security and Compliance Matter

Sensitive user data, payment systems, or regulatory requirements are involved.
Freelancers may lack the expertise to ensure security best practices.

How to Transition Smoothly to Full-Time Engineers

Once you’ve decided to hire real engineers, plan the transition carefully to avoid disruption:

Audit Existing Code: Identify areas of technical debt and create a roadmap for refactoring.
Hire Strategically: Look for engineers with startup experience who can handle rapid iteration and product scaling.
Document Everything: Ensure all features, APIs, and infrastructure are well-documented for the new team.
Maintain Continuity: Keep a few top freelancers for short-term tasks during the handover period.
Invest in Tools: Use code repositories, CI/CD pipelines, and testing frameworks to support professional development practices.

Cost Considerations

Hiring full-time engineers is an investment. While freelancers may seem cheaper upfront, consider the long-term costs:

Technical Debt: Fixing poor-quality code can cost far more than hiring engineers initially.
Lost Customers: Product instability can lead to churn and missed revenue.
Opportunity Cost: Delays in scaling and adding features can let competitors win market share.

Think of full-time engineers as insurance for your product’s future success.

Conclusion

Freelancers are invaluable for testing your idea and building a lean MVP quickly. But relying on low-cost vibe coding can be dangerous: messy code, delayed timelines, and hidden costs can stall your startup before it even takes off. Once your product gains traction, complexity, and paying users, hiring real engineers ensures stability, scalability, and long-term growth.

Key Takeaway: Use freelancers for prototyping, but transition to full-time engineers before your MVP becomes a product your customers depend on. Planning the move carefully saves time, money, and frustration.

Have you experienced the vibe code tax firsthand? Share your story in the comments and tell us how you decided when to hire full-time engineers.