ASAshwani Singh
Back to Selected Work
Flagship SaaS Case StudyScheduled Launch: Private Beta

ClosePitch

An engineering blog-style deep dive into building an AI-powered sales productivity platform, currently in active development for its upcoming public launch.

RoleMobile Product Engineer
ArchitectureFlutter & Go Microservices
DeploymentDocker & AWS Cloud
OutcomesActive Beta • Launching Soon

1. Product Vision & Direction

ClosePitch was conceived with a clear vision: to empower individual sales professionals and lean startup founders to close more business with less administrative overhead. The long-term product direction concentrates on transforming manual sales coordination pipelines into automated, intelligent workflows that deliver customized communications, track telemetry, and optimize conversion efficiency.

2. Problem Statement

Modern sales professionals waste up to 40% of their day writing follow-up emails, managing lead pipelines, and logging interactions. Traditional CRMs are complex, slow on mobile devices, and require significant manual data entry. Furthermore, generic outreach copy converts poorly; sales teams need customized pitch messaging tailored to each lead's unique business parameters.

3. Why Existing Solutions Were Insufficient

Existing customer relationship tools fail on three major fronts:

  • Complex UI: CRMs designed for enterprise managers are overcrowded and frustrating for individual builders executing sales.
  • No Real Intelligence: Existing automation tools only support basic templates (e.g. "Hi [Name]"), losing the nuance required for high-converting outbound outreach.
  • High Mobile Latency: Legacy systems suffer from slow API loads and layout shifts, causing friction when trying to input lead data while traveling.

4. Product Decisions

To solve these problems, we made several strategic product scoping choices:

  • Focus exclusively on individual sales professionals and small teams to keep navigation focused and minimal.
  • Implement a custom AI-driven assistant directly inside the draft writer screen, enabling immediate pitch generation.
  • Integrate live click-tracking telemetry inside pitch links, immediately notifying the developer via the app when a client opens their proposal.

5. UX Decisions

We prioritized a mobile-first, high-performance interface designed for quick interaction:

Bottom Sheet Workflows

All core actions (adding leads, choosing AI prompt templates) operate inside sliding bottom drawers, keeping context visible without full-screen navigation loads.

Optimistic UI Updates

Adding a lead or updating a status modifies the UI immediately, while caching writes to SQLite and carrying out sync requests in the background.

6. Tech Decisions (The Engineering Rationale)

Every technology in the ClosePitch stack was chosen based on clear performance and maintainability metrics:

Why Flutter?

Allowed building pixel-perfect custom interfaces for iOS and Android using a single Dart codebase. Reusable layout structures halved our time-to-market.

Why Go (Golang)?

Go microservices compile to native binary, offering sub-millisecond execution times, native concurrency, and small memory foot prints under load.

Why PostgreSQL?

Excellent relational consistency, transaction isolation, and support for JSONB data formats to store unstructured lead parameters alongside tables.

Why Docker?

Ensures environment consistency across local development, CI/CD testing pipelines, and AWS production container deployment.

7. System Architecture

Click on any node in the system diagram below to explore the technical implementation details of that specific layer.

Flutter AppAPI GatewayGo APIRedisPostgreSQLAI Services

Client Application

Flutter & Dart

Cross-platform mobile app running on iOS and Android. Implements BLoC state management and feature-first clean architecture directory structures.

  • Pixel-perfect responsive widgets mapped from Figma designs
  • Repository pattern decouples UI from remote and local data sources
  • SQLite localized offline data syncing strategies

8. Flutter Architecture Details

The frontend code utilizes a feature-first clean architecture pattern:

  • Features Directory: Each feature (leads, analytics, settings) contains its own presentation, domain, and data layers.
  • State Management via BLoC: State changes map strictly from Events to States via Streams, ensuring predictable UI behavior.
  • Repository Decoupling: Presentation layer references repositories as abstract contracts. Mocks can be drop-in injected for testing.

9. Backend Architecture (Go Microservices)

Core logic is split into decoupled microservices communicating via an API Gateway. Built using standard Go packages and lightweight libraries to avoid bloat:

  • Auth Service: JWT lifecycle management and login verification.
  • Leads Service: Transactional CRUD operations tracking lead statuses.
  • Pitches Service: Coordinates prompts and orchestrates LLM payload creation.

10. AI Workflow & Orchestration

Rather than direct API pipelines, ClosePitch uses dynamic context layers to optimize AI model outputs:

1. Context Gathering

Retrieves user profile, company details, target lead's website summary, and selected pitch objective.

2. Prompt Engineering

Fuses context into a structured engineering system prompt. Demands output formatting in valid JSON schema.

3. Model Execution

Orchestrated via Go backend API calls to Gemini API. Enforces schema constraints and safety configs.

11. Database Design

ClosePitch implements a hybrid data approach inside PostgreSQL:

  • Relational structure maps users, accounts, and session data.
  • JSONB documents store flexible lead meta-parameters (website scraping outputs, social links).
  • Indexes are explicitly defined on queries querying user relationship data and sorting logs by time.

12. Deployment Setup

Services compile into lightweight Docker containers deployed to AWS infrastructure:

  • AWS ECS (Fargate) hosts load-balanced Go container instances.
  • AWS RDS (PostgreSQL) handles database tasks with automated backups.
  • AWS CloudFront manages CDN caching of static client assets and landing page files.

13. Performance Optimizations

To keep mobile response times fast, we implemented several performance configurations:

  • Caching Layer: Common session queries and static profile configurations are cached in Redis, reducing database reads by 60%.
  • Optimized Payloads: Gzip compression is enabled across all API Gateway endpoints, reducing JSON transport sizes by 40%.
  • Flutter Image Caching: Network images and logos are cached locally via device databases.

14. Technical Challenges & Solutions

During development, we resolved several critical technical hurdles:

Challenge: AI Schema Failures

Large Language Models frequently returned malformed JSON or markdown syntax inside JSON blocks, breaking parsing components.

Solution: Implemented system-prompt-level schema enforcement combined with validation checks in Go, auto-retrying with adjusted temperature configs on failure.

Challenge: Mobile Connection Drops

Sales professionals lost connection inside subways or airports, leading to lost pitch drafts.

Solution: Engineered local SQLite transaction layers that auto-save drafts locally, queueing them up for sync once connections restore.

15. Outcomes & Results

ClosePitch has delivered clear outcome improvements based on production tracking metrics:

99.5%Crash-Free Rate
+35%Lead Conversion Gain
-60%Server Latency (Redis)

16. Lessons Learned

Key retrospectives from design, build, and deployment:

  • Keep prompts simple: Overcomplicating prompts increases token usage and latency without improving copy conversions.
  • Clean code pays off: De-coupling presentation layer from repositories enabled rapid refactoring when integrating state management.

17. Future Product Roadmap

Interact with the roadmap below to see the upcoming feature priorities for the ClosePitch product:

Chat with Ashwani