Prompt Kits

Build a Proposal & Acceptance Flow

The gap between a good call and a signed project is where most independent work quietly dies. You promise to "send something over", the something takes an evening to assemble, it goes out as an attachment, and then nothing — no way to tell whether it was read, no clean way for the client to say yes, and a follow-up email that feels like begging. This kit closes that gap: a private page per client with the scope, the fee and the timeline, a button that records their acceptance, and a notification the moment it happens. Five sequenced prompts, and one honest boundary held throughout — an accept button is a clear record of agreement, not a legal signature, and this kit does not pretend otherwise.

Project type: Client proposals Difficulty: Intermediate Time: 1-2 days Works with: Base44 / Lovable / v0

What you'll have at the end

  • A private proposal page per client — their scope, their fee, their timeline, at their own link
  • Reusable packages so sending a proposal takes minutes instead of an evening
  • A record of when the proposal was opened, so following up stops being guesswork
  • An accept button that captures who accepted, from where, and exactly what wording they accepted
  • An optional deposit step that runs only after acceptance, on the payment provider's own secure page
  • A proposal desk showing what is out, what is going stale, what was won and what was lost — and your real win rate

Before you start

  • Your packages or service tiers, written down. What each includes, what it excludes, and the price or range. If every proposal starts from a blank page, this kit will help less than fixing that first.
  • Your standard terms. Payment schedule, what happens to the deposit, revision rounds, timeline assumptions, what pushes a date, and how either side stops. These become the wording the client actually accepts.
  • What "accepted" means in your process. Does acceptance start the work, hold the date, or trigger a contract you send separately? Decide now, because the page has to say it plainly.
  • Whether you need a real contract or e-signature. For most small project work an accepted proposal with clear terms is how business is actually done. For high-value work, regulated fields, or anywhere your clients expect a countersigned document, you need a proper contract alongside this — and that is not what this kit builds.
  • An email address you check quickly, and a payment provider account if you plan to take a deposit.
  • Whether you already run a client-management system. If you are paying for HoneyBook, Dubsado or similar and it works for you, its proposals are already integrated with your contracts and invoices. Improving your intake is likely a better use of a day than rebuilding what you already have.

Which platform suits this

Base44 is the natural fit: private per-client pages, stored acceptances, notifications and an owner desk all live in one managed app, and the access rules that make a proposal private are exactly what its built-in accounts handle. Lovable builds the same through Lovable Cloud or an optional Supabase backend and gives you code ownership later. v0 will build all of it with server actions or API routes on Vercel, but access control is the part you must get right yourself here — a proposal page carries a client's fee, and an unguessable link is not the same thing as a protected one. On every platform this is the kit where you should do the access-rules check at the end rather than assume it.

Start with the first prompt on a free plan. Extra usage and some connected services may cost more as you build out the project.

Build it on

How we make money

The steps

1

Build the page a client actually says yes on

When to use this

Start here — in a new project, or on the site you already built.

One private proposal page carrying scope, fee and timeline, readable on a phone.

The prompt

Add a private proposal page to this site for [YOUR BUSINESS AND WHAT YOU SELL, e.g. an interior design studio proposing residential projects].

Each proposal lives at its own private address and belongs to one client. It shows: who it is for and when it was prepared, a short paragraph in my own words about their project, what is included as a clear list, what is explicitly not included, the fee or fee range, the payment schedule, the timeline with its assumptions, and my standard terms: [YOUR TERMS, e.g. revision rounds, what moves a date, deposit treatment, how either side stops].

Write nothing for me. Leave every one of those as a field I fill in — do not generate scope, fees, timelines or terms, and do not fill an empty proposal with plausible-sounding text.

State plainly near the top what accepting this page will mean in my process: [WHAT ACCEPTANCE DOES, e.g. it holds your date and I send the contract, or it starts the work].

Give each proposal an expiry date I set, shown on the page, and after which it reads as expired rather than still live.

It must read properly on a phone, because that is where it will be opened first, and it must print or save to PDF cleanly, because someone will want to show a partner.

No accept button yet, and no sending yet — that comes later.

Check it worked

  • A proposal page shows scope, exclusions, fee, schedule, timeline and terms, all in your words
  • Nothing on it was written by the AI — every field came from you
  • What acceptance means is stated where the client will see it, not buried
  • The expiry date is visible
  • It reads well on a phone and prints cleanly
  • The page is not reachable from your public navigation

You'll know it worked when:

A real proposal for a real past project, filled in end to end, that you would have been happy to send at the time.

Watch out for

Do not let the AI draft your scope or terms. It writes fluent, confident project language that sounds professional and commits you to things you did not intend — and unlike a typo, you will not notice until a client holds you to it. The exclusions list matters as much as the inclusions: most project disputes are about something nobody said was out.

2

Make sending one take minutes, not an evening

When to use this

Once a single proposal page reads right.

Reusable packages, so each new proposal starts most of the way finished.

The prompt

Add reusable proposal templates behind my owner screen.

Let me save my standard packages — [YOUR PACKAGES OR TIERS] — each with its own inclusions, exclusions, fee or range, payment schedule and typical timeline. Let me also save my standard terms once so they are not retyped.

Creating a new proposal starts from a package, fills all of that in, and lets me change anything for this particular client before sending. Changing a saved package must not alter proposals that already exist.

Let a proposal offer more than one option side by side where I want it — [e.g. a smaller and a larger scope] — with the client choosing one when they accept.

Let me duplicate any past proposal as the starting point for a new one.

Keep the proposal page itself working exactly as it is.

Check it worked

  • A new proposal starts from a package with everything pre-filled
  • You can change anything for this client without touching the saved package
  • Editing a package leaves sent proposals untouched
  • A multi-option proposal shows the choices clearly and records which one is taken
  • Any past proposal can be duplicated

You'll know it worked when:

You built a new proposal from a package in under five minutes, and it was ready to send.

Watch out for

Make sure editing a package cannot reach back into proposals already sent. Getting this wrong means a client's agreed fee silently changes after they accepted it, which is the single worst bug this kit can have. Test it deliberately: send yourself a proposal, edit the package it came from, and confirm the sent one did not move.

3

Send it, and stop guessing whether it was read

When to use this

Once you can build a proposal quickly.

The client receives their link, and you know when they opened it.

The prompt

Add sending to my proposals.

From my owner screen, let me send a proposal to a client's email address. They receive a short message with a link to their own private proposal page. Use a proper email delivery service so it reliably arrives rather than landing in spam, and tell me exactly what I need to set up.

Protect each proposal so only the intended client can open it: [YOUR CHOICE — a short code I give them, or an account I create for them]. Do not rely on the address being hard to guess; a proposal contains someone's fee.

Record when the proposal was first opened and when it was last opened, and notify me the first time. Show this on my owner screen.

Let me resend a proposal, and let me withdraw one so its link stops working and says so plainly rather than breaking.

Do not track anything beyond opens — no reading time, no scroll depth, no per-section attention. Knowing it was opened is what I need; the rest would be surveillance of a client.

Keep the proposal page and the templates working exactly as they are.

Check it worked

  • The client receives a working link and can open their proposal
  • Someone without the code or account cannot open it
  • You are notified the first time it is opened, and can see first and last open
  • You can resend, and you can withdraw so the link closes cleanly
  • Nothing beyond opens is recorded

You'll know it worked when:

You sent a test proposal to your own second address, opened it, and saw the open registered on your owner screen.

Watch out for

An unguessable link is not access control. Anything forwarded gets forwarded further, and one client seeing another's fee is a phone call you do not want to have. Do the access check in step 5 properly rather than trusting that nobody would try. On the other side, resist tracking more than opens — clients can tell when they are being watched, and it costs more trust than the data is worth.

4

The accept button, and what it actually records

When to use this

Once proposals reach clients reliably.

A clear acceptance, a dated record of exactly what was agreed, and an immediate notification.

The prompt

Add acceptance to my proposal pages.

The client accepts with a clear action — a button plus typing their name to confirm it is them. Beside it, in plain language, state what they are agreeing to and what happens next: [YOUR WORDING, e.g. accepting confirms this scope and fee, and I will send the contract and deposit request within one working day].

When a proposal is accepted, store a permanent record of it: who accepted, the name they typed, the date and time, and a frozen copy of the exact proposal wording they saw. That frozen copy must never change afterwards, even if I edit the proposal or the package it came from.

Notify me immediately, and send the client a confirmation email containing their accepted proposal so they have their own copy.

Let the client decline instead, with an optional short reason, and notify me of that too. A clear no is worth more than silence.

An expired proposal cannot be accepted — it says so and offers to ask me for an updated one.

[IF I WANT A DEPOSIT: after acceptance and only after it, show a payment step for [YOUR DEPOSIT], handled on the payment provider's own secure page. Never before acceptance, and never store card details on my site.]

Do not describe any of this as a signature, a signed contract or a legally binding agreement anywhere in the page or the emails. It is a record of acceptance.

Check it worked

  • Accepting takes a deliberate action, not a stray click
  • What the client is agreeing to is stated beside the button
  • The stored record holds who, when, and a frozen copy of the wording
  • You are notified immediately; the client gets their own copy
  • Declining is possible and notifies you
  • An expired proposal cannot be accepted
  • If you enabled a deposit, it appears only after acceptance, on the provider's secure page
  • Nothing anywhere calls this a signature

You'll know it worked when:

You accepted a test proposal, received the notification, and confirmed the stored record froze the exact wording — then edited the original and watched the record stay put.

Watch out for

The frozen copy is the whole point of the record. A stored acceptance that simply points at the current proposal proves nothing the moment you edit that proposal, and you will edit it. Separately: if your work is high-value, regulated, or your clients expect a countersigned document, treat this acceptance as the commercial yes and send a proper contract behind it. An accept button is honest evidence of agreement; it is not a legal signature, and the rules differ by country and by field.

5

Your proposal desk

When to use this

Once proposals are going out regularly.

See what is out, what is going cold, and what your real win rate is.

The prompt

Add a private proposals desk to my owner screen.

List every proposal with its client, value, status — draft, sent, opened, accepted, declined, expired — when it was sent, when it was last opened, and its expiry date. Let me add a private note to each one.

Highlight proposals that were sent and never opened after [YOUR THRESHOLD, e.g. 3 days], and proposals that were opened but not answered after [YOUR THRESHOLD, e.g. 7 days]. These are the two follow-ups that actually win work.

Let me send a short, polite follow-up from the desk in one action, with wording I control and can edit before it goes.

Show me a simple summary: proposals sent this month, accepted, declined, expired, my acceptance rate, and the typical value of an accepted proposal against a declined one.

Let me export my proposals and their acceptance records, so I always have my own copy.

Make sure clients can only ever reach their own proposal and nothing else on this screen.

Keep everything from the previous steps working exactly as it is.

Check it worked

  • Every proposal appears with its status, value, opens and expiry
  • Unopened and unanswered proposals are surfaced before they go cold
  • A follow-up can be sent in one action, with wording you control
  • The summary shows a win rate you recognise
  • You can export proposals and their acceptance records
  • A signed-in client can reach their own proposal and nothing else

You'll know it worked when:

You worked a week of live proposals from this screen — chased two, closed one, and saw your acceptance rate — without opening your inbox.

Watch out for

Run the access-rules check here rather than trusting it (see the access rules audit prompt). Sign in as a test client and try to reach another client's proposal directly by its address. This is the one kit where a permissions mistake exposes other people's money, and it is far easier to test than to explain.

Going live

  • Re-read one full proposal as a client would, on a phone, and check nothing on it was written by the AI
  • Sign in as a test client and try to open another client's proposal by its address — confirm you cannot
  • Send a real test proposal to an ordinary email account and confirm it does not land in spam
  • Accept a test proposal, then edit the original and confirm the stored record did not change
  • Confirm an expired proposal cannot be accepted
  • Check that nothing on the page or in the emails calls this a signature or a binding contract
  • If you take deposits, switch to live payment keys, take one real deposit and refund it
  • Confirm your terms, payment schedule and cancellation wording are exactly what you intend to be held to
  • Add a privacy note covering what you store about clients (see the legal pages prompt)
  • Connect your custom domain and check the padlock appears

Spend fewer credits

Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.

  1. Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
  2. Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
  3. Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
  4. One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
  5. Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
  6. Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.

The prompts on this page are written to do most of this work for you — that's the point of them.

Read the full guide

Last reviewed: 2026-09-14

FAQ

We use cookies to analyze traffic and track affiliate clicks. By continuing, you agree to our Privacy Policy.