EventCompass: Hard-Learned Lessons from AI-Driven Indie Development

Over the last 3 month I create EventCompass, my frist SaaS from scratch. With EventCompass, I wanted to build a complete product on a strict budget while leveraging modern AI. I never really used AI before so this was a interesting experience especiall cause I wanted to managing cost discipline but still generating an awesome app.

Here are the key takeaways from my journey.

1. Manage Tokens as a Precious Commodity

AI models generate code quickly, but raw token usage gets expensive fast. Spending tokens inefficiently hurts both your wallet and project structure. So before even starting

• Write down your idea: Clearly define and document your core concept before opening an IDE or triggering AI model prompts. Having a single source of truth prevents scope creep and wasted iterations. Ensure important decisions along the way are reflected in these documents. For example my Styleguide was updated several times.
• Target Market & Legal Requirements: Know your target market from day one. If you operate in or target the EU, investigating legal issues like GDPR is mandatory before locking in your data structures and user consent flows. Write them down aso you can feed it to your AI as input.
• Spec-First Development: Before letting AI implement features, use tools like speckit to write clear design docs, architectural plans, and specifications.
• Review Before Implementation: Always review and approve the written specs manually before letting the AI write the code. Catching mistakes early saves thousands of tokens.
• Static Security Scanning: Integrate tools like GitLab SAST into your pipeline to detect security issues early.
• Manual Usability Testing: AI cannot feel UX friction. Thoroughly test your app manually to find usability flaws and edge cases.
• Make Repetitive Tasks Automated: Don’t waste AI tokens on manual tasks like updating demo videos or feature images. I fully automated these updates using Playwright E2E test playbooks, which generate updated assets reliably on every pipeline run.

2. CI/CD Discipline: Homelab Runners and Smart Pipelines

I love gitlab and their free tier offers amazing capabilities. However, the default 400 shared CI minutes run out quickly. To keep pipeline usage and cloud spending completely under control:

• Self-Hosted Homelab Runners: I set up my own GitLab Runner inside my homelab. This lifts arbitrary CI execution limits and gives me full hardware performance for builds and tests without paying for compute minutes.
• Selective Deployments: Not every git push needs a trip to staging. Optimize pipeline rules to run linting and unit tests on branches, reserving full E2E testing and staging deployments for specific triggers (like merges to main or manual pipeline releases).
• Catch Failures Early with Git Hooks: There is nothing more annoying than pushing code only to watch it fail in CI due to simple lint errors or broken unit tests. Use local pre-commit git hooks so tests execute locally before the push ever happens.
• Local Secret Scanning: Run local secret scanning in your pre-commit hooks to flag secrets or eliminate false positives before they break the remote CI pipeline.

3. Architecture Evolution: Reducing Latency and Costs

Hosting choice heavily affects both performance and hosting bills:

• Usage Estimation: Always run rough estimates on traffic and API calls early on to avoid unexpected cloud charges as usage grows.
• Vendor Lock-In vs. Portability: Edge platforms (Cloudflare Workers, Lambda@Edge) are fast to start, but proprietary features like KV or D1 lock you in. Decouple your core logic and database access with clean interfaces so you can move away if needed.
• Cold Starts & DB Connection Limits: Serverless functions have cold start delays on quiet endpoints. Traditional databases (Postgres/MySQL) also struggle with thousands of short serverless connections, so use a connection pooler to avoid hitting DB limits and burning compute money.
• Always-On vs. Per-Request Pricing: VMs and containers charge you continuously even with zero traffic. Edge/Serverless charges strictly per request and execution time—great for low or bursty traffic, but heavy background processing will cost you.
• Data Sovereignty & Cross-Border Latency: Keeping compute globally distributed at the edge while keeping user data locked to an EU region for GDPR compliance can introduce hidden cross-border latency if not planned properly.
• Capping Auto-Scaling Costs: Uncapped auto-scaling protects uptime, but a sudden traffic spike or bot attack can result in a massive bill. Set hard limits on max instances, configure budget alerts, and use rate limiting at the edge.

My architecture went through three iterations before finding the sweet spot:

[ GCloud VM + Container + Aiven DB ]
        │ (Requires Load Balancer to scale + network delay)
        ▼
[ Cloud Run + Aiven DB ]
        │ (Scales better, but network latency to DB remains)
        ▼
[ Cloudflare Workers + D1 ]
        └──> Co-located compute & edge database

• GCloud VM + Containers: Setting up containers on a VM works initially, but scaling requires an added Load Balancer. Additionally, querying an external database (Aiven) introduced network latency hops, even in the same region.
• Cloud Run: Solved the scaling issue automatically, but the network delay to the external database remained an annoyance.
• Cloudflare Workers + D1 SQLite: Running compute and database together on Cloudflare Workers solved the network delay entirely. Combined with their generous free tier, this turned out to be the most cost-effective and responsive setup.

4. Testing Realities: Local Environments vs. Staging

Testing locally before pushing code is essential, but it often masks real-world production issues:

• The Local Stack Fallacy: Early on, I used SQLite locally while running Aiven Postgres on staging. A divergent stack locally hides subtle SQL dialect issues and behavioral differences.
• Network Latency Is Invisible Locally: Running everything on localhost feels instant. It isn’t until you push to a staging environment with real network boundaries that multi-hop database latencies and network delays actually reveal themselves.
• Regular Staging Verification: Test your app regularly in local dev, but always validate on a staging environment that mirrors your production architecture.

5. Pragmatic Model Choices & Cost Management

You don’t need top-tier closed models for every development step. I currently use ollama-cloud. Considering my cost discipline the following I applied:

• Leverage Budget & Open Models: Using providers like Ollama Cloud or high-performing open models delivers great coding results at a fraction of the cost.
• Cross-Model Code Reviews: Run automated code reviews periodically using different LLMs to catch edge cases, bugs, or bad practices that the primary model missed.

6 Security, Usability, and Legal Compliance

• Static Security Scanning: Integrate tools like GitLab SAST into your pipeline to detect security issues early.
• Manual Usability Testing: AI cannot feel UX friction. Thoroughly test your app manually to find usability flaws and edge cases.
• Legal Setup (GDPR): Address privacy rules, data processing, and GDPR compliance early before committing to restrictive data structures.

Summary

Building EventCompass proved that AI can significantly accelerate development—provided you govern it with specs, automated E2E tests, static analysis, and a lean edge architecture.

If you’re starting a similar project: start small, assign features to milestones, monitor your infrastructure spending, and keep your critical workflows repeatable.