Tag Archives: entrepreneurship

A glowing app icon launching from a futuristic digital cube platform with sparks and fragments
AI, Business, cloud

Migrating from Lovable: Steps to Self-Host Your App

Lovable is a remarkable product.
You describe what you want. It builds it. You ship in hours instead of weeks.
That’s genuinely impressive, and I’ve used it to launch things I would have otherwise shelved for “when I have more time.”

But “when I have more time” eventually arrives.

And when it does, you start asking different questions:

“What happens if they change pricing?”
“Can I run this on my own infrastructure?”
“Where exactly does my data live?”

Those aren’t paranoid questions. They’re the right questions.
This post is about answering them — practically, with actual steps you can follow.

Continue reading →
Standard
Business

Scaling Engineering: Ownership Over Hiring

Most engineering leaders think scaling is about hiring.

And honestly, that instinct makes sense — more work, more people, problem solved. But in practice, scaling engineering is mostly about scaling ownership. The teams that succeed aren’t necessarily the ones with the most engineers, the most process, or the fanciest org charts. They’re the ones that can keep ownership close to the work as the organization grows.
That sounds simple until you’ve experienced the moment it breaks down at 2 AM.

I’ve had the chance to see engineering organizations at very different scales — from early startup environments to larger companies like Google, Netflix, Meta, and JFrog.
Every company is unique, but the patterns are surprisingly consistent.

The biggest takeaway is this: every growth stage introduces a new coordination tax.
The challenge isn’t eliminating that tax.
The challenge is preventing coordination overhead from growing faster than the company does.

The First 20 Engineers: Optimize for Builders

At around 20 engineers, speed is your biggest advantage, and process is often your biggest enemy.
Everyone sits close to the product. Engineers talk directly to customers.
The person writing the code can usually explain exactly why it exists and what it connects to. It’s a genuinely magical phase — and it’s also temporary, so it’s worth enjoying while it lasts.

At this stage, ownership should be brutally simple: teams own services end-to-end, carry their own on-call rotation, deploy their own code, and fix their own incidents.
No exceptions.
One of the strongest signals of a healthy engineering culture is whether the people building the software also feel the consequences when it breaks. If your team gets paged because their service is down, reliability becomes surprisingly important. Funny how that works.

The Platform Team Trap

One mistake I see repeatedly at this stage is creating a platform team too early.
The logic is completely understandable — someone notices that everybody is independently building CI pipelines, setting up monitoring, and solving the same deployment problems.

The natural reaction is, “we need a platform team.” And you know what?
That instinct isn’t wrong.
It’s just early.

At 20 engineers, the cost of coordination is often higher than the cost of duplication.
A few redundant solutions are cheaper than introducing another organizational boundary and the meetings, hand-offs, and dependency management that come with it. This tradeoff becomes even more relevant in the AI era.

Generating code is now cheap.
Creating clear ownership is still expensive. The bottleneck is no longer writing software — it’s understanding who should maintain it six months from now. That’s a human problem, not a tooling problem.

Around 50 Engineers: The Coordination Tax Arrives

Continue reading →
Standard
Physical legal documents dissolving into digital code and holographic interface on an office desk
AI, Business

AI and Compliance: The Most Boring Billion-Dollar Opportunity Nobody Is Talking About

The US compliance sector is massive, expanding rapidly, and heavily strained.
It represents over $40 billion in annual labor spend with more than 400,000 officers. Despite ballooning teams, compliance work has remained stubbornly manual, bureaucratic, and paper-based (“schlep work”), leading to high employee churn (>20%) and massive backlogs (e.g., TD Bank’s $3B fine over a 70,000-alert backlog).

Here’s a weird data point:
Over the last 20 years, the fastest-growing occupation in the US was manicurists and pedicurists.
Right behind it?
Compliance Officers.

Not AI engineers. Not data scientists. Compliance officers.
That says something important about where the real work has been hiding.

The Problem Nobody Wanted to Solve

Compliance is painful. Bureaucratic. Paper-heavy. Repetitive.

Continue reading →
Standard
Business

Effortless Techmeme Summaries to Slack and Telegram

Every morning starts the same way: open Techmeme, scan headlines, open too many tabs, and somehow end up 20 minutes deep into something you didn’t mean to read.

That loop is the problem. Instead of trying to “summarize the internet” or build another bloated AI dashboard, this project does something much simpler: take a strong source, rank and summarize it, and deliver a clean digest to Slack or Telegram.

That’s it—and that’s why it works.

Continue reading →
Standard
AI, Business

Your Startup Is Not a Marathon — It’s a Series of Hard Sprints

For years, founders have been fed the same comforting story:

“Building a startup is a marathon, not a sprint.”

It sounds wise. Mature. Sustainable.
It’s also mostly wrong.

If you’ve actually built something from zero—raised money, shipped under pressure, stared at a flat growth chart at 2am—you know the truth:

Startups don’t feel like marathons. They feel like repeated, borderline irresponsible sprints… with no clear finish line.

The Marathon Myth Is Attractive

Marathons are predictable.
You train. You pace. You fuel. You suffer…
but in a controlled, linear way.
If you’ve done the work (in most cases), you’ll finish.

Startups?
Completely different game.

  • You can do everything “right” and still fail
  • Effort doesn’t map cleanly to outcome
  • The terrain changes mid-race
  • Someone can move the finish line—or delete it entirely

Calling it a marathon gives founders a false sense of control.
It suggests that if you just keep going steadily, things will work out.

They won’t.

Continue reading →
Standard
AI, Business

Compliance Is Not a Checkbox – It’s a System

Let’s be honest.
Compliance today is broken for SMBs.
It’s fragmented.
Expensive.
Manual.
And worst of all—reactive.

You buy a few tools.
Hire a consultant.
Fill out some spreadsheets.
Panic before the audit.
Repeat next year.

Meanwhile, the reality has changed:

  • SOC 2 is table stakes
  • CMMC is blocking revenue
  • HIPAA fines are brutal
  • ISO 27001 is becoming expected

And one unsecured laptop can kill a deal.

The Core Problem

Most companies treat compliance like documentation.
It’s not.
It’s continuous enforcement of controls across your entire environment.

That means:

  • Every device encrypted
  • Every patch applied
  • Every user monitored
  • Every control provable—on demand

You can’t fake that with PDFs.

Continue reading →
Standard
AI, Business

Understanding SOC 2 Compliance: Why It’s Critical for Business

You don’t lose deals because your product is bad.
You lose them because someone in procurement asks: “Are you SOC 2 compliant?” — and you’re not.

That’s it.
Game over.

What is SOC 2?

It is a security and trust standard. It proves that your company handles customer data responsibly across five areas:

  • Security – are your systems actually protected?
  • Availability – do they stay up?
  • Processing integrity – do they work correctly?
  • Confidentiality – is sensitive data locked down?
  • Privacy – are you respecting user data?

It’s not a checklist.
It’s an audit.
An external firm comes in and validates that you’re not just saying you’re secure—you actually are.

Why it matters

SOC 2 isn’t about compliance.
It’s about trust at scale.

Continue reading →
Standard
bots, Business, JavaScript

Streamline Engineering Updates with Slack to Notion Bot

There’s been a lot of noise lately about productivity tools and the “perfect” engineering workflow.
Let’s slow down and separate what actually works from what just creates more overhead.

Here’s a boring truth: Slack is incredible for quick, ephemeral communication.
Here’s a less comfortable truth: It is an absolute nightmare as a system of record.

If you lead an engineering team or run a startup, you probably have a #daily-updates or #eod-reports channel.
The theory is sound.

Everyone drops a quick note at the end of the day: what they shipped, what blocked them, what’s next.

But here is what actually happens:

Those updates get posted.
Someone replies with an emoji.
A thread erupts about a weird bug in production.
Someone posts a picture of their dog.

By Friday, when you’re trying to answer a simple question—“What did we actually accomplish this week?”—those reports are buried under a mountain of noise.

You find yourself scrolling endlessly.
It’s exhausting.
And it doesn’t scale. Not to mention that if you will need SOC-2 (and you will 🙂 ) –> you can’t say “we have everything in Slack”

Why not just force everyone into Jira or Linear?

You could.
But engineers hate context-switching just to write a status update.
Slack is where the conversation is happening.
The friction to post there is zero.

The problem isn’t the input. The problem is the storage.

So I (=Gemini+Claude) built a bridge.

Meet the Slack → Notion EOD Sync Bot

I got tired of losing track of momentum, so I wrote a bot that does the tracking for us.

It’s a lightweight NodeJS service that automatically extracts End-of-Day reports from Slack and structures them beautifully in a Notion database.

Continue reading →
Standard
life, Sport

Optimize Your Murph Challenge Experience with This Tracker

The Murph Challenge isn’t a workout.
It’s a systems failure conducted at heart-rate redline.

If you’ve ever tried to remember whether you’re on rep 183 or 193 of squats while your lungs are filing a formal complaint, you already know: human memory is not a reliable datastore under load.

So I built a Murph tracker that does exactly one job well—count reps—while I focus on the important things, like not dying.

🎖️ What is Murph (and why people keep doing it)

The Murph Challenge is performed on Memorial Day to honor Lt. Michael P. Murphy, a Navy SEAL killed in Afghanistan in 2005.

It was his favorite workout. Originally named “Body Armor”, which feels accurate in the same way “production incident” feels accurate.

The canonical version:

  • 1 mile run
  • 100 pull-ups
  • 200 push-ups
  • 300 squats
  • 1 mile run

Optional difficulty modifier: wear a 20 lb vest and rethink your life choices.

Continue reading →
Standard
AI, Business

How AI is Reshaping Engineering Roles

Every few weeks there’s a new take declaring that AI has made junior engineers obsolete, senior engineers redundant, and teams magically “10x.”
That story is lazy.
And dangerous.

AI didn’t remove the need for engineers. It exposed which parts of engineering were never that valuable to begin with.

What’s actually happening is a compression of execution. The typing, scaffolding, and boilerplate are cheaper than ever. Judgment, architecture, and responsibility are not. If anything, they’re more expensive—because the blast radius is larger.

This forces a reset. On roles. On metrics. On how we train people. On what “good” looks like.

Let’s talk about what to do.

For Engineering Leaders (CTOs, VPs, EMs)

Redesign junior roles instead of killing them

If your juniors were hired to crank out CRUD and Stack Overflow glue, yes—AI just ate their lunch.

That’s your fault, not theirs.

Stop hiring “Keyboard Cowboys” –> Hire juniors who can:

  • Drive AI tools deliberately
  • Reason about outputs
  • Write tests that catch subtle failures
  • Explain tradeoffs in plain language

Make AI usage explicit in job descriptions and interviews. Ask candidates how they validate AI output, not how they prompt it. The junior of the future is an operator and a critic, not a typist.

Make fundamentals non-negotiable

AI is great at producing answers.
It’s bad at knowing when they’re wrong.

Your review culture must check understanding, not just correctness. Ask:

  • Why was this approach chosen?
  • What fails under load?
  • What breaks when assumptions change?

Reward engineers who can debug, profile, and reason under failure.
That’s where AI still stumbles—and where real engineers earn their keep.

Treat AI as infrastructure, not a toy

If AI tools are everywhere but governed nowhere, you already have a problem.

Standardize:

  • Which tools are allowed
  • How prompts are shared and versioned
  • How outputs are validated
  • How IP, data, and security are handled

Ignoring this creates shadow-AI, silent leaks, and unverifiable decisions. You wouldn’t let people deploy random databases to prod.
Don’t do that with AI.

Shift metrics away from “lines shipped”

Output metrics are (now) meaningless. AI inflates them by design.

Measure what actually matters (DORA style):

  • System quality / DevEX / Even Developer happniess
  • Incident recovery time
  • Change failure rate
  • Test coverage and signal
  • Architectural clarity

AI can help you ship faster. It cannot guarantee outcomes. Your metrics should reflect that reality.

Invest in orchestration skills

The future senior engineer doesn’t just write code. They design systems that coordinate intelligence.

Encourage work on:

  • Agent pipelines
  • Evaluators and guardrails
  • Feedback loops
  • Tooling that checks AI against reality

This is the new leverage layer. Treat it as a core skill, not a side experiment.

Protect deep expertise

Don’t flatten everyone into “full-stack generalists.”

You still need domain owners:

  • Performance
  • Security
  • Data
  • Infrastructure

AI boosts breadth.
Humans anchor depth.
Lose that balance and your systems will rot quietly—until they fail loudly.

Rebuild onboarding

Assume new hires will use AI heavily from day one.

Onboarding should teach:

  • How your systems actually work
  • Why key decisions were made
  • What invariants must not be broken
  • How to validate AI output against production reality

Otherwise you’re training people to copy confidently—and understand nothing.

For Engineering Teams

Use AI to kill boilerplate, not thinking

Let AI scaffold, refactor, and generate tests.

Humans own:

  • Architecture
  • Invariants
  • Edge cases
  • Failure modes

If AI is making your design decisions, your team is already in trouble.

Practice “AI-assisted debugging,” not blind trust

Always reproduce. Always measure. Always verify.

Treat AI like a fast junior engineer: helpful, confident, and occasionally very wrong. If you wouldn’t merge their code without checks, don’t do it for a model.

Document intent, not just code

Code shows what the system does. It rarely shows why.

Write down:

  • Why the system exists
  • What tradeoffs were made
  • What must never change

This documentation becomes the truth source when AI generates plausible nonsense at scale.

Continuously reskill horizontally

Each engineer should expand into at least one adjacent area every year:

  • Infra
  • Data
  • Product
  • Security

AI lowers the learning barrier. Use that advantage deliberately, or waste it.

For Individual Engineers

Master one thing deeply

Pick a core domain and become genuinely hard to replace there.

Depth is your moat. AI makes general knowledge cheap. It does not replace hard-earned intuition.

Learn how AI systems fail

Hallucinations. Bias. Brittle reasoning. Silent errors.

Knowing failure modes is more valuable than knowing prompts. Engineers who understand where AI breaks will outlast those who just know how to ask nicely.

Build visible, real projects

Portfolios beat resumes.

Show:

  • Systems you designed
  • Tradeoffs you made
  • How you used AI responsibly
  • How you validated results

Real work cuts through hype instantly.

Think in systems, not tickets

The future engineer isn’t judged by tasks completed.

They’re judged by how well the whole machine runs under stress.

Bottom Line

AI compresses execution time.
It does not compress judgment, responsibility, or accountability.

Teams that double down on thinking, architecture, and learning will compound.
Teams that chase raw output will ship faster…

…straight into walls.

The choice is not whether to use AI.
The choice is whether you’re building engineers—or just accelerating mistakes.

Standard