build.allanninal.dev

Part 1 of 7 · Proposal generator series ~5 min read

A proposal generator on AWS for a few dollars a month

A small business wins work on proposals, and the good proposals take hours nobody has. A prospect calls on Tuesday, loves the chat, and asks you to “send something over.” By Friday the thread has gone cold because the blank page won. You already know what you’d write — the cover, the bit where you show you understood the need, the approach, the timeline, the price — because you’ve written it forty times before. This post walks through the design of a small system that takes a few notes from you, drafts the whole proposal in your voice from your own past work, and hands it back for you to edit and send. Nothing goes to a client without your sign-off.

Key takeaways

  • Three ways to start a proposal: a short web form, a forwarded email thread, or a one-line Slack command.
  • Every draft has the same five parts: cover, understanding of the need, approach, timeline, and price summary.
  • The draft is grounded on your own templates and the past proposals that won — so it sounds like you.
  • The price is computed in plain Python from your rate card. The model never invents a number.
  • Designed on AWS for about $3/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Brief in" — the three ways a salesperson starts a proposal: a short web form, a forwarded email thread that gets read into a brief, and a one-line Slack command. Centre, "Templates and voice" — a Google Drive folder with your section templates (a cover format, a scope shell, a standard timeline), your past winning proposals used for grounding, and a short doc of pricing rules and voice notes. Far right, "Client" — where the finished, approved proposal lands as a branded PDF, emailed after you sign off. Each connects via an arrow to the AWS account container below. The brief flows into AWS. Templates and voice ground every draft. The client receives the approved proposal as a PDF with a short cover note. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Brief intake — receives a brief from each source, tidies it with a cheap model call, and stores a clean brief. In the middle, the Generator — finds your closest past proposals, computes the price in plain Python, then writes the five sections in one grounded model call and runs a price-and-date guard. On the right, the Delivery — shows you the draft to edit and approve, renders a branded PDF, and emails it to the client. Internal arrows flow left to right. A note at the bottom reads: every proposal is yours to edit — the generator never sends anything a human hasn't approved. Brief in form, email, Slack Templates and voice past proposals, rules Client where the PDF lands brief in grounds proposal after sign-off AWS account Brief intake tidy, normalize, store clean brief Generator retrieve, price, draft five sections, guard Delivery edit, approve, PDF then email brief draft Every proposal is yours to edit — the generator never sends anything a human hasn’t approved.
Fig 1. Three sources outside, three pieces inside AWS. A brief flows in from a form, an email, or a Slack command. The Generator drafts five sections grounded on your past work. Delivery shows you the draft, then sends the approved proposal as a PDF.

What you set up once (the outside)

  • Brief in. Three ways to start a proposal, covered in Part 2. A short web form (client name, what they need, rough budget, due date) for when you’re at your desk. A forwarded email thread — send the back-and-forth with the prospect to a dedicated address and the system reads it into a brief. A one-line Slack command for the proposal you remember on the way out the door. All three end as the same clean brief.
  • A templates folder. A Google Drive folder you fill once. One sub-folder holds your section templates — the cover format you like, a scope shell, a standard timeline, your terms. One holds your past proposals, the ones that won; the generator reads these to sound like you. One short doc holds your pricing rules and voice notes — your day rate, your packages, the phrases you always use and the claims you never make. Editing any of these changes future drafts without touching code.
  • Client. Where the finished proposal lands. After you approve a draft, the system renders it to a branded PDF, saves a copy to the Drive folder, and emails it to the client with a short cover note. You can also just download the PDF and send it yourself.

What runs on every brief (the inside)

  • The brief intake. Whichever lane the brief came in on, a small step tidies it: a cheap Bedrock Haiku 4.5 call pulls out the client name, the need, the rough budget, and the due date, and flags anything missing. The clean brief is stored, and you get a one-tap “start the draft” card. Nothing is drafted until you say go — the intake just gets the brief ready.
  • The generator. The heart of the system, covered in Part 3. It finds your closest past proposals (using embeddings — a way to find work that reads similar to this brief, not just work that shares the same words). It computes the price in plain Python from your rate card and the brief’s budget. Then it makes one grounded Claude Sonnet 4.6 call to write all five sections — cover, understanding of the need, approach, timeline, and price summary — using your templates, the retrieved past sections, and the computed numbers. A guard re-reads the draft to check every price and date matches the computed values before anyone sees it.
  • Delivery. The draft shows up for you to read — in Slack with three buttons, or in a linked Google Doc you can edit directly. Approve renders a branded PDF and emails it to the client. Edit opens the doc to revise, then re-approve. Discard archives the brief. Every action is logged so a sent proposal can always be traced back to the brief it came from. A weekly digest lists what went out and what’s still sitting in draft.

In plain words

A prospect named Delgado & Co. asks you to redesign their booking flow. You type three lines into the form: “Delgado & Co. — rebuild the online booking flow, mobile-first — budget around $18k — wants it live before their Q4 push.” You tap start the draft. Ninety seconds later a draft lands in your Slack: a cover addressed to Delgado & Co., a paragraph that plays back exactly what they need, an approach lifted from the two booking projects you’ve done before, a four-week timeline, and a price summary that lands at $17,500 against their budget — computed from your day rate, not guessed. You tweak two sentences in the linked doc, change the timeline by a week, and tap Approve. The branded PDF emails itself to Delgado & Co. with your cover note. Total time: under ten minutes, on a Tuesday, before the thread went cold.

The cost of running this is about $3 a month at SMB volume. The cost of not running it is the proposal you didn’t send because Friday got busy — the deal that quietly went to whoever did get something over.

Design rules that shaped every decision

  • Five sections, always. Cover, understanding of the need, approach, timeline, price summary. There is no sixth.
  • The price is computed in code from your rate card. The model restates the number; it never invents it.
  • Every draft is grounded on your own templates and past winning proposals — so it reads like you, not like a robot.
  • Nothing is sent without a human tapping Approve. The default action is “show me,” never “send.”
  • The templates live in Drive. Changing your voice, packages, or terms doesn’t need a deploy.
  • Every proposal is logged. Look at a deal next quarter and you can see the brief it came from and who approved it.

Why this shape

Most small teams write proposals one of two ways: from a blank page every time, or by copying last month’s proposal and find-and-replacing the client name. The blank page is slow and it’s where deals go to die — the proposal you mean to write tonight becomes the one you never send. The copy-paste approach is fast but dangerous: it’s how last client’s name ends up in this client’s cover, or how a price from a different-sized job sneaks in.

The setup above keeps the best of both. The draft is fast, because the system writes it. It sounds like you, because it’s grounded on your own winning proposals instead of a generic template. And it’s safe, because the numbers are computed in code and a human approves every word before it leaves. The generator does the eighty percent that’s the same every time, and leaves you the twenty percent — the judgment, the tweak, the “actually let’s phase this” — that’s why a person should still be in the loop.

The next four posts walk through each piece in turn: how a brief gets captured, how a proposal gets drafted, how a proposal stays on brand, and how a proposal gets sent. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts