Why I Built My Own SaaS Stack

The Problem Every SaaS Developer Knows

Every SaaS project starts the same way. You have a brilliant product idea, open your editor, create a new repository — and then spend the next four to six weeks building the same foundations: user registration, email verification, login, password reset, payment integration, subscription management, role system. Only then can you actually start working on your idea.

I went through this three times. Wrote the same code three times. Implemented the same Stripe webhooks three times. Set up the same OAuth2 flows three times. The third time around, I asked myself: why am I doing this from scratch every single time?

The problem is not that solutions do not exist. There is Auth0, Clerk, Firebase Auth, Supabase — all good services. But they only solve part of the problem. And once you run multiple products that should operate under a shared brand, things get complicated. I wanted a user to sign up once with IT-Trail and then seamlessly switch between Atoo Studio, SiteHorse, and future products. No third-party provider offers that out of the box.

The Decision: Build Once, Reuse Forever

Before I started building SiteHorse.ai, I made a deliberate decision: invest four weeks into a solid foundation. Not into a product that makes money. Not into a feature that customers see. Into infrastructure. Into the boring parts that nobody notices when they work — and that bring everything crashing down when they do not.

It was not an easy decision. As a solo founder, every week counts. Investing four weeks into something that generates no direct revenue feels like a gamble. But I knew from experience: the alternative — starting from scratch every time and making different small mistakes each time — is more expensive in the long run.

What Is in the IT-Trail SaaS Stack?

The stack is the complete foundation that every one of my SaaS products needs. At its core, it consists of several modules that can be used together or independently.

OAuth2-Based Single Sign-On

The centerpiece is a full OAuth2 server that serves as the central identity layer for all IT-Trail services. A user registers once and can then sign in to any product built on the stack. Atoo Studio, SiteHorse, future products — one identity, one login.

It sounds simple, but the implementation is anything but. OAuth2 is a complex protocol with many flows: Authorization Code with PKCE for web applications, Client Credentials for service-to-service communication, Refresh Tokens for long-lived sessions. I implemented all relevant flows and deliberately avoided libraries like Passport.js because I wanted full control over the token lifecycle.

User Registration and Social Login

Registration supports classic email sign-up with verification as well as social login via Google and Microsoft. Microsoft was particularly important because many business customers want to sign in with their Azure AD account. Integrating both providers turned out to be surprisingly different — Google is straightforward and well-documented, while Microsoft requires significantly more configuration work and has subtle differences in token validation.

Payment Integration: Stripe and Paddle

Here I made a pragmatic decision: I support both Stripe and Paddle. Why two payment providers? The answer is simple: taxes.

Stripe is the gold standard for payment processing. The API is excellent, the documentation first-class, the webhook integration reliable. But Stripe is a pure payment processor — as a business, I am personally responsible for correct VAT handling in every country where I have customers. As a solo entrepreneur in Austria, that is an administrative nightmare when selling globally.

Paddle, on the other hand, is a Merchant of Record. This means Paddle technically sells to the end customer and handles all the VAT complexity. They take a higher cut for it. For B2C products with many international small customers, Paddle is often the better choice. For B2B with fewer but larger customers, Stripe is more efficient.

In the stack, I built an abstract payment layer that hides both providers behind a unified interface. Each product can decide which provider to use — or even both simultaneously for different pricing plans.

Role-Based Access Control

The permission system is deliberately kept simple: users have roles, roles have permissions. No nested groups, no complex policies. For the products I currently build, that is enough. But the system is designed so it can be extended when needed.

TypeScript End-to-End

The entire stack is written in TypeScript — backend, shared types, utility libraries. This was a deliberate choice. TypeScript gives me type safety across the entire codebase. When I rename a field in the User object, the compiler immediately shows me every place that needs updating. For a system that forms the foundation for multiple products, this safety is invaluable.

How the Investment Paid Off

SiteHorse.ai — my AI-powered website builder — was built in six weeks. Six weeks from the first line of code to public launch. Without the SaaS Stack, that would have been simply impossible.

From day one, SiteHorse had working login, registration, email verification, Google sign-in, Stripe integration with multiple pricing tiers, and a role system. I did not have to write any of that — I just plugged it in. I could focus entirely on what makes SiteHorse unique: the AI-driven website generator, the template engine, the visual editor.

Architecture Decisions

Some decisions deserve a closer look.

Why OAuth2 instead of a simpler solution? JWT-based sessions would be perfectly adequate for a single product. But I am not building one product — I am building an ecosystem. OAuth2 gives me standardized flows for cross-service authentication that any client understands. If a mobile client comes along tomorrow, I do not have to change anything.

Why a modular monolith? I deliberately did not build microservices. The auth server, payment integration, and user management are separate modules in a single repository. They share types and utilities but are deployed independently. This gives me the simplicity of a monolith during development and the flexibility of services at deployment time.

Open Source Plans

The IT-Trail SaaS Stack is currently a private repository. But I plan to release it as open source. My conviction: good infrastructure should not be a competitive advantage. The value lies in the products built on top of the foundation, not in the plumbing underneath.

Before that happens, though, I still need to clean up a few things. Write documentation. Create configuration examples. Make sure no secrets are in the code or in the Git history. Open source also means responsibility — especially with security-critical code like authentication and payment processing.

Lessons Learned

What did I learn from this project?

Do not rebuild what you have already built. It sounds obvious, but the urge to do it “right this time” is real. Yes, the code from two years ago is not perfect. But it works and it is tested. Refactoring is more sensible than a complete rewrite.

Invest in foundations early. The boring parts — auth, payments, user management — are exactly the parts that bite you hardest when they are poorly built. A bug in authentication is not a feature request you can postpone. It is a security incident.

Keep it simple until you have a reason for complexity. My role system has three roles. My OAuth2 server supports two grant types. My payment system has two providers. That is enough. When I have five products and requirements grow, I can extend. But until then, I do not build infrastructure for problems I do not yet have.

The IT-Trail SaaS Stack is not a glamorous project. There is no impressive demo, no wow effect. But it is the reason I can build SaaS products in weeks instead of months. And that is worth more than any feature.