Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for QuotePilot

Inspiration

I'm a freelance full-stack developer I run my pre-sales process across Fiverr, Upwork, and direct client work every week. The pattern is always the same: a vague inquiry comes in, I have to figure out what they actually need, ask clarifying questions, dig through old projects for a fair price comparison, draft a quote, and chase it through revisions until it's approved. It's repetitive, error-prone (arithmetic mistakes on quotes are embarrassing), and it's the kind of workflow that either gets done sloppily under time pressure or eats hours that should go into actual delivery work.

When I saw the Autopilot Agent track, this was the obvious thing to build: an agent that runs my own pre-sales pipeline, but stops and asks a human before anything goes out the door.

What it does

QuotePilot takes a raw client inquiry and walks it through a full pipeline:

  1. Classify & extract: structured requirements pulled from freeform text (budget, scope, timeline, platform) using Qwen's deep reasoning model, validated in code.
  2. Ask clarifying questions:if the inquiry is too vague to quote confidently, the agent drafts 2-3 plain-language questions and emails the client directly.
  3. Retrieve similar past work: semantic search over my own service catalog and project history (pgvector embeddings + a rerank pass) to ground the quote in real precedent, not guesswork.
  4. Draft a priced quote:line items, assumptions, and a total, with all arithmetic verified in code rather than trusted to the model.
  5. Pause for human approval: this is the core of the track. Nothing goes to a client without me clicking approve in the dashboard.
  6. Revise on rejection: if I reject with feedback, the agent drafts a new version incorporating it.
  7. Send on approval: renders a real PDF, emails the client with the total and a booking link, logs everything to a full audit trail.

Every step is visible in a dashboard with a reasoning trace model used, tokens, latency, and a plain-English summary of what happened so approving a quote isn't a leap of faith.

How I built it

  • Backend: Node.js/TypeScript, Express, running as a single process an API for the human-in-the-loop actions, and a background worker that polls every 5 seconds to advance any inquiry not currently waiting on a human or a client.
  • Models: Qwen's larger reasoning model handles extraction and quote drafting/revision (the slow, high-stakes steps); a faster, cheaper model handles classification and clarifying-question generation. Embeddings and a separate rerank endpoint power the retrieval step.
  • Database: PostgreSQL with pgvector for similarity search, fully versioned quotes and a step-by-step event log for every inquiry.
  • Frontend: A React/Vite dashboard, designed first as a mockup and rebuilt as real components wired to the live API dark navy/teal, built to feel like a real internal tool, not a hackathon demo.
  • Tools: PDF generation (pdf-lib) for real, attachable quote documents; email delivery (Resend) for clarification and quote-sent messages, with a clean stub mode so the whole pipeline still works and is testable without a live email key.

The whole thing runs on Alibaba Cloud Express serves both the API and the built dashboard from one process on an ECS instance, talking out to Qwen Cloud's OpenAI-compatible API for every model call.

Challenges I ran into

  • State machine discipline. Every status transition goes through a single guarded function that throws on illegal transitions this caught several bugs early rather than letting the agent drift into an inconsistent state silently.

  • Treating tool failures as loud, not silent. Email and PDF generation are the agent's "hands" a failure there is worse than a failure in reasoning, because nothing tells you it happened. Every tool call is wrapped so a failure flips the inquiry to a failed status with a clear logged event, rather than hanging or pretending to succeed.

  • Arithmetic trust. Quote totals are never trusted to the LLM's output directly they're recomputed and verified in code before being stored or sent, since a wrong subtotal in a real quote is a real problem, not a cosmetic one.

  • Deploying to Alibaba Cloud for the first time. I'd never used anything beyond shared hosting before this. Getting a real ECS instance provisioned, the security group opened correctly, the environment recreated safely (without ever committing secrets), and the process kept alive with pm2 across reboots was a genuine first and a good one, since it forced me to actually understand what "deploying a backend" means rather than relying on a host that does it for you.

  • A git branch mismatch that nearly cost the deployment. My local default branch and the one GitHub had set as default diverged silently, which meant an early deploy attempt pulled an almost empty repo. Tracing that down was a useful reminder to verify a fresh clone before trusting it, rather than assuming a push succeeded just because it didn't error loudly.

What I learned

Building the human-in-the-loop gate forced a different design mindset than a fully autonomous agent every step needed to produce something a non-technical person (a future client of mine, or a judge) could glance at and trust or distrust in seconds. That meant investing as much in the audit trail and dashboard clarity as in the agent logic itself. I also got real, hands-on experience with cloud deployment fundamentals ECS, security groups, process managers that I'd been meaning to learn for a while and finally had a concrete reason to.

What's next

Real usage on my own freelance pipeline is the actual goal here this isn't just a demo, it's the pre-sales tool I intend to keep running for my own client inquiries going forward. Next steps are broader test coverage of edge cases (multi-service inquiries, non-English input), and tightening the retrieval step as my own catalog of past projects grows.

Built With

Share this project:

Updates