What We Learned Building CampusTPO With a Lightweight SaaS Stack
Building a SaaS product doesn't always mean starting with a complicated infrastructure.
While working on CampusTPO, we took a different approach: build a focused foundation first and introduce additional infrastructure only when the product actually needs it.
Starting With a Simple Architecture
CampusTPO is built around Bun and SQLite, keeping the initial infrastructure lightweight.
Bun provides native SQLite support through bun:sqlite, including prepared statements, transactions, and other database capabilities. oai_citation:0‡Bun
For an application at this stage, this means we don't have to immediately operate a separate database server just to get the core product running.
The goal isn't to claim that SQLite is the answer for every SaaS application.
It's about choosing infrastructure based on actual requirements.
Security Still Comes First
Simple infrastructure doesn't mean simple security.
CampusTPO includes authentication and account-management capabilities such as:
- Email/password authentication
- Email verification
- Google sign-in
- Password recovery
- Session management
- Account management
The application also incorporates security controls such as:
- Role-based access control
- CSRF protection
- Content Security Policy
- Rate limiting
- Password hashing
- Audit trails
The idea is to keep security part of the architecture from the beginning rather than treating it as a final step.
Keeping Responsibilities Separate
Another important part of the project is how the codebase is organized.
The application separates:
Routes → Services → Repositories → Views
Routes deal with incoming requests.
Services contain application and business logic.
Repositories handle data access.
Views handle presentation.
This separation makes the codebase easier to understand and helps prevent business logic from becoming tightly coupled to the interface.
Why Not Start With Microservices?
This was probably one of the most important architectural decisions.
It's easy to add Redis, message queues, multiple databases, containers, and microservices because they are common in larger SaaS systems.
But every additional component also creates another thing to deploy, monitor, debug, secure, and maintain.
If a product doesn't need a particular system yet, adding it can create complexity without solving an actual problem.
That doesn't mean we will never use these technologies.
If CampusTPO grows to the point where a queue, cache, separate service, or different database becomes necessary, the architecture can evolve.
The Principle We're Following
The biggest lesson from building CampusTPO has been:
Infrastructure should follow requirements, not trends.
Start with a solid foundation.
Keep the system understandable.
Build security into the application.
Measure what the product actually needs.
Then add complexity when there's a real reason to do it.
That's the approach we're taking while building CampusTPO.
You can explore the project here:
Top comments (0)