Simon Høiberg

My marketing team is getting weirdly small.

Not because I stopped doing marketing. Because a lot of the old production work is now handled by agents and specialized tools.

For YouTube:
- research comes from analytics, comments, and audience questions
- scripts get shaped with Claude
- motion graphics are built in Remotion
- editing happens in Resolve

For social:
- drafts get prepared with AI
- visuals are built in Remotion
- scheduling runs through FeedHive

For ads:
- Meta, Google, and TikTok are still the distribution layers
- agents help with angles, variations, checks, and workflow handoffs

For SEO:
- GPT-5.5 helps with keywords
- Claude helps shape content blocks
- n8n handles repeatable workflows

The founder still has to bring the taste.

But I don't think the future of marketing teams is 12 people passing tasks around in Slack all day - AI agents can do most of the work.

8 hours ago | [YT] | 42

Simon Høiberg

Your SaaS stack usually gets bloated one reasonable decision at a time.

Support gets messy, so you add another helpdesk seat. Reporting gets annoying, so you add another dashboard. Research takes time, so you add another tool. Ops gets scattered, so you add another automation app.

None of these decisions look stupid on their own.

But after a while, the business has 40 tabs, 12 pricing pages, and data spread across too many places.

AI changes the calculation a bit.

You can keep the core stack small:

Database.
Payments.
Support inbox.
Publishing system.
Analytics.

Then let agents do the work around it:

→ read tickets
→ check metrics
→ pull context
→ draft replies
→ find patterns
→ prepare the first version

The founder still approves, rejects, changes direction, and makes the final call.

But you don't need to buy another SaaS product every time a workflow gets annoying.

1 week ago | [YT] | 93

Simon Høiberg

Most founders keep looking for the next magic tool that makes business easier.

But the people who are hard to compete with usually got good at the work others avoid.

The uncomfortable stuff.
The technical stuff.
The conversations most people postpone.

So roll up your sleve and learn these 8 skills no one else wants to learn - and you'll keep winning 👇

Skip the Carousel

1 2 3 4 5 6 7 8 9 10

1 week ago | [YT] | 212

Simon Høiberg

The old version of self-hosting was brutal.

Something broke.
You opened docs.
You searched GitHub issues.
You found a random forum thread.
Then you ran some command you only half understood.

I get why people wanted to avoid that.

But with AI, that's not really the version we’re dealing with anymore.

AI is extremely good at infrastructure work when it can inspect the actual system.

Give your OpenClaw/Hermes agent access to your Kubernetes cluster, logs, and monitoring.

Not write access or deploy access, just enough permissions to read and understand what is happening.

Then let it do this hourly:

→ check pods and events
→ inspect logs and metrics
→ understand the cluster context
→ prepare a short report
→ notify you in Telegram

If a pod is crashing, it can explain the logs.

If traffic is not reaching the app, it can trace the path from the public VPS/tunnel into the cluster.

If backups are failing, it can look at the config and point to the line that looks wrong.

You'll get stuff fixed fast! But you'll also learn about infrastructure and devops in a totally different way.

Do this, and self-hosting becomes much less scary.

1 week ago | [YT] | 121

Simon Høiberg

OpenClaw + n8n.
This is an extremely powerful combination.

People thought OpenClaw (or Claude Code) would replace n8n, but here's what they're missing.

n8n - as an application layer between the agent and the tool - still makes perfect sense for at least 3 reasons.

1️⃣ Observability

OpenClaw can write its own skills.
But instead of letting it script away, ask it to create n8n workflows for itself to use.

It is much easier for you to investigate and see what the agent built for itself in n8n, rather than looking through 100 ugly written JavaScripts.

2️⃣ Security

After the agent is done creating its n8n workflow, you can lock in place. Making it read-only from that point.

Instead of adding API keys to .env.local for the agent to use (and abuse) in any way it likes, you can now add the credentials securely to n8n.

From here, you can also easily add any additional safeguarding step, making sure your agent doesn't make a mess by mistake.

3️⃣ Performance

An agent adds value when it needs to make decisions.
But a lot of work is still predictable and deterministic.

Turn it into a workflow.
It's faster and you save tokens.

🔁 The flow

- The agent needs access to an API.
- It writes an n8n workflow with incoming webhook.
- You lock the workflow and add the API key.
- You add extra safeguarding steps.

The agent now proxies all calls through n8n.
It never sees the API key.
It's prevented from making crucial mistakes.

I know... It feels addictive to let OpenClaw do everything.

But this thing is a beast!
Use it responsibly.

3 weeks ago | [YT] | 181

Simon Høiberg

I don’t want every small AI workflow in my business running through OpenAI or Anthropic.

Frontier models are still best for serious work. I use them every day.

But a lot of SaaS workflows are not that deep:

Support triage.
Ticket tags.
Docs lookup.
PR summaries.
Log summaries.
Daily reports.

That stuff does not need the best model on earth.

It needs to be cheap, repeatable, private enough, and good enough to run without turning every tiny task into another hosted API dependency.

That is where local models start to make sense.

Not as a full replacement for Claude or ChatGPT.

As a layer for the normal business workflows you run over and over again.

Start there.

Then move up when the workflow is actually worth the GPU bill.

Here’s the practical map 👇

3 weeks ago | [YT] | 148

Simon Høiberg

We just got rug pulled by the US government.

Anthropic launched Fable 5, the safer version of Mythos.

Then a directive landed, and customer access had to be removed.

This is why founders need a local model strategy.

Hosted models are rented access.

Use them. I do.

But don’t let every AI workflow in your business depend on one provider keeping access open.

Start with the easy stuff:

Support triage.
Routing.
Summaries.
Internal search.
Small agents over company docs.

Here are 8 AI models you can self-host now 👇

Skip the Carousel

1 2 3 4 5 6 7 8 9 10

4 weeks ago | [YT] | 210

Simon Høiberg

You think bootstrapping a SaaS in 2026 is about scale? You got it upside down.

It's about doing more with less.

10-person teams can do +$10M ARR.
3-person teams can do +$1M ARR.
1-person teams can do 6 figures ARR.

And no, you don't have to be a superstar. This is fully achievable by the "average" person (just like myself).

Here's how it breaks down:

For product, you need:
→ AI-powered support
→ Streamlined feedback handling
→ CRM / simple database
→ Automation & workflows
→ Scaling & managing advertisement
→ Email newsletters & updates

For marketing, you need:
→ Monthly YouTube videos
→ Weekly email newsletters
→ Daily LinkedIn posts
→ Ads on Meta, Google, YouTube

For operations, you need:
→ AI Agent workflows.

Setups like these allow small teams to compete with billion-dollar enterprise companies.

And it allows solopreneurs to claim freedom and financial independence.

2026 still has plenty left.
Let's go 🚀

1 month ago | [YT] | 133

Simon Høiberg

Most SaaS advice assumes growth means hiring more humans.

AI makes that advice look old.

A lot of the classic founder advice came from a world where every bottleneck eventually turned into another person, another manager, another meeting, or another tool.

That is changing fast.

Here are 8 SaaS beliefs AI is killing 👇

Skip the Carousel

1 2 3 4 5 6 7 8 9 10

1 month ago | [YT] | 124

Simon Høiberg

Most AI support setups are still way too small.

They answer the ticket.
Maybe summarize the conversation.
Then everyone moves on.

That is fine if all you want is a slightly cheaper support queue.

But the interesting part is what happens before and after the reply.

A good support agent should read the actual context:

Aidbase tickets.
Stripe account state.
Product usage.
Grafana errors.
Docs and internal notes.

Then it should turn the ticket into useful work:

Product issue.
Docs update.
Churn flag.
Weekly pain report.

If support only answers users faster, you still have the same product problems.

The useful setup makes those problems harder to ignore.

1 month ago | [YT] | 91