¿Why we choose open source over SaaS and what we built?

Self hosted architecture overview

¿Why we choose open source over SaaS? and ¿what we built?


For many small businesses and independent tech teams, the journey of building a digital presence often starts with a difficult question: "How do we build modern, scalable systems without subscribing to a dozen SaaS tools?"

At iforwhile, a small tech company offering fullstack development and cloud infrastructure services, we faced this challenge early on. Instead of relying on third party platforms with recurring costs, we decided to build everything ourselves using open source tools, a single VPS, and our own engineering.

The result? A fully operational environment with:

  • four production ready websites (Next.js and Angular)
  • three backend APIs (NestJS and Spring Boot)
  • a secure and scalable self hosted authentication system
  • a content delivery backend for a mobile app built in Flutter
  • and infrastructure tooling like MongoDB, Appwrite, CapRover, Docker, and more

Why we choose to go open source and self hosted

There’s no shortage of SaaS platforms promising to make development easier, from authentication services like Firebase to headless CMS tools, email delivery APIs, or PaaS solutions. But most of them come with trade offs: monthly fees, usage limits, vendor lock in, and limited customization.

We chose the open source path because we needed control, flexibility, and long term sustainability.

For a small team like ours, the ability to self host every component, from APIs to databases and email services, gave us two major advantages:

  1. Cost efficiency: We run our entire stack on a single virtual private server (VPS), 4 vCPUs, 8 GB RAM, and 45 GB storage, for a fixed monthly price. That includes all our web apps, backend services, databases, authentication, and more. No per user fees, no usage based pricing.

  2. Full flexibility: We didn’t want to adapt our ideas to third party limitations. By hosting and managing our own services, we can design exactly the architecture we need, including things like:

    • Custom user flows with Appwrite
    • Multiple API backends for different domains
    • Automatic SSL, Docker based deployments, and subdomain routing with CapRover
  3. A learning and leverage opportunity:
    Coming from a consulting background in large scale enterprise systems, we saw this as a way to translate our professional experience into self directed infrastructure. It allowed us to:

    • Apply battle tested best practices to a small scale system
    • Experiment with tools not commonly used in corporate environments
    • Strengthen our understanding of full stack autonomy, from server provisioning to app delivery

This wasn't just an alternative to SaaS, it was a proving ground for our knowledge, and a way to build credibility with solutions we can now confidently recommend to future clients.


What our stack looks like

We host our entire digital infrastructure on a single Ubuntu 24.04 VPS, managed remotely via SSH and DNS configured through our hosting provider. On top of that, we’ve deployed CapRover as our platform as a service (PaaS) layer. CapRover allows us to easily manage deployments, SSL, routing, and Docker containers, all through a clean UI or CLI.

Here’s a breakdown of what we run daily:

Web Applications

We currently manage four web applications:

  • iforwhile web site (Next.js): Our official website for clients and leads
  • iforwhile legacy web site (Angular): A localized version targeting our Chilean audience
  • canticles landing web site (Angular + SSR): A production site for our mobile app project
  • preview client web site (Next.js): A live design preview for a potential client

Each site is deployed as a separate CapRover app, with SSL certificates handled automatically via Let’s Encrypt.

Backend APIs

We’ve deployed three APIs to support our platforms:

  • Contact API (NestJS): Handles submissions from our contact forms and sends templated emails using SMTP
  • Canticles API (NestJS): Powers our mobile app with secure, paginated access to hymnals and song data
  • Demo API (Spring Boot): A sample project to showcase Java based enterprise architecture

Each API is containerized, follows clean architecture principles, and uses validation layers, DTOs, and structured logging.

Identity and Session Management

We use a self hosted Appwrite instance as our authentication and user management provider for the Canticles app. This gives us control over anonymous sessions, OAuth workflows, password recovery, and user data without depending on a third party auth provider.

Data Layer

Our backend services store and query data from a MongoDB instance, also self hosted. To manage it visually, we’ve deployed Mongo Express, making it easier to debug collections and explore the database schema during development.

We’ve also tested and integrated other open source services, such as:

  • Kong Gateway OSS: for service routing and API exposure (demo use)
  • PostgreSQL, MariaDB, Redis: all deployed and running in isolated containers

All of this runs within the same Docker Swarm network managed by CapRover, giving us a clean separation of concerns with fast internal communication and minimal resource overhead.


Final thoughts

By building everything with open source tools and infrastructure we control, we’ve not only saved money, we’ve built a deep understanding of how to run real systems in production, end to end.

This experience has sharpened our ability to offer tailored solutions to clients, especially those looking to scale without becoming dependent on costly external platforms.

For other small teams or independent developers, we strongly believe this path is not only viable, it's empowering.


Let’s talk

Interested in building your digital stack with open source tools and full control? Want to reduce costs without sacrificing scalability? Contact us through our contact form.