EXIST · UnternehmerTUM

2026

Websites that run themselves —
so their owners don't need a developer.

hintergrund.dev 01

Where it started

hintergrund.dev 02

Lesson one

hintergrund.dev 03

Lesson two

hintergrund.dev 04

The insight · 5+ years ago

hintergrund.dev 05

What if my clients could commit to GitHub —
without knowing what Git is?

First version

hintergrund.dev 06

Why rent a server 24/7?

hintergrund.dev 07

Cloudflare Workers

100,000 requests/day free
static files: free, unlimited
then $5/mo → 10M requests

Scaleway Functions

1M requests/month free
+ 400,000 GB-s compute free
then €0.15 per 1M requests

a small business fits in the free tier: 0 €

The next question was infrastructure. My CMS backend does almost nothing almost all the time — it waits for a site owner to save something every couple of months. Renting a server 24/7 to wait for that is absurd — that's the red line: you pay every month whether anyone shows up or not, from around 4 euros for the cheapest VPS, plus all the maintenance we saw. During the IoT Praktikum at TUM I stumbled over serverless architectures — and over how cheap they are. Code that spins up per request, runs for milliseconds, and is billed only for that. Cloudflare gives you 100,000 requests a day for free and serves static files free without limits; Scaleway gives a million requests and 400,000 gigabyte-seconds of compute per month for free. (step) Which means: for a typical small business, the entire infrastructure bill is zero. Not "cheap" — zero. And it scales up smoothly if a site takes off, at 5 dollars for ten million requests. That's the economics that make everything else viable.

The bet

hintergrund.dev 08

Everything a server does can run serverless* *with modest concurrency — which small businesses always have

There was one hard problem: users need to log in. Every auth solution back then assumed a full Node server — long-running process, sessions in memory, open ports. Serverless runtimes are deliberately limited: no state between requests, restricted APIs, milliseconds of CPU. So I built my own auth system for exactly that runtime — stateless, token-based, everything needed for login and permissions, with no server underneath. (step) And doing that taught me the general principle this whole platform is built on: basically everything that works on a server can be transformed into a serverless program — as long as you don't have extreme concurrency. And for my customers, small businesses, that's simply always the case. The asterisk that excludes Google-scale problems is exactly the market I'm serving.

What it became

hintergrund.dev 09

Tech highlight

hintergrund.dev 10

the owner edits

Svelte compiler

running in the browser

real component preview

Instant preview. No build server. No round trip.

Business model

hintergrund.dev 11

typical SaaS

→ rent, forever
→ your data on their servers
→ price hikes, shutdowns,
roadmaps you don't control

hintergrund

→ one-time purchase
→ deploys into your own
cloud account
→ your data, your keys,
your ~0 € infra bill

Software changes too fast to rent it forever.
Own the stack.

The architecture enables a business model I believe in. Software is evolving faster than ever — tools that are state of the art today can be obsolete in a year. In that world, I think people increasingly don't want to rent software indefinitely; they want to own it. Typical SaaS: you pay rent forever, your data sits on the vendor's servers, and you're exposed to their pricing, their shutdown, their roadmap. (step) hintergrund is a one-time purchase, and it deploys into the customer's own cloud account — their Cloudflare account, their keys, their data. And this is only possible BECAUSE of the serverless architecture: since running costs are near zero, owning the stack doesn't burden the customer with an ops bill. A SaaS company has to charge monthly because its servers cost monthly. Mine don't exist. (step) So the pitch is ownership: buy it once, it's yours, it keeps running for free. I'd like to discuss with you how investors and EXIST view a one-time-purchase model — that's one of my questions at the end.

Why now

hintergrund.dev 12

AI made building a website easy. Running one is still hard.

hosting auth database payments email security updates

hintergrund

one platform · pre-integrated · serverless · owned

Where I need your advice

hintergrund.dev 13

product status ~90 %

CMS · shop · email live — in use on real client projects

01 · Launch

How should I go to market — direct to small businesses, or through agencies & freelancers?

02 · Team

Found solo or bring in co-founders — and what does that mean for EXIST?

03 · Model

One-time purchase: how do EXIST & investors see it? Hybrid options?

04 · EXIST

Eligibility, timing of incorporation, TUM mentor — what's the ideal path from here?

max@julius-brantner.de · hintergrund.dev

Where I stand: the product is roughly 90 percent ready. CMS, shop and email are implemented and running on real client projects. What's missing is polish, onboarding, and the launch itself — and that's exactly where I'd like your advice. (step) One: go-to-market. Sell directly to small businesses, or go through the people who build sites for them — agencies and freelancers — as a multiplier? Should I launch with a closed beta from my existing client base first? (step) Two: the team. I've built this alone so far. Should I found solo, or bring in co-founders — for sales and business especially — and how strongly does EXIST weigh a team over a solo founder? (step) Three: the business model. Is one-time purchase viable in the eyes of EXIST reviewers and later investors, or should I plan a hybrid — for example paid major upgrades, optional hosted convenience, or support plans — to show recurring revenue? (step) Four: EXIST mechanics. Am I eligible, when should I incorporate — before or after the funding period — what do I need from TUM as the host institution, and how do I find the right mentor professor? And beyond these: I'd genuinely like to hear which risks YOU see that I don't. Thank you.

What if my clients could commit to GitHub — without knowing what Git is?

Software changes too fast to rent it forever. Own the stack.

AI made building a website easy. Running one is still hard.

What if my clients could commit to GitHub —
without knowing what Git is?

Software changes too fast to rent it forever.
Own the stack.