> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getquikly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Proposal types
> Quikly supports six engagement models for software services. Learn how each one works and when to use it.
Quikly includes six proposal types, each designed for a different way of selling software projects. Every type has its own pricing logic, governance fields, and AI analysis tailored to that engagement model.
Each type reflects a real contracting model. Pick the one that matches how you already work with your clients.
## Comparison
| Type | Pricing model | Best for | Plan required |
| ------------------ | -------------------------------------- | -------------------------------------------- | -------------- |
| Technical Proposal | Story points → hours × rate | Fixed-scope projects, technical clients | Starter (free) |
| Hour Bucket | Total hours × rate | Maintenance, support, variable tasks | Professional |
| Time & Materials | Hour range × rate per role | Variable scope, agile teams | Professional |
| Retainer | Monthly hours × discounted rate | Ongoing support, long-term clients | Professional |
| Milestone-Based | Payments tied to deliverables | Migrations, large phased projects | Professional |
| Staff Augmentation | Rate cards × team allocation per phase | Consultancies, dedicated teams (3–12 months) | Agency |
## Technical Proposal
A fixed-scope proposal where each requirement gets estimated in **story points** (complexity: 1, 3, 5, or 8) and converted to hours using an efficiency factor you control.
**How pricing works:**
* Each requirement is assigned a complexity value in story points.
* Hours = story points × efficiency factor (configurable per project).
* Total = hours × your hourly rate.
* Adjustments stack on top: tech stack complexity (+5%), urgency surcharge (+25%), recurring client discount (−10%), applicable tax, and optional maintenance fee (15% of project total).
**What the AI generates:**
* Structured requirements with descriptions, acceptance criteria, and complexity scores.
* Delivery conditions and out-of-scope definitions.
* Risk analysis with mitigation strategies.
* Governance section (warranty period, revision rounds, change request process).
**When to use it:** complex projects where the client expects a detailed breakdown of what they're paying for — feature by feature.
**Complexity scale:**
| Points | Meaning | Typical scope |
| ------ | ------------ | ------------------------------------------------ |
| 1 | Trivial | Config change, copy update |
| 3 | Standard | CRUD endpoint, form with validation |
| 5 | Complex | Third-party integration, complex business logic |
| 8 | Very complex | Architecture change, real-time system, migration |
**Available adjustments:**
| Adjustment | Default | Description |
| ------------------------- | ------------ | ------------------------------------------------------------------ |
| Tech stack complexity | +5% | Applied when the stack involves unfamiliar or complex technologies |
| Urgency surcharge | +25% | For tight deadlines |
| Recurring client discount | −10% | Optional discount for returning clients |
| Tax | Configurable | Country-specific tax rate |
| Maintenance fee | 15% | Post-delivery maintenance and support |
All adjustments are optional and editable before sharing.
## Hour Bucket
A pre-paid block of hours at your hourly rate. The client purchases a fixed number of hours and uses them for agreed-upon services within a validity period.
**How pricing works:**
* Total = bucket hours × hourly rate.
* You set the validity period (e.g., 30, 60, or 90 days from acceptance).
* An **expiry policy** defines what happens to unused hours:
* **Expire** — unused hours are non-refundable.
* **Rollover** — unused hours carry over to the next period.
* **Credit** — unused hours become credit toward a future purchase.
* A **minimum billing increment** (15 min, 30 min, or 1 hour) determines the smallest unit billed per request.
**When to use it:** retainers, technical support, bug fixes, or any engagement where the exact scope varies but the client wants a predictable budget.
**Governance fields:**
* Service description and included activities.
* Hour reporting cadence (weekly, biweekly, monthly).
* Request process and prioritization rules.
* Escalation path.
* Identified risks (expiration disputes, scope ambiguity, micro-billing).
Quimy can auto-suggest governance terms and identify risks based on the brief.
## Time & Materials
Billing by the hour within a defined range, with role-based rate cards and configurable budget caps.
**How pricing works:**
* You define an **hour range** (minimum–maximum estimated hours).
* Each role has its own rate (from your rate card or a flat rate).
* A **billing cadence** sets how often you invoice (weekly, biweekly, monthly).
* An optional **budget cap** protects the client from runaway costs.
**When to use it:** projects with evolving requirements where you need flexibility but still want guardrails.
**Key fields:**
| Field | Description |
| ---------------------- | --------------------------------------- |
| Hour range (min–max) | Estimated effort range |
| Rate per role | Individual rates by role or seniority |
| Billing cadence | Weekly, biweekly, or monthly invoicing |
| Budget cap | Maximum spend before requiring approval |
| Change request process | How scope additions are handled |
## Retainer
A recurring monthly engagement at a preferred (discounted) rate, with defined hours per month and optional rollover.
**How pricing works:**
* Monthly total = retainer hours × discounted hourly rate.
* You set a **minimum commitment** (e.g., 3 months, 6 months).
* A **rollover percentage** defines how many unused hours carry over (e.g., 20% of unused hours roll to the next month).
* Optionally include an **SLA** (response time, uptime commitment, escalation path).
**When to use it:** ongoing maintenance, long-term support, or any relationship where the client benefits from a predictable monthly cost and you benefit from recurring revenue.
**Governance fields:**
| Field | Description |
| ------------------ | ---------------------------------------------- |
| Monthly hours | Contracted hours per month |
| Discounted rate | Preferred rate (lower than your standard rate) |
| Minimum commitment | Minimum number of months |
| Rollover % | Percentage of unused hours that carry over |
| SLA | Response time, resolution time, uptime targets |
| Renewal terms | Auto-renew, manual renewal, notice period |
## Milestone-Based
Payments tied to deliverables. Each milestone has a clear deliverable, acceptance criteria, a percentage of the total budget, and a due date.
**How pricing works:**
* The project total is split across milestones, each with a **payment percentage** that must sum to 100%.
* Each milestone defines **acceptance criteria** — the conditions the client evaluates to approve payment.
* An optional **deposit** (e.g., 20–30%) is collected before work begins.
You can create milestones in two modes:
* **With requirements** — milestones reference specific requirements from the scope. Quimy can auto-group requirements into logical milestones.
* **Without requirements** — milestones are defined as standalone deliverables (useful for non-technical phases like discovery or design).
**When to use it:** migrations, large multi-phase projects, or any engagement where the client wants to pay incrementally based on verified progress.
**Example milestone structure:**
| Milestone | Deliverable | Payment % | Acceptance criteria |
| --------- | -------------------------------- | --------- | ---------------------------------------------------------------------- |
| Deposit | Project kickoff | 20% | Signed agreement |
| Phase 1 | Authentication + user management | 30% | Login flow working in staging, passes test suite |
| Phase 2 | Product catalog + search | 30% | Catalog browsable, search returns results in under 200 ms |
| Final | Deployment + handover | 20% | Production deploy, documentation delivered, training session completed |
## Staff Augmentation
Dedicated team allocation with role-based rate cards, seniority levels, and per-phase team composition.
**How pricing works:**
* You define a **rate card** with roles (e.g., Senior Frontend Developer, DevOps Engineer, QA Lead), each with a seniority level and hourly or monthly rate.
* The project is divided into **phases** (e.g., Discovery, Build, Stabilization), each with its own team allocation and duration.
* An **agency margin** is applied on top of individual rates (visible only to you, not the client).
* Constraints include minimum commitment, ramp-up/ramp-down periods, and replacement guarantees.
**When to use it:** consultancies placing dedicated teams with clients for 3–12 months, where the client pays for people and capacity rather than deliverables.
**Rate card example:**
| Role | Seniority | Monthly rate | Dedication |
| ------------------ | --------- | ------------ | ---------- |
| Frontend Developer | Senior | \$8,500 | 100% |
| Backend Developer | Senior | \$9,000 | 100% |
| QA Engineer | Mid | \$5,500 | 50% |
| DevOps Engineer | Senior | \$9,500 | 25% |
| Tech Lead | Lead | \$11,000 | 50% |
**Phase example:**
| Phase | Duration | Team size | Key roles |
| ----------------- | -------- | --------- | ------------------------------------ |
| Discovery & setup | 2 weeks | 3 | Tech Lead, Frontend Dev, Backend Dev |
| Core build | 8 weeks | 5 | Full team |
| Stabilization | 2 weeks | 3 | Tech Lead, QA, DevOps |
**Governance fields:** SLA summary, contractual clauses (IP, confidentiality, replacement policy, termination terms).
Staff Augmentation is available on the **Agency** plan. It includes multi-role proposals with per-member cost breakdown and seniority-based pricing.
## Related documents
Beyond creating a new proposal, you can generate **addendums** and **renewals** that reference an existing proposal. These inherit the parent's settings and follow their own wizard steps.
* [Addendums and renewals](/guides/addendums-renewals) — learn how to modify or extend an existing agreement.