How We Built a 20,000-User AI SaaS Product Using an AI-First Development Process

What We Built — Lamblight

Lamblight is a scripture-based AI journaling application. The concept is simple: users write a journal entry, and the app generates a reflective prompt grounded in relevant scripture passages, helping them connect their daily experience to their faith in a way that feels personal rather than generic. The category — spiritual wellness technology — had a real audience, a clear unmet need (existing journaling apps offered no AI-driven reflection layer), and a founder with deep domain knowledge. It was a strong product-market fit hypothesis waiting to be tested with an actual product.

Lamblight came to Automely as a client brief. By the time we delivered, it had cost $95,000 to build, reached 20,000+ users, and was generating $312,000 in ARR. This case study documents the architecture decisions, development process, technical challenges, and lessons from building a production AI SaaS product — not a prototype, not a demo, but a product real users pay for and return to daily.

What AI-First Development Actually Means

There is a meaningful distinction between “SaaS with AI features” and “AI-native SaaS.” In the first, AI is a bolt-on — a chatbot in the corner, a summarisation button, maybe some autocomplete added after the product was already designed. In AI-native SaaS, AI is the product. The entire user experience, data pipeline, and business model are designed around AI capabilities from day one. Lamblight is the second kind. The journaling engine is not a feature of the app. It is the reason the app exists.

AI-first development at Automely specifically means the following. First, Amir and the engineering team use AI tools to generate 70-80% of implementation code — boilerplate, repetitive integration code, test suites, and infrastructure configuration. This is not the same as vibe coding; the senior engineers review, refactor, and govern every output. But the velocity is dramatically higher than traditional development. Second, the AI capability — in Lamblight's case, the journaling engine and RAG pipeline — is architected and built before the product shell. The product wraps around the AI, not the reverse. Third, the evaluation framework is in place before launch. We do not ship without knowing what “good” looks like for the AI output and having automated tests to catch regressions when models update.

6 Architecture Decisions That Determined the Outcome

Every AI SaaS product involves a set of foundational decisions that are difficult to reverse once the build is underway. These are the six decisions that shaped Lamblight's architecture — and the reasoning behind each one.

4 Build Phases — From Brief to Production

Lamblight was delivered across four overlapping build phases — architecture and AI core first, backend and AI engine next, product layer wrapping a proven AI core, and ongoing scale and iteration. The sequencing matters as much as the scope: shipping mobile and web before the AI engine is production-tested is the most common pattern that produces expensive prototypes that break under real usage.

Inside the AI Journaling Engine

The core AI capability in Lamblight is the journaling engine — the system that takes a user's journal entry and generates a scripture-grounded reflective prompt. Here is how the pipeline works in production:

# 1. User submits journal entry (streamed response begins)
user_entry = "Feeling anxious about the job interview tomorrow..."

# 2. Tier 1 — Intent Classification (GPT-4o Mini, temp=0.1)
intent = classify_intent(user_entry)
# → {"emotion": "anxiety", "theme": "uncertainty", "context": "professional"}

# 3. Scripture Retrieval — pgvector semantic search
passages = retrieve_scripture(
    query=build_retrieval_query(intent),
    user_id=current_user.id,  # Strict tenant scoping
    top_k=5,
    min_similarity=0.72
)
# → Philippians 4:6-7, Matthew 6:25-27, Isaiah 41:10 (top 3 returned)

# 4. Personal Context Injection (user's recent journal history)
personal_context = retrieve_user_context(
    user_id=current_user.id,
    lookback_days=14
)

# 5. Prompt Construction
prompt = build_reflection_prompt(
    entry=user_entry,
    scripture=passages,
    context=personal_context,
    tone="warm, grounded, non-preachy"
)

# 6. Tier 2 — Journaling Generation (GPT-4o, temp=0.7, streaming)
async for token in stream_reflection(prompt):
    yield token  # SSE to client — tokens appear in real time

The scripture retrieval precision in production runs at 94% — meaning 94% of retrieved passages are judged contextually relevant by our evaluation suite. The chunking strategy was critical: we chunk by semantic concept boundaries, not token counts. A naive chunk of Philippians 4:6-7 split at a token limit would separate “be anxious for nothing” from “with prayer and petition” — destroying the meaning of the verse for retrieval purposes.

AI Cost Management at 20,000 Users

The most common surprise for founders building AI SaaS products is the AI cost structure at scale. At 20,000 active users with daily journaling habits, controlling per-user AI cost is not optional — it determines whether the business model works. Here is how Lamblight manages it:

• Tiered model routing holds the cost floor. By routing classification and simple tasks to GPT-4o Mini and reserving GPT-4o Full for complex generation, the average AI cost per journaling session is under $0.02. Without routing, the same session would cost $0.08-$0.12 on full GPT-4o — a 4-6× difference that compounds severely at scale.
• Scripture passage caching eliminates redundant embedding operations. The most frequently retrieved passages (the 200 most common scripture responses) are cached in Redis. When a retrieval query returns a cached passage, the embedding and retrieval cost is zero. At 20K users with significant overlap in common emotional themes, this eliminates roughly 35% of vector retrieval operations.
• Usage tiers align revenue with AI cost. The top 10% of Lamblight users (the heaviest journalers) generate roughly 60% of AI cost. These users are on the Premium tier at $19.99/month, which prices in the higher consumption. Free tier users are limited to 3 sessions per week — sufficient to validate the product but structured to drive upgrade conversion rather than unlimited free AI consumption.
• Context window management keeps prompt costs minimal. Personal context injection is capped at the 5 most relevant recent journal entries. System prompts are compressed and cached. Every additional token in the context window costs money at 20K users per day — we treat prompt length as a financial variable, not just a performance variable.

Results — From $95K Build to $312K ARR

Lamblight's commercial outcomes reflect what is achievable when the AI-first development process is applied correctly to a product with genuine product-market fit. The build cost of $95,000 covered the full AI journaling engine, RAG pipeline, iOS app, Android app, web app, subscription management, admin dashboard, and production infrastructure. The $312,000 ARR represents a 3.3× return on build cost within the first year of operation. User growth to 20,000+ users came primarily through organic channels — the daily habit mechanics (streaks, notifications, weekly reflections) driving retention rates that sustain word-of-mouth growth.

The technical outcomes that enabled these commercial results: scripture retrieval precision maintained at 94% across model updates; average AI response latency under 1.8 seconds end-to-end (with streaming, the perceived latency is under 400ms); monthly AI cost per active user under $0.50; zero cross-tenant data incidents since launch. These are not marketing claims — they are the output of the evaluation suite, cost monitoring dashboard, and production observability stack built in Phase 1 before the first user interaction.

8 Production Lessons From Building Lamblight

Eight lessons recur across the Lamblight build — each one is a decision that, made correctly in Week 1, compounds into sustainable unit economics and product quality at scale; made incorrectly, becomes an expensive retrofit later. They are documented below in the order they most affect the outcome.

For the broader context on how AI-first development companies differ from traditional agencies — and how to evaluate any AI development firm before commissioning your product — see our AI development company vs traditional agency guide. For the architecture decision of which AI model approach is right for your product, see our OpenAI API vs custom AI development guide.