Dario_le's PingMon: Lean Stack Choices for Solo SaaS Efficiency
Founder Dario_le reports building API monitoring tool PingMon with FastAPI, SQLite, and a Telegram bot. This lean technical stack enables high performance on minimal infrastructure for solo…
Founder Dario_le reports building API monitoring tool PingMon with FastAPI, SQLite, and a Telegram bot. This lean technical stack enables high performance on minimal infrastructure for solo developers.
Dario_le, a mechanical engineer turned founder, launched PingMon, an API monitoring SaaS, by prioritizing a lean technical stack. The founder claims this approach allows PingMon to perform 10,000 checks per day on a single $6 Hetzner VPS, demonstrating a direct correlation between specific technology choices and operational efficiency for a solo-built product.
FastAPI for Asynchronous Performance
Dario_le selected FastAPI over Django or Flask due to its native asynchronous capabilities. The core function of an API monitoring tool involves making numerous HTTP requests, a task that benefits significantly from non-blocking I/O. Asynchronous operations prevent performance bottlenecks that would arise from traditional blocking I/O when checking hundreds or thousands of endpoints.
The founder implemented an async loop that runs every minute for Pro users and every five minutes for free users. This setup, leveraging aiohttp.ClientSession, allows the system to handle the reported 10,000 daily checks without performance strain on a low-cost virtual private server. The choice of FastAPI directly addressed the I/O-bound nature of the application from the outset, avoiding complex ASGI configurations or additional libraries.
SQLite for Database Simplicity
Against conventional advice, Dario_le chose SQLite for PingMon's database. The primary justification was operational simplicity: SQLite eliminates the need for a separate database server, connection pooling, or complex backup scripts. The database resides in a single file, simplifying backups to a cron job.
Dario_le reports SQLite handles approximately 50 concurrent writes per second, which is sufficient for PingMon's workload, where each check is a single INSERT and dashboard operations involve a few SELECT statements. The critical configuration for production stability was enabling WAL mode (PRAGMA journal_mode = WAL;) and setting a busy_timeout to prevent locks and corruption. The founder states this configuration has run in production for weeks without issues, deferring a switch to PostgreSQL until reaching 100 or more concurrent users.
Telegram Bot for Alerts
Instead of developing a traditional email notification system, Dario_le integrated a Telegram bot for alerts. This choice bypassed common email deliverability issues, SMTP configuration, and spam filters. The implementation requires sending a simple POST request to Telegram's API with a chat_id and message text.
The founder claims users can connect their Telegram accounts within 30 seconds. This method provides immediate, reliable notifications with minimal development effort. The simplified alert system avoids a common point of complexity and failure for early-stage SaaS products.
Schema Simplicity and Async-First
Dario_le emphasizes two key lessons: maintaining a simple database schema and embracing asynchronous programming from the start. The initial PingMon schema began with three tables, expanding only when necessary, avoiding premature optimization. The founder advises against fighting async, noting that converting synchronous code to asynchronous later in development is a painful process. The initial version of PingMon was a 200-line Python file, proving that shipping a simple, functional core is more critical than complex architecture in early stages.
What We'd Change
While the lean stack proved effective for PingMon's initial phase, several aspects would require modification for sustained growth or increased resilience. SQLite, despite its simplicity, presents inherent scalability limitations beyond the reported 50 concurrent writes per second. As user concurrency or data volume grows, the single-file database will eventually become a bottleneck for complex queries or high-throughput operations, necessitating a migration to a more robust RDBMS like PostgreSQL.
The reliance on a Telegram bot for all alerts, while simple, limits user choice. Not all users prefer or use Telegram, potentially excluding a segment of the target market or requiring additional notification channels (e.g., email, Slack, webhooks) as the product matures. This could introduce the very complexity the initial choice sought to avoid.
Operating on a single $6 VPS, while cost-effective, introduces a single point of failure. For a monitoring tool, which inherently needs high availability, this setup lacks redundancy. Future iterations would require considering load balancing, database replication, and multi-region deployments to ensure continuous service and protect against infrastructure outages.
Landing
Dario_le's approach with PingMon illustrates how specific, deliberate technical choices can enable solo founders to launch and operate functional SaaS products with minimal resources. The success hinges on understanding the application's core demands—heavy I/O, simple data storage, and reliable notifications—and selecting tools that directly address those needs without introducing unnecessary complexity. This strategy prioritizes rapid iteration and operational lean-ness, proving that sophisticated functionality does not always demand an equally complex underlying infrastructure in the early stages of a product lifecycle.
The investor read
Dario_le's PingMon highlights the viability of lean technical stacks for micro-SaaS in the monitoring space. The ability to handle 10,000 daily checks on a $6 VPS signals extremely low operational costs, enabling high-margin, bootstrapped growth. While the current setup is a lifestyle play, an investor would look for a clear path to enterprise features (e.g., advanced alerting, team collaboration, multi-region deployment, robust database scaling) and a move beyond Telegram-only notifications to broaden market appeal. The technical choices demonstrate strong founder efficiency and resourcefulness, but the product's investability hinges on its ability to evolve beyond a solo-developer-optimized architecture to serve larger, more demanding customer segments.
Pull quote: “The founder claims this approach allows PingMon to perform 10,000 checks per day on a single $6 Hetzner VPS, demonstrating a direct correlation between specific technology choices and operational efficiency for a solo-built product.”
Every claim ties to a primary source. See our methodology.