Why We Built CampusTPO With a Lightweight SaaS Architecture

When building a SaaS application, it’s easy to assume that more infrastructure means better architecture.

A separate database.

A cache.

Message queues.

Multiple services.

Container orchestration.

All of these can be useful. But adding them before the application actually needs them can also create unnecessary operational complexity.

That was one of the ideas behind CampusTPO.

Starting With a Focused Foundation

CampusTPO is designed as a reusable foundation for authenticated dashboard applications.

Instead of starting with a distributed architecture, the application uses Bun and SQLite with WAL.

This keeps the core infrastructure lightweight while still providing a practical foundation for development.

The application can operate without requiring a separate database server, cache, or message queue.

The principle is straightforward:

Use the smallest architecture that responsibly solves the current problem.

That doesn’t mean avoiding technologies such as Redis, queues, or microservices forever.

It means introducing them when the product has a real requirement for them.

Authentication Built Into the Foundation

Authentication is something that almost every SaaS application needs, but rebuilding the same functionality for every project can take significant development time.

CampusTPO includes:

• Email/password authentication
• Email verification
• Google sign-in
• Password recovery
• Session management
• Account management

This allows future applications built on the foundation to focus more on their actual business functionality.

Security From the Beginning

Security wasn’t treated as a feature to add after everything else was finished.

CampusTPO includes several security mechanisms as part of the foundation:

• Role-based access control
• CSRF protection
• Content Security Policy
• Rate limiting
• Password hashing
• Audit trails

The objective is to establish sensible security boundaries before additional application functionality is introduced.

Keeping the Codebase Modular

A simple infrastructure stack doesn’t mean the application itself should be unstructured.

CampusTPO separates responsibilities using a repository → service → route → view pattern.

Repositories handle data access.

Services handle application and business logic.

Routes handle incoming requests.

Views handle presentation.

This separation helps prevent database operations and business logic from becoming tightly coupled to the user interface.

It also provides a consistent pattern for adding new modules.

Why Avoid Unnecessary Infrastructure?

One of the biggest lessons from the project is that infrastructure should solve problems rather than create them.

A message queue is useful when asynchronous processing requires one.

A cache is useful when caching provides measurable benefits.

Multiple services are useful when independent deployment, scaling, or ownership makes them worthwhile.

A more complex database setup is useful when the application’s workload demands it.

But if none of those requirements exist yet, introducing the infrastructure early means there are simply more components to configure, monitor, secure, deploy, and debug.

That’s complexity without a corresponding benefit.

Let the Architecture Evolve

A lightweight architecture isn’t about refusing to scale.

It’s about scaling the architecture alongside the product.

If CampusTPO eventually requires additional databases, queues, caching, or distributed services, those components can be introduced when the requirements justify them.

Until then, keeping the foundation small makes it easier to understand and maintain.

That is the philosophy behind CampusTPO:

Start simple. Build securely. Keep responsibilities separated. Add complexity when the product actually needs it.

You can explore CampusTPO here:

https://campustpo.com/

CampusTPO — Fast, secure software without unnecessary infrastructure.