Learn how to build and scale bootstrapped SaaS with AI, automation, and systems.


Simon Høiberg

I rebuilt my SaaS stack around things I can actually own.

Because if your entire product is sitting on rented abstractions, someone else controls your margins, your data, your scaling path, and sometimes even what you’re allowed to build.

My current self-hosted stack looks roughly like this:

→ Core infra
Hetzner.
Kubernetes.
Docker.
Node.js.

Most of the products run on bare metal with containers and a setup I actually understand.

→ Data layer
Postgres.
pgvector.
Redis.
RabbitMQ.

This is where I want ownership the most. Product data, queues, cache, embeddings, and agent memory should not be scattered across 9 different SaaS tools if I can avoid it.

→ Agent ops
OpenClaw.
n8n.
Cron.
Webhooks.

This is the layer that turns one-off founder work into repeatable workflows. Agents, schedules, scripts, docs, and automation all connected instead of sitting in separate browser tabs.

→ Observability
Grafana.
Prometheus.
Logs.
Telegram alerts.

I don’t want 12 dashboards. I want the system to tell me when something is weird and give me enough context to act.

→ AI compute
Qwen.
Vast AI.
GPU boxes.
vLLM.

Frontier APIs are still best for serious work. I use them. But I also want open-weight models in the stack now, because I don’t think founders should wait until prices explode before learning how to run this stuff.

→ Dev + content
Forgejo.
Git.
Strapi.
MinIO.

More ownership.
Fewer random dependencies.
Lower fixed costs.
Less panic when a platform changes pricing.

Self-hosting used to feel like a weird sysadmin hobby.

In 2026, I think it’s becoming a serious founder advantage.

2 days ago | [YT] | 216

Simon Høiberg

One tiny n8n node makes AI agents way less scary:

Wait.

Most people think of n8n as the thing that runs workflows.

I use it as a proxy layer around OpenClaw.

OpenClaw can decide what needs to happen.
n8n keeps the credentials, API calls, webhooks, and boring execution steps.

So when OpenClaw wants to do something sensitive, it does not get direct access to the API key.

It calls an n8n webhook.
Then the workflow stops.

n8n sends me a form:

Approve this API call?
Here is what the agent wants to do.
Here is the payload.
Here is the endpoint.

If I approve, the Wait node continues and n8n makes the request.

If I ignore it, nothing happens.

That one step changes a lot.

The agent can still move fast.
The credentials stay in n8n.
The risky action is visible before it runs.
And the approval step is just a normal workflow node I can reuse anywhere.

Refunds.
Billing changes.
Posting content.
User exports.
Database writes.

OpenClaw handles the reasoning.
n8n handles the execution.
The Wait node is where I stay in control.

If you are giving agents access to real business systems, this is the kind of boring guardrail you want around them.

3 days ago | [YT] | 149

Simon Høiberg

Most founders give AI agents way too much access way too early.

They connect tools.
Add API keys.
Let the agent touch too many real workflows.

That's a recipe for disaster.

I think about agent permissions more like a ladder.

→ Read-only

This is where I’d start.

Docs.
Logs.
Analytics.

Let the agent understand the business before it can change anything.

→ Draft only

Next step: let it prepare work, but not publish it.

Emails.
Docs.
Replies.

This is useful because the agent can remove a lot of manual work, but humans still decide what actually goes out.

→ Reversible actions

Now it can start doing things.

Scripts.
Tickets.
Webhooks.

But only if the action is logged and easy to undo.

If a mistake creates 5 minutes of cleanup, fine.
If a mistake creates a customer problem, no.

→ Approval required

This is for the stuff that can actually hurt the business.

Deploys.
Billing.
Deletions.

The agent can prepare the work, explain what it wants to do, and ask for approval.

But it should not just go ahead.

This is how I like to introduce agents into a business:

Start with visibility.
Then drafting.
Then reversible execution.
Then gated high-risk actions.

You do not need a fully autonomous AI employee on day 1.

You need a permission system that lets the agent become useful without making the business fragile.

2 weeks ago | [YT] | 147

Simon Høiberg

We're slowly entering a new chatper: Self-hosting AI models is no longer all-or-nothing.

There is now a real middle ground between toy-setups and getting serious work done!

Here's the practical breakdown 👇

→ Qwen3.6-27B

30.5B total params.
3.3B active.
262K context.

Runs in the sane range:
~$0.70/hr on Vast AI with an 80GB-class GPU.

This is the practical entry point for agent work:
Research, sorting, docs, support prep, and simple tool workflows.

Small enough to run without doing anything ridiculous.
Large enough to be worth taking seriously.

→ GLM-5.1

235B total params.
22B active.
256K context.

Now you're in multi-GPU territory:
~$3-6/hr on Vast AI depending on setup and context.

This is where self-hosting starts to hurt a bit.

But for higher-value internal workflows, a few dollars per hour is not crazy if the agent can stay coherent, use tools properly, and finish more work without constant correction.

→ Kimi K2.6

744B total params.
40B active.

This is the high-end setup:
~$12-20/hr on Vast AI with serious multi-H100 infrastructure.

Not the normal founder setup.

But useful as the upper edge of what open-weight agentic models can look like when you stop pretending everything has to run on cheap hardware.

It's a tough balance right now!

We want agents that can use tools, keep context, handle files/APIs, and finish actual work. But we don't want OpenAI and Antrophic to own us forever.

2 weeks ago | [YT] | 122

Simon Høiberg

If you're a tiny team and you want AI agents in production, don't start with the scary stuff.

Don't let the first agent touch billing, refunds, deploys, or anything that can quietly break the business.

Start where being wrong is annoying, not expensive.

My safest first buckets:

Drafting.
Docs, changelogs, emails, social drafts. Easy to edit. Useful even when it's 70% right.

Sorting.
Tickets, bugs, leads, feedback. The agent helps humans find the next step faster.

Research.
Accounts, competitors, docs, call notes. Read-only, high leverage, low blast radius.

Monitoring.
Errors, metrics, mentions, queues. Let it watch, summarize, and wake you up when something looks weird.

This is how I like to introduce agents into a business.

Small scope.
Clear boundaries.
Human checkpoints.

You do not need an autonomous AI employee on day 1.

You need one boring workflow that saves time without creating cleanup work.

2 weeks ago | [YT] | 117

Simon Høiberg

Most founders are still using AI like a browser tab.

Open ChatGPT.
Paste a bunch of context.
Ask for help.
Copy the result somewhere else.
Forget half the process next week.

Useful? Sure.

But it does not compound.

The real unlock for me came when AI stopped being a place I visit, and became part of the system.

Webhooks trigger things.
Cron runs the boring stuff.
Scripts handle repeat work.
Docs and runbooks hold the context.
RAG + vector DB make the knowledge searchable.

Then the agent is not starting from zero every time.

It has rails.
It has context.
It has jobs to run.

If I ask the agent to do something twice, I try to turn it into a workflow.

If I explain something once, I try to turn it into documentation.

If something happens every week, I try to make it automatic.

That is when AI gets interesting.

Not when it writes a slightly better email.

When it starts removing founder drag from the business.

3 weeks ago | [YT] | 151

Simon Høiberg

One thing I think most people get wrong with agents:

They keep trying to make the agent smarter.

I mostly try to make everything around it more predictable.

That is why OpenClaw works so well for me.

OpenClaw sits in the middle, but I have a bunch of very boring infrastructure wrapped around it:

n8n workflows.
Webhooks.
Cron jobs.
Reusable scripts.
Markdown docs.
Runbooks.
RAG + vector DB.

Nothing fancy.

Just the stuff that turns random one-off requests into repeatable systems.

If I ask the agent to do something twice, that is usually a sign it should become a workflow.

If I explain a process once, it should probably be documented.

If something needs to happen every Monday, I should not be remembering it.

That is where the leverage comes from.

The agent uses fewer tokens because it does not need the same context explained 50 times.

The output gets more predictable because the paths are already defined.

And the whole setup gets better every time we turn a messy repeated task into a script, doc, or workflow.

A lot of people are still using AI like a browser tab.

I think the real unlock is when the agent becomes the interface to the systems you already run.

3 weeks ago | [YT] | 153

Simon Høiberg

I run 4 SaaS products with 4 people and 16 AI agents.

No HR department. No middle management. No "team leads" managing other team leads. Just 3 humans who are really good at what they do, and a bunch of agents handling everything else.

Engineering has 2 humans and 6 agents. Support has 1 human and 3 agents. Content, growth, and ops are fully run by agents.

Two years ago this setup would have required 15-20 people and $80K+/month in payroll.

Now it costs me a fraction of that, moves 10x faster, and I actually know what is happening across all of it because the agents report to me directly. No game of telephone through 3 layers of management.

The founders who are still hiring for every function in 2026 are building companies that look impressive on LinkedIn but move like molasses.

1 month ago | [YT] | 213

Simon Høiberg

My deployment pipeline has no keyboard.

I shipped a feature to production last week while enjoying the Swiss nature on a walk with my wife and kids. No laptop. No terminal. Just two voice messages on my phone.

Here is how it works:

I describe what I want to my AI agent in a voice note. Casually, like I am talking to a coworker. "Hey, users are complaining that the dashboard feels sluggish when they have a lot of data. Can you look into it and optimize the heavy queries? Maybe add some caching too."

The agent figures out the rest. Finds the bottleneck, writes the fix, runs it through the test suite, and pings me when it is ready.

I quickly QA from my phone to see if it works, and if it does I just say "ship it."

CI/CD takes it from there. Tests, build, deploy. Done.

Two voice interactions. Everything in between is automated.

Total time from idea to production: usually under an hour.

I think most founders massively overcomplicate their shipping process. Sprint planning, ticket grooming, standups, code review meetings, release windows...

All of that made sense when you had a team of 10 writing code together. But when it is you + AI, all that ceremony just slows you down.

My entire workflow now is:
1. Talk to the agent
2. QA the result
3. Say "ship it"

No Jira. No PRs sitting for 3 days. No "we will ship it next sprint."

The bottleneck is no longer engineering speed. It is how fast you can think of the next thing to build.

If your deployment process still requires you to sit at a desk, open a terminal, and type commands - you are leaving speed on the table.

1 month ago | [YT] | 144

Simon Høiberg

It's 2026, and Micro SaaS is still a massive opportunity!

Yes, use AI.
But use it the right way.

PRACTICAL > HYPE
✅ One problem, one promise, one price
✅ Validate with real users before code
✅ Automate the boring, review the critical
✅ Self-serve onboarding + clear docs

AVOID THE NOISE
❌ Feature soup to chase "everyone"
❌ Vanity metrics over paying customers
❌ Hype hacks without distribution
❌ "AI slop" that replaces human judgment

- Distribution BEFORE development.
- Design UI that sells the value.
- Protect your calendar like equity.

3-STEP MICRO SAAS LOOP
1️⃣ PROVE: Landing + email waitlist + LTD smoke test
2️⃣ BUILD: Tiny MVP with AI-assisted dev, human QA
3️⃣ SCALE: Onboarding polish, trust signals, content engine

SYSTEMS THAT BUY FREEDOM
- Weekly rotation: build → ops → growth → slack
- Automations: n8n for chores, Aidbase for support
- Pricing: monthly, yearly, pay-once for cashflow

1 month ago | [YT] | 175