Why We Chose a Lightweight Architecture for CampusTPO

When building a SaaS application, it's tempting to start with a large technology stack.

Multiple databases, caches, queues, containers, and microservices can all be useful, but they also introduce additional complexity.

While building CampusTPO, we decided to start with a simpler approach: use only the infrastructure we actually need.

Bun + SQLite

CampusTPO uses Bun and SQLite as core parts of its architecture.

SQLite provides a relational database without requiring a separate database server. With WAL mode, it offers a practical foundation for applications that need concurrent database operations while keeping deployment relatively simple.

The important point isn't that SQLite is always the right choice.

It's that technology decisions should be based on actual requirements rather than assumptions about future scale.

Security From the Start

Keeping the stack lightweight doesn't mean ignoring security.

The application incorporates:

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

Authentication is also part of the foundation, including email/password authentication, email verification, Google sign-in, password recovery, and session management.

A Modular Codebase

The application separates responsibilities into clear layers:

Routes
   ↓
Services
   ↓
Repositories
   ↓
SQLite

Routes handle requests, services contain application logic, and repositories handle data access.

This provides clear boundaries without requiring a microservices architecture.

Don't Add Complexity Without a Reason

A queue can be useful when an application needs background processing.

A cache can be useful when there is a real caching problem.

A distributed database can be useful when the workload requires it.

But adding these components before they're necessary creates more configuration, monitoring, deployment, and maintenance work.

Our approach with CampusTPO is to start with a focused foundation and evolve the architecture when actual requirements demand it.

Good architecture isn't about using the most technologies. It's about understanding why each technology exists.