The first weeks of building Stackbastion in public

I keep meeting the same person. They built an app with an AI tool, it worked, real people started using it, and then one morning it broke and they had no idea what to do. No backup they trusted. No logs they could read. No one to call. Just a live app, some upset users, and a sinking feeling.

Stackbastion exists because of that person. This post is an honest snapshot of where the business actually is right now, not a highlight reel. We’re early. I’d rather tell you the truth than sell you a story.

Where things actually stand

Let me be plain about the stage, because a lot of “building in public” posts blur this on purpose.

Stackbastion is pre-revenue. No paying customers yet. The thing you’re reading this on is the marketing site, and most of what surrounds it right now is a plan: the backlog, the pricing, the launch sequence, the runbooks. The customer-facing product, the part that actually runs your app on real servers, is being built as the plan gets executed.

I’m telling you this up front because trust is the whole product here. If I fudge the stage now, why would you believe me when your database is on fire?

Why this, and why me

I’ve spent 15 years building and running web apps. The pattern I keep seeing is new: people who aren’t developers are now shipping real software with AI tools, and it works well enough to get users. That’s genuinely great. But “works in the demo” and “survives a bad Tuesday” are different things, and nobody warns them about the gap.

The gap is boring stuff. Backups that have actually been restored once. A database that won’t fall over at 300 users. Logs you can search when something breaks. A person who answers when it does. None of that is exciting. All of it is the difference between a scare and a disaster.

Big cloud platforms assume you have a DevOps team. AI app builders assume you’ll never leave their walled garden. The person in the middle, the one with a real app and no ops knowledge, has nowhere good to go. That’s the wedge.

What “in public” means here

Building in public can turn into theater. Screenshots of graphs going up, vague “big things coming” posts, numbers with no context. I want to avoid that.

For me it means a few concrete things:

• Real numbers or none. When I share a metric, it’ll be a real one. If I don’t have it yet, I’ll say so rather than invent a round number that sounds good.
• Decisions with the reasoning attached. When I pick a tool or a price, I’ll show the trade-off I made, including the downside. A decision without its cost is just a slogan.
• The mistakes too. The point of doing this in the open is that other people learn from the wrong turns, not just the wins.

The reason isn’t that transparency is a nice brand value. It’s that the customer I want is scared of exactly the thing I’m asking them to do: hand their app to a stranger. The only way through that fear is to show my work.

The first real decisions

A few calls are already made, and they tell you how I think.

The product runs on Hetzner, not AWS. Own Postgres, Docker, Caddy in front, backups I control. The big clouds are built for teams who can afford their complexity and their bill. My customers can’t and shouldn’t have to. I wrote up the full reasoning in why we chose Hetzner over AWS, GCP, and Azure.

This website is not on Hetzner. The marketing site is a static site, and it’s deployed on Railway. That surprises people, so I explained the split in how we host this site. Short version: the site and the product are different jobs, and using the same tool for both would be dogma, not sense.

We start narrow. For the first six months, Stackbastion supports Lovable apps and generic Git-repo imports, and that’s it. Not because other platforms don’t matter, but because doing two things well beats doing eight things badly. A managed-ops promise you can’t keep is worse than no promise.

None of these are locked forever, but each one was a real choice with a real cost, and I’d rather be narrow and honest than broad and vague.

What I’m scared of

Fair to name the risks, since I’m asking you to watch this play out.

The biggest one is trust at the worst moment. Managed hosting is a promise that when things break, I’ll be there and I’ll be good. That promise is easy to make on a landing page and hard to keep at 3am. The whole business lives or dies on keeping it.

The second is being early. The market of “non-technical founders with an outgrown AI app” is real and growing, but it’s new. Some of these people don’t yet know they need what I’m building until the day it breaks. Educating a market is slower than serving one that’s already shopping.

I don’t have these solved. I have a plan, a stack I trust, and a bias toward telling the truth. That’s the starting position.

If you’re the person in the first paragraph

If you built something that works and you’re quietly worried about the day it doesn’t, that worry is the correct instinct. Most AI-built apps are one bad traffic spike or one fat-fingered delete away from a very bad afternoon.

You don’t have to hire me to fix that. But you should at least know where you stand. That’s what the free audit is for: I look at your app’s backups, database, logs, and security, and tell you plainly what would hurt if it broke tomorrow. No pitch attached to the findings. Just the honest picture, which is the same thing I’m trying to give you about the business itself.

FAQ

Is Stackbastion actually live and taking customers?

The marketing site is live. The managed product is being built as the plan executes, and it’s pre-revenue right now. The most useful thing available today is the free audit, which works whether or not you ever become a customer.

Why build this in public instead of quietly?

Because the customer I want is nervous about handing their app to a stranger, and the only cure for that is showing my work. Doing it in the open forces honesty and lets people judge me by my reasoning, not my marketing.

Who’s behind it?

One person, for now. I’ve been building and running web apps for over 15 years. Stackbastion ships as a sub-brand of AKTAI LTD, a UK company. More on the why in the about page.

What does “vibe-coded” mean?

It’s the affectionate term for apps built by describing what you want to an AI tool rather than writing the code yourself. Lovable, Cursor, Bolt, Claude Code, and similar. These apps can be genuinely good. They just rarely come with the boring operational safety net a real production app needs.