The biggest shifts in our daily lives didn’t come from “apps” or social networks — they came from invisible levers that quietly gave us back time, energy, and attention.

Smartphones? They’re just the remote control.
The real transformation came from what’s humming backstage.

Here are five “boring” technologies that ended up being more disruptive than any iPhone launch.

1. Contactless Payments: Time, Unlocked

Remember fumbling for cash, waiting for chip cards, or praying the machine wouldn’t reject your swipe?

Now you tap. Two seconds. Done.

During the pandemic, contactless adoption exploded by 150%. Today, nearly 80% of in-person transactions in U.S. cities are tap-to-pay.

The real impact? The friction of spending dropped below the threshold of conscious thought. You don’t think about “paying” anymore — it just happens. And that changed how we all shop.

2. Smart Thermostats: The Stress You Forgot You Had

Temperature used to be a constant battle:

• Too hot, too cold.

• Arguing about settings.

• Heating empty homes out of guilt.

Smart thermostats ended that background noise. They learn your patterns, sense when you’re gone, and pre-warm your home before you arrive.

Result? 10–15% less energy spend and a chunk of low-grade stress removed from your brain.

This isn’t “cool tech.” It’s invisible comfort.

3. Barcodes & QR Codes: The Passport for Things

Without barcodes, modern logistics would collapse. Every package, every delivery, every stocked shelf — it all traces back to that first barcode scan in 1974. Today? 5 billion scans a day.

QR codes took it further. Menus, payments, packaging, check-ins. Between 2018 and 2022, U.S. QR usage grew 750%.

It’s the simplest idea: let every object speak. But without it, same-day delivery wouldn’t exist.

4. LED Lighting: The Revolution Nobody Noticed

When did you switch to LEDs? You probably don’t remember. But the shift cut lighting costs by 80% and multiplied bulb lifespans 20x. U.S. households saved billions. Cities lit up streets longer. Businesses stopped budgeting for bulbs.

The deeper change? Lighting stopped being a conscious decision. Leaving a light on no longer “felt expensive.” That mental burden vanished.

5. Robot Vacuums: Automation That Actually Matters

Most “smart” devices just add screens. Robot vacuums removed work. The average home spends 5 hours/week cleaning. A robot can reclaim 4 of those — whether you’re there or not.

The first time you return to clean floors you didn’t clean yourself, it feels like magic. But it’s really infrastructure: a background process running your house.

The Pattern: Infrastructure > Interface

The future doesn’t belong to shiny new features. It belongs to friction killers.

• Contactless removed the act of “paying.”

• Smart thermostats removed the act of “managing temperature.”

• Barcodes removed the act of “tracking inventory.”

• LEDs removed the act of “thinking about light.”

• Robot vacuums removed the act of “cleaning floors.”

The most powerful technologies are the ones you stop noticing.

What Founders Should Steal From This

If you’re building, ask yourself:

Am I adding another notification, or am I removing a point of friction?

Startups that give people attention back will always outlast those that compete for it.

The next wave of unicorns won’t be the loudest apps on your home screen. They’ll be the invisible levers in your life you never want to live without.

The best innovation isn’t the one you rave about.
It’s the one you forget exists.

So when you’re sketching your next big startup idea, don’t just chase what looks shiny.
Ask yourself: what’s the “quiet technology” in your own life you couldn’t imagine living without?
That’s where the real leverage usually hides.

Here's the reality: while you're debugging NextJs code at 2am, your competitors just hired a developer who works 24/7 for less than your coffee budget.

• He doesn't take sick days.

• He doesn't argue in code reviews.

• He doesn't need equity or benefits.

• He writes features, tests, and documentation.

His name is Claude Code.

But here's the thing most founders get wrong – they think AI coding is about prompting. It's not. It's about management.

The Vibe-coding trap (and why I escaped it)

I was deep in the Cursor cult last year. We even rolled it out company-wide. I tried vibe-coding heavy projects and spinning up quick prototypes. The honeymoon phase was real – until it wasn't.

The bigger the project got, the more obvious the problem became: this "vibe coding" doesn't scale.

Everything breaks at the complexity boundary.
Context gets lost.
The agent loops or ignores rules.
The system falls apart.

Most founders hit this wall and give up. They go back to doing everything themselves, burning out or hiring real developers to handle the complexity. And thus slowing down.

I took a break, cancelled Cursor, switched to Zed, back to old-school.

Then I found Claude Code

Claude Code is a completely different animal.

For the first time, I could run long development sessions, maintain context, and design, evolve, and refine complex systems without feeling like I was walking on a glass bridge.

I realized I was basically working with my own personal, dedicated junior developer. For $100 a month. Insane.

Last week I set myself a brutal test: build a native macOS Swift extension for centralized information collection and sharing. I'd been avoiding this project for 18 months. Too complex, too unclear, too time-consuming.

Claude Code helped me ship it to production. Over the weekend.

But only after I gave him:

• Structured requirements

• Clear UX design

• Proper context delivery

• Role definition, constraints, and interaction methodology

That's when the insight hit me like a freight train.

The secret: treat AI like your best junior developer

I started using every management technique I'd learned from running real teams. The same frameworks we use to organize humans: goals, requirements, assumptions, boundaries, instructions, milestones.

I wasn't "prompting" anymore. I was delegating.

Look, here's the problem – most technical founders suck at delegation because they've never had to manage people. They think faster code means doing it themselves.

Wrong.

Faster code means building systems where other people (or AI) can execute your vision without constant hand-holding.

What changes when you get this right

• The stress disappears.

• Deadlines become realistic.

• Ideas become shippable.

You can have one developer. Or two. Or five. Even if you're flying solo.

The bottleneck isn't the coding anymore – it's how clearly you can explain what you want.

Not "prompting." Task assignment.
Not "chatting." Building knowledge systems where AI integrates as a team member.

Claude Code can't innovate for you. But she'll execute your ideas rapidly if you explain them like you would to any good developer.

Stop coding. Start delegating.

Don't wait for "someday when I have budget for a real developer."

Your competitors aren't waiting. They're shipping features while you're still stuck in the terminal.

The founders who figure this out first will eat everyone else's lunch.

💬 If this resonates - write in the comments.

I'll share what the structure looks like that makes AI actually work like a developer.
With which I've built more than one working project.
And it's an incredible feeling.

Most founders obsess over product-market fit, burn rate, and growth constraints. They build elaborate security protocols for their servers and databases. But they're missing the most obvious attack vector: the device sitting in their pocket.

Here's what I learned the hard way about how quickly everything can fall apart.

When one click nearly cost me everything

In 2019, I lost my iPhone. Not ideal timing—I was running a startup, had investors breathing down my neck, and my entire business lived in that little black rectangle.

I activated remote search but didn't enable immediate wiping. Big mistake. Within hours, I got an SMS that looked legitimate: "Access to your iCloud account has been restored. Link." or sorta, I do not remember now

The link looked real. The messaging felt authentic. I was stressed, distracted, and frankly desperate to get my phone back.

So I clicked. And entered my iPhone unlock code. “It was that moment he knew that he f***d up”. Really, just after the click I realized that I screwed up.

It was a sophisticated phishing operation targeting iCloud unlock services. These aren't random script kiddies—they're organized operations to unlock stolen phones, harvest the unlock credentials, and flip devices for profit. My desperation made me the perfect mark.

I managed to trigger remote wipe before they got deeper into my systems, but the damage assessment was brutal. Every password had to be changed. Every access point secured. Sensitive materials over Slack and e-mail must be reviewed for potential compromise.

That's when I understood a fundamental truth about modern business: your startup is only as secure as the weakest device in your founder's pocket.

The billion-dollar lesson from Jeff Bezos

If you think I'm being dramatic, consider what happened to the richest man in the world.

In May 2018, Jeff Bezos received a WhatsApp message from Saudi Crown Prince Mohammed bin Salman's account. It contained a video file. Bezos didn't click anything suspicious. He didn't download sketchy attachments. He simply received the message.

That was enough.

The video triggered a zero-click exploit—a sophisticated attack that requires no user interaction. Within hours, Bezos's phone transformed from a communication device into a surveillance tool. Data exfiltration jumped from 430KB daily to over 101MB. That's a 200x increase in outbound traffic.

The attackers used memory corruption vulnerabilities in video processing to gain complete device access. They installed persistent surveillance malware that operated invisibly for months. When forensic experts finally analyzed the device, they found attack chains so sophisticated they essentially created "a computer within a computer."

This wasn't some random hacker. This was nation-state level spyware—likely NSO Group's Pegasus—deployed against the CEO of Amazon.

The architecture of digital destruction

Here's the reality most founders don't understand: memory corruption vulnerabilities are the nuclear weapons of cyber warfare.

Every app that processes images, videos, or documents creates opportunities for buffer overflows, use-after-free exploits, and integer overflows. When attackers find these vulnerabilities, they can:

• Execute arbitrary code without user interaction

• Install persistent surveillance malware

• Access encrypted communications and stored passwords

• Exfiltrate sensitive business data

• Use your device as a launching pad for deeper network attacks

The economics are brutal. Individual exploit chains cost millions to develop, but they target high-value individuals—executives, journalists, activists, and yes, startup founders (especially in crypto/web3) who might have valuable IP or investor connections.

Recent attacks show the evolution of this threat:

FORCEDENTRY (2021): Used iMessage's image processing to create a Turing-complete computing environment within a single exploit. Over 70,000 logical operations built a custom computer architecture inside the victim's phone.

PWNYOURHOME (2022-2023): Two-phase attack targeting HomeKit and iMessage, successfully bypassing Apple's Pointer Authentication Codes.

CVE-2025-43300: A zero-day in Apple's Image I/O framework that could trigger memory corruption through malicious image files—actively exploited against targeted individuals.

The common thread? Memory corruption vulnerabilities that turn everyday digital interactions into potential business catastrophes.

Why Apple's Memory Shield changes everything

Most security improvements are incremental—better encryption here, stronger authentication there. Memory Shield is different. It's architectural surgery.

Here's how it works: Every block of memory in iPhone 17 gets tagged with a secret code. When any process tries to access memory, the hardware checks if the request includes the correct tag. No match? The system immediately blocks access and terminates the process.

This isn't software trying to catch attacks after they start. This is hardware preventing entire classes of exploits from functioning at all.

Buffer overflows? Different memory regions get different tags, so spillover attacks hit a wall.

Use-after-free exploits? Memory gets retagged when reallocated, making old references instantly invalid.

Speculative execution attacks? Tag confidentiality protections prevent side-channel leakage.

Apple's offensive research team tested Memory Shield against six major exploit chains used in real attacks over the past three years. None could be rebuilt to bypass the new protections. Not adapted—rebuilt from scratch.

This breaks the economics of sophisticated attacks. Previously, attackers could swap similar memory corruption bugs when one got patched. Now they need completely new attack strategies, driving development costs through the roof while reducing reliability.

The hidden cost of founder devices

Here's what every startup should understand: when your founder's device gets compromised, it's not just personal data at risk.

Access to cloud infrastructure. Most founders have admin access to AWS, Google Cloud, or Azure through their phones. Device compromise = infrastructure compromise.

Business Email Compromises. Those WhatsApp threads with VCs or private equity? Telegram conversations about fundraising? Email chains about acquisition discussions? All visible to attackers, and might be a subject to extortion or spoofing.

Development resources. GitHub access, deployment pipelines, database credentials—much of this flows through founder devices.

Customer data. Support systems, CRM platforms, analytics dashboards (that means customer’s data) —accessible through mobile apps and saved passwords.

The startup failure statistics are sobering: 60% of companies close within six months of a serious cyberattack. For early-stage companies without extensive security infrastructure, a compromised founder device can be the single point of failure that kills the business.

The upgrade that's actually about necessity

For founders and C-level executives, iPhone 17 isn't an upgrade—it's business insurance.

Traditional security thinking focuses on perimeter defense: firewalls, VPNs, endpoint protection. But when the "endpoint" is the device that controls everything else, you need a different approach.

Memory Shield provides always-on, invisible protection that requires zero configuration. No security training needed. No complex policies to maintain. No performance impact on daily operations.

This is particularly crucial for technical founders who often resist "security theater" but understand real engineering solutions. Memory Shield isn't compliance checkbox—it's a fundamental shift in how devices handle potentially malicious code.

(And yes, the hardware is genuinely beautiful. Sometimes the best security solutions are also the most elegant ones.)

Building systems that survive contact with reality

The lesson extends beyond device security to startup architecture in general: build for the attacks you can't see coming.

Most founders optimize for known threats—competitors, market changes, funding gaps. But black swan events—sophisticated attacks, zero-day exploits, nation-state actors—can destroy companies overnight.

Memory Shield represents a philosophy I try to apply across all startup systems: defense in depth at the architectural level. Don't just patch vulnerabilities as they're discovered. Engineer solutions that eliminate entire categories of problems.

Whether it's device security, infrastructure design, or business processes, the startups that survive are the ones that prepare for threats they haven't imagined yet.

In an era where AI makes sophisticated attacks more accessible and geopolitical tensions increase cyber warfare, proactive security isn't paranoia—it's survival strategy.

The reality is simple: Apple just made it dramatically harder for one WhatsApp message to destroy your business. For founders, that might be the most valuable product feature released this decade.

What's the most overlooked security vulnerability in your company right now? The answer might be closer than you think.

If Claude Code is only helping you code faster, you're not building leverage – you're reinforcing the founder bottleneck.

I see this a lot. Technical founders discover Claude Code, fall in love with the productivity boost, and start cranking out features at 3x speed. They feel like they've unlocked a cheat code.

But here's the trap: if that acceleration only lives in your personal workflow, you've just shifted the bottleneck from coding to prompting. Every architectural decision flows through one person who knows how to talk to Claude effectively.

That's not scale. That's fragility with better autocomplete.

I learned this the hard way at our side startup. I was the "Claude whisperer," churning out prototypes while my team struggled with basic prompts. When I took a week off, velocity collapsed. The AI that was supposed to multiply our team had actually made us more dependent on me.

The real unlock isn't making one person faster. It's creating reproducible workflows where your entire team can think and build together.

Why Solo Genius Fails at Scale

The solo genius founder is startup mythology at its worst. Brilliant technical leader who carries the entire architecture in their head, makes every important decision, becomes indispensable. Early employees worship their speed. Investors love their deep technical knowledge.

Claude Code amplifies this failure mode. When only one person knows how to prompt effectively, you've created a more sophisticated version of the same bottleneck.

Your job isn't to be the fastest coder in the room. It's to create conditions where your team produces consistent outcomes without constant oversight. Engineering culture gets shaped in the smallest details: how files are structured, how prompts are written, which commands get documented.

I call this the "avalanche effect." Small rocks seem harmless until they trigger something that buries the entire project under rotten technical debt. One sloppy naming convention leads to confused imports. With Claude in the mix, these defaults become critical. If your prompts are vague, Claude generates inconsistent code. If your folder structure is chaotic, Claude amplifies the chaos.

The biggest misconception about Claude is that it's a productivity hack for individuals. The real shift happens when Claude changes how the team thinks together. Instead of five engineers carrying different mental models, you now have a shared assistant that reflects the same patterns across all interactions.

This forces transparency. Claude is only as good as the context it receives. If critical knowledge lives inside someone's brain, Claude underperforms for everyone else. Architecture decisions must be written down. Reasoning steps must be documented.

Rules imposed by one genius founder get ignored the moment that founder isn't watching. Rules created together become part of the team's identity. The difference? Ownership. When the team feels ownership over the rules, they internalize them.

Building Your Team's Constitution

Everything crystallizes in a single file: Claude.md. This isn't documentation – it's your repo's constitution. The persistent instruction set that governs how both humans and AI reason about your codebase.

Every developer brings years of implicit knowledge to your codebase. Claude doesn't have that context. This file closes the gap. For humans, it captures agreements in one place. For Claude, it ensures every suggestion aligns with team standards.

The template covers the essentials: project structure with clear layer separation, workflow enforcement that makes Claude behave like a disciplined engineer, real commands that prevent hallucinations about how to run your project, coding standards that emphasize functional patterns and explicit typing.

But the value isn't copying any template verbatim. It's starting with clear guardrails, then evolving them together. After seeding the repo, schedule a focused hour with the team. Walk through each section: Does this reflect how we actually want to work? What feels too restrictive?

Your role as founder is paradoxical. Seed the system with strong defaults – showing up with a blank page wastes weeks. But step back enough that the team feels genuine ownership. Frame decisions instead of dictating them.

Treat pull requests against the file like code changes. When someone wants to adjust testing patterns, they submit a PR. The team reviews it. This makes governance feel as natural as coding.

Rules must be living artifacts. Review monthly: Does this still reflect how we actually work? This cadence normalizes change. Engineers stop seeing rule updates as disruptive events.

If you want to start a fresh Python project now – start today using the Claude Code. You can use my starter template for this, the same ones I gonna use for my projects. Here are the files:

• /Claude.md

• /Readme.md

But, please discuss the rules with the team. In the next article of this series I will explain technology and rules choices, so stay tuned.

Implementation Reality Check

Most teams treat Claude Code like assistant on steroids. When properly integrated, it becomes an agent that participates in your entire development lifecycle – from exploration through deployment.

Every development task begins with exploration. Instead of manually grepping through files, prompt Claude to generate structured overviews: "Generate a complete tree hierarchy of the repo." This builds shared mental models the team can discuss rather than knowledge trapped in individual heads.

With proper guardrails, Claude always proposes a plan before coding: which files it will modify, what changes it will make. This transforms Claude from code generator into thought partner.

When coding begins, Claude works in dialogue with engineers. The AI drafts, humans review, adjustments are made. But never let Claude run fully autonomous on complex work. That's where drift happens.

Let me walk you through a real scenario. You're launching a Python product with three engineers: a backend developer, a bootcamp graduate, and a data scientist brilliant with models but weak on software discipline.

Drop in the starter constitution, framed as "This is our starting point. We'll evolve it together." Walk through the file section by section. The data scientist questions whether strict type hints will slow experimentation. The bootcamp graduate asks for functional style examples.

These discussions matter more than the final rules. By hashing out disagreements early, you avoid endless arguments later.

When the first feature request arrives – building a REST endpoint for user recommendations – the process unfolds naturally. Claude explores repo structure, proposes a plan, writes scaffolding while engineers refine logic, runs tests and catches edge cases, then checks against team conventions before merging.

The endpoint ships in hours with consistent quality because Claude enforces shared guardrails at every step. When you hire your first additional engineer months later, they read the constitution, understand the philosophy immediately, and become productive within days instead of weeks.

Common Ways This Goes Wrong

The fastest way to sabotage Claude Code adoption is giving it too much autonomy too soon. Teams hand off massive tickets and let it run for as long as possible. The output looks impressive but contains architectural violations and brittle integration code.

Another common failure is producing beautiful documentation that nobody follows. The fix is cultural, not technical. Rules must be visible, discussed, and lived.

Perhaps the most insidious pitfall is forgetting that AI adoption is cultural change, not just technical implementation. If engineers feel alienated – seeing AI as competition instead of collaboration – you've lost. Frame AI not as replacement for their skills but as amplification.

Making It Scale

The holy grail is a team that executes independently – engineers who make good decisions without constant oversight. Claude, when properly integrated, becomes the mechanism that scales your judgment across the team.

Traditional founder bottlenecks start innocently. You make key architectural decisions early. Those work well, so you keep making them. Soon engineers ask permission for every choice. You think you're maintaining quality. Really, you're creating dependency.

The solution isn't abandoning oversight – it's encoding your judgment into systems. When architectural principles live in your team constitution, Claude Code applies them consistently. When testing philosophy is documented, engineers don't guess what "done" looks like.

How do you know if it's working? The clearest signal is onboarding speed. Traditional onboarding is brutal: weeks of pair programming, endless context-setting meetings. With properly integrated Claude workflows, new hires get productive faster because the AI enforces patterns from day one. Track time from first commit to first meaningful pull request – this should drop from 2-3 weeks to 3-5 days.

Another key metric is decision consistency. Are engineers making choices that align with team conventions without asking permission? Claude integration succeeds when it distributes good judgment, not just speed.

The most important measures are cultural. Do engineers contribute to and defend conventions? Can they refactor code without seeking approval? When deadlines compress, does quality hold steady or collapse?

This transformation doesn't happen overnight. It requires intentional facilitation and willingness to let the team shape rules you might have written differently. But the payoff is massive.

Month one feels slow because you're debating rules instead of shipping features. Month six feels smooth because everyone knows the conventions. Month twelve feels magical because new hires become productive in days, Claude amplifies collective wisdom instead of personal preferences, and the system becomes more intelligent as it grows.

By year two, you achieve something most startups never reach: a technical culture that scales independently of any individual contributor.

The Choice

The story isn't really about Python, Claude Code, or AI. It's about a choice every technical founder faces: chase individual productivity by treating Claude as your personal superpower, or slow down just enough to build systems that scale beyond you.

When you create a team constitution for AI workflows, you're not just configuring an assistant. You're codifying how your team thinks about code, makes decisions, and solves problems. The conversations around creating and evolving that document matter more than the document itself.

Claude's role is as an amplifier. Give it chaos, and it multiplies chaos. Give it clarity, and it multiplies clarity. The hardest part isn't technical – it's cultural. Convincing brilliant engineers to follow shared conventions instead of optimizing personal workflows.

The founders who succeed understand their job isn't being the smartest person in the room. It's creating conditions where the room gets smarter together.

Don't wait until chaos forces your hand. Start with a team constitution. Debate it together. Embed Claude Code throughout your development lifecycle. The goal isn't moving faster in month one. It's building systems that move faster every month for years to come.

The small file you create today might become the backbone of an engineering organization that outlasts your direct involvement. That's not just productivity – that's legacy.

What's your experience with systematizing AI tools across your team? I'd love to hear how you've handled the transition from individual productivity boosts to scalable workflows.

So instead of repeating it for the dozens time over coffee or Zoom, I figured it’s time to write it down. Let me introduce myself properly.

What the hell is a Growth CTO?

Most people hear “CTO” and think senior engineer with better equity. Others hear “consultant” and immediately picture PowerPoint decks and buzzwords.

Neither is what I do.

A Growth CTO lives at the intersection of technology and growth. The job isn’t about coding for you – or hyping you up with fancy frameworks. It’s about turning a promising product into a predictable growth engine.

Nobody tells you this, but the real constraint in 90% of startups isn’t the product, the team, or even the market. It’s the founder. Every decision, every hire, every feature flows through them. The founder becomes the system. And the system breaks.

That’s where I come in. Connecting founder’s illusions with reality.

Who I work with

Not napkin-stage dreamers. Not corporates drowning in process. I mostly work with founders who:

• Already have an idea or an MVP.

• Have a few early users or revenue.

• But have hit the growth paradox.

Here’s the pattern: the product technically works (or at least exists), but growth stalls. The team grows, but velocity drops. Burn goes up, but outcomes don’t. Or the founder is staring down Series A, but they know their tech stack, team, and systems won’t survive investor due diligence – let alone scale.

Sound familiar?

How I Help Founders Break Through

For Early-Stage Founders: You Don’t Need a Product (Yet)

When early founders come to me and say, “I’m starting with this thing, I need to build the product,” my answer is usually: no, you don’t need a product.

Unless you already have customers lined up, the product is just an illusion. What you need first is market validation. Then we dig into real customer development - interviews, requirement gathering, hypothesis testing. Then we use quick prototypes as the heavy cannon to find the real meat: what future users are actually willing to pay for. Build once you’ve proven demand, not before.

Turning Chaos into a System

Most early teams run on adrenaline and heroics. It works for a while, until it doesn’t. At some point, you can’t out-hustle complexity anymore. My job is to help founders stop firefighting and start building real systems – processes, architecture, and culture – that let the company run without them holding every string.

Prototypes That Actually Prove Something

A lot of founders burn months polishing an MVP that’s still just a guess. I take the opposite route: fast, scrappy prototypes designed to answer one brutal question – will customers pay for this? how much? will economy converge? 

We don’t build for beauty; we build to test, learn, and adjust. Validation beats perfection every time.

Architectures That Don’t Collapse Under Growth

Growth exposes cracks. What felt like “good enough” engineering suddenly becomes a bottleneck. I help founders rebuild their technical foundation so it can handle 10x more users, 10x more data, and 10x more expectations – without the whole system buckling. And with security angle in the focus – it's a paramount in our early AI era, and will become more and more important in a future. Especially in crypto and DeFi verticals.

Connecting Tech to Business Outcomes

Too often, features are built because they “feel cool” or because someone shouted loudest in a sprint meeting. I make sure every technical decision ties back to the metrics that actually matter - revenue, retention, runway. No more building for the sake of building.

Why my approach is different

You’ve heard the shallow advice before:
“Just hire faster.”
“Outsource your CTO role.”
“Hustle harder.”

That’s consultant-speak bullshit.

Here’s the reality:

• Tech-only fixes (better code, faster sprints, CI/CD pipelines) don’t solve growth.

• Business-only fixes (pitch decks, funnels) don’t fix scalability.

I’ve seen this movie before: the founder stays stuck in the middle, exhausted, irreplaceable, and secretly terrified the whole thing collapses without them.

My approach is simple: dismantle the bottleneck. Build systems around the founder instead of relying on them. Shift decision-making. Connect tech and metrics. Build a second tier of leadership investors actually trust.

This isn’t about working harder. It’s about re-architecting how the founder + company makes decisions.

Why I care

I’m not saying this from the sidelines. I’ve lived it.

As a technical founder, I was once the guy saying, “Only I understand the architecture.” My team waited on me for every decision. We shipped slow, burned out, and nearly missed product-market fit.

The turning point came when I stopped treating myself as THE system and started building systems around me. That shift - from technical expert to business systems thinker - is exactly what I bring to founders now.

My philosophy

Forget the startup theater. You’re not building a deck for Sand Hill Road. You’re building a business.

Yes, it needs to be scalable. Yes, it needs to be investable. But first it needs to make money. Otherwise, raising more just buys you a longer runway to crash harder.

I’ve seen too many founders chase “future adoption” (especially in crypto) while ignoring today’s fundamentals. That’s how bubbles pop and dreams die.

The companies that win? They build like Amazon did: steady, customer-obsessed, cash-generating engines.

The community piece

Here’s the trick. I’m not here to make you dependent on me or any other external “expert.” The whole goal is to turn you into the architect of your own growth systems. Just follow my Substack, read articles – I will be writing a lot about that in attempt to externalize the knowledge I gathered.

And that only works if we build this as a community of founders who share scars, frameworks, and hard truths - not just motivational fluff.

So if you recognize yourself in this…

👉 If you’ve got MVP traction but stalled growth
👉 If you’re preparing for Series A but know your tech foundation won’t hold
👉 If you’ve realized you are the bottleneck

… Let’s talk.

Because it might be time to turn your promising product into a predictable growth engine.

P.S.

If you’re reading this as a peer – same invitation. Growth skills are becoming essential not just for startups, but for agencies, studios, and independent builders too. If you’re exploring these systems for your own work, I’d love to swap notes.

Yesterday’s post about founder agreements blew up more than I expected – comments, traffic to my Substack, even new subscribers.

Not surprising. I learned this lesson the hard way. So I decided to create a GPTs to help me systematically draft these boundaries in future.

TLDR:

Founder Agreements assistant

Below is my story, essentials and example how I’d use it in future endeavors.

NB! This is not a legal advice. Please talk to your lawyer after you drafted something.

I once spent ten years building a company with a partner. Ten years of shared wins, shared failures, shared sleepless nights. And then it all blew up. Not because the market killed us, not because the product sucked – but because we couldn’t hold it together.

I wasn’t easy to work with. I didn’t know how to set boundaries, and I sure as hell didn’t respect his. When the stress spiked into the red zone, my ego chose to torch the whole thing instead of renegotiating like an adult. The formal reason? A side hustle plus burnout. The real reason? We were sick of each other.

The cost: ten years of friendship gone, one business dead, and millions left on the table.

That’s why I got very serious about founder agreements. Because here’s the thing: a founder agreement isn’t a legal checkbox. It’s a pre-marriage conversation. A stress test for the relationship before you hit turbulence.

So let’s get tactical. Here’s what needs to go in.

5 Non-Negotiables (skip these and you’re asking for drama)

1. Roles & Responsibilities
   Who’s doing sales? Who’s doing marketing? Who’s writing the content? Who’s in charge of technology? How many hours per week is realistically expected from each founder?

2. Equity Vesting + Commitment Cliff
   Equity is earned, not gifted. Leave early, leave your shares. No drama, no lawsuits.

3. IP & Audience Belong to the Company
   Clients, social channels, domains, content – are these a company assets or personal toys?

4. Exit & Buyout Formula
   If someone leaves, the price and terms are already defined. No “we’ll figure it out later in court.”

5. Deadlock Resolution
   What happens if it’s 50/50 and you can’t agree? Pick an arbiter now (mentor, advisor), not later.

The Pre-Breakup Plan (without killing the vibe)

You can talk about ugly scenarios while everyone’s still smiling. That’s the trick.

• Cooling-Off Exit (Founder Sabbatical)
  Up to X weeks “time out” without stigma. But vesting pauses. If you don’t return – you’re out.

• Loss of Interest Clause
  If someone’s done – either with this product or the company entirely – they get a clean buyout.

• Side Projects Rule
  Got a new idea? Offer it to the company first. If rejected, you can build it separately – but not using the shared audience or client base.

Governance moves that make you investable at Series A

What investors want to see in your Data Room:

• One clean legal entity with a transparent cap table and all IP assigned.

• Advisory board in place – so when founders fight, decisions aren’t made by lawyers billing $800/hour.

• Regular reviews – update the agreement every six months, don’t let it gather dust.

That sends the signal:

“These founders have their shit together. Internal fights won’t kill the company.”

⚡ How to Use GPTs Assistant for This

Here is the link to GPTs I created and use for this occasions:

Founder Agreements assistant

Drafting this agreement doesn’t have to be brutal. Think of it as the difference between walking into battle naked vs. armored.

You can sit and talk to you co-founders over Zoom or Meet, click on “Dictate” button in your ChatGPT window, talk through it with your mates and send it to ChatGPT for transcription.

You can literally drop these clauses into a GPT-powered assistant and get a first draft customized to your team’s context. Then run it past a lawyer for final polish if you need to.

Example case

Scenario:

I considering launching a company which produces AI courses with a friend of mine. One founder runs marketing and funnels, the other produces creative and video. Due to my past experience, I have concerns that four months after, the creative partner burns out and needs a break.

The video:

Prompts

Prompt 1:

I want to start a business with a person I know for quite a long. He's actually a friend of mine. And I would like to start a business of AI course creation. He's a creative person and can be easily distracted to new ventures. And the primary idea is to... I'm going to handle the production and marketing part. He's going to handle the creation, content creation, curation, and all other things. And I would like to have a founder agreement drafted concerning the pain points I might experience with him, like multitasking across different households, and maybe get burned out because of no immediate result in this interesting business. And he's a cool guy, but I want to have some sort of fences here.

Prompt 2:

This is the thorough template. Another problem here is that he's working on his day job, and he's willing to quit as soon as this thing gonna start some traction. But I would like to interview him and discuss questions raised here, okay? So, the question is like, what if he gonna lose the interest in the project during the midway, or would like to switch to another product or project, especially if he would like to launch something independently, etc. So, let's extend.

Prompt 3:

Let's make a draft question script and make a list of topics to discuss with notes which we made here, like explanation of risk and mitigations. For example, questions and follow-up, which can disclose some risks or get more meat to think about.

Prompt 4:

Ok, what is left aside? Please combine and make a comprehensive canvas with all the interview questions and red flags above

Prompt 5:

Please review all the text above and think of what is left, what should be edited and we didn't ask yet. Please combine in the full message, don't be lazy, it's important.

Take care.
And Keep Building. Even when it feels pointless.

Here’s the thing: most founder breakups aren’t because the business “failed.” They happen because the partnership failed. And nine times out of ten, it’s not the market, the product, or the customers - it’s the invisible mismatch in expectations, values, and decision-making styles.

Nobody tells you this, but you can absolutely have product-market fit, healthy MRR, and a clear path to Series A… and still watch the whole thing burn down because your co-founder wants to sell in three years while you want to build a generational company.

The Agreement You Shouldn’t Skip (But Most Do)

I’m talking about a founder agreement. Not the generic, lawyer-template one that sits in a Dropbox folder collecting dust, but a real alignment document.

You sit down and answer the uncomfortable stuff:

• What happens to profits - do we reinvest or take distributions?

• Are side hustles allowed?

• How can equity splits change over time?

• What counts as “company property”?

• How does someone exit, and on what terms?

If you can’t agree on these before you’ve raised your first dollar, you’re going to be screwed when the stakes are seven figures and your burn rate is ticking down. Better to walk away now than fight it out in Delaware Chancery Court.

Why You Also Need a “Board” Before You’re Ready for a Board

Even if you have the agreement, life will throw curveballs you never planned for—an acquisition offer, a PR crisis, a sudden cash crunch. That’s where an advisory or oversight council earns its keep.

Not a bunch of “mentor” LinkedIn headshots you never call, but 3–5 people you actually trust to challenge you on:

• Big capex or investment decisions

• Hiring/firing key execs

• Market pivots or product overhauls

• Navigating macro shocks (regulatory, economic, competitive)

• Even responsibilities distributions – believe me or not, I hit that blindly a lot

The trick is: these people aren’t there to “vote” for one founder over another -they’re there to stop you from making dumb emotional calls in high-stress moments.

How to Plan for the Breakup Before It Happens

The ugliest fights I’ve seen weren’t over product direction, they were over exits. A founder wants out, but the buyout terms are a mystery, valuation is emotional, and suddenly your Slack is full of lawyers.

A grown-up founder agreement bakes in:

1. Clear buyout formulas – valuation rules you both agreed on in calmer times

2. Asset division rules – no ambiguity over IP, customer lists, or cash reserves

3. Exit timelines & steps – so you can unwind without blowing up the business

Think of it as a prenup for your startup marriage. It doesn’t make you pessimistic – it makes you investable.

The Reality Check

This is not fun work. Nobody starts a company dreaming about governance frameworks and exit clauses. But here’s the reality:

• Without this, your Series A pitch deck is weaker (VCs smell governance risk instantly)

• Without this, your speed to recover from founder conflict is measured in quarters, not days

• Without this, you’re one bad week away from watching your runway evaporate in legal bills

A founder agreement gives you the baseline clarity. An oversight council gives you ongoing alignment. Together, they make the business harder to kill.

What’s your experience with co-founder alignment?
Have you actually used your founder agreement in a real dispute—or did you wish you had one when things got messy?
Drop me a note; I’ve got war stories that could save you six months of pain.