Skip to main content

Proposal Process

How to Prepare a Project Before Requesting a Proposal

A 6-section preparation checklist for faster, more accurate proposals: goal, scope, references, budget, GDPR/KVKK, documentation. Good preparation doubles proposal quality.

Quick answer

Prepare project goals, scope, references, budget, GDPR, and documentation before requesting a software proposal. 6-step checklist.

T

Tolga Ege

Mobile & Web Software Architect, AI/SaaS Specialist

Published: 2026-03-038 min

Intro: bad proposals usually start with the client

Many project owners experience this: 5 agencies, 5 different prices — one says 50K, another says 500K. The reaction is "the software market is unpredictable." In reality, 80% of the spread comes from missing client preparation, not the agencies.
Good preparation does one thing: reduces the number of assumptions. Agencies add a risk premium for every uncertainty, so uncertainty equals expensive proposal. If you clarify the 6 sections in this article, proposals get cheaper, more aligned with each other, and properly comparable.
Goal: a 4-6 page project brief you can put together in a day. The headings below form its skeleton.

1. Goal: what will the product do?

The first question is not technical — it's about the business goal. "I want a mobile app" isn't enough; "a mobile app for customer loyalty, where I can send push campaigns and target a 20% lift in repeat-order rate" is right.
Three questions to answer: (a) who will use it (user persona)? (b) what problem does it solve (problem statement)? (c) how will success be measured (KPIs)?
What this means for the agency: without these answers, technology selection isn't possible. Mobile vs PWA, Stripe vs iyzico, Postgres vs Firebase — all depend on the business goal. Without the goal, the agency picks the wrong technology; you discover it 6 months later.

2. Scope: must-have / nice-to-have / won't-have

Use the MoSCoW method to split scope into 4 lists: Must-have (no project without it), Should-have (phase 1.5), Could-have (phase 2+), Won't-have (out of scope, explicitly written).
Bad scope: "Mobile app, with everything in it." Good scope: a 15-30-item feature list with priority for each. "Push notification: must", "In-app chat: should", "AI recommendation engine: could".
The won't-have list is the most critical part. Anything not explicitly written is left to agency assumption — the source of price spread. Once "no admin panel in this version" is on paper, 5 agencies all bid on the same scope.

3. References: similar products and screen examples

Visual references communicate 10× faster than words. "Like Booking.com's search page" is clearer than three paragraphs of explanation.
Prepare: 3-5 similar product screenshots (not just UI, also the flow order), notes on what you like / dislike, design direction references (Behance / Dribbble links).
Risk: too many references create confusion. "A mix of Booking + Spotify + Notion + Tinder" puzzles the team. 3-5 references are enough; share the rest in a verbal session.

4. Budget + timeline: give a range, not a fixed number

Asking for proposals without sharing a budget seems smart — but slows you down in the long run. Without knowing the spend level, agencies either overshoot (premium proposal scares you off) or undershoot (insufficient solution).
Give a range: "100-300K TL band", "500K-1M TL band". This tells the agency which architecture and scope to suggest. If they're not in your budget band, they'll act as a consultant: "at this budget, this scope makes sense; this part isn't needed."
Timeline: "3 months" is insufficient. "Demo on Jan 15, pilot on Mar 1, live on May 1" with milestones. Is there a race (competing product launching)? A seasonal must (Ramadan, season start)? This information clarifies prioritization.

5. Data + GDPR/KVKK + security requirements

Many briefs skip this; then in Phase 3, "this must be GDPR / KVKK compliant" gets added and the architecture is rewritten. Clarify on day 1: what type of data will be collected (any personal data?), under which jurisdiction (Turkey? EU?), who is responsible (controller / processor)?
Sector-specific add-ons: healthcare (HIPAA / health-data clauses), finance (PCI-DSS, banking regulator), public sector (national digital transformation rules). These standards affect architecture + cost + time, all three.
Data migration: will data be moved from an existing system? CSV, API, or direct database dump? What's the data quality state? These items usually surface late in the project; written into the brief from day 1, the agency can give a realistic proposal.

6. Existing documents + integration list

List existing systems / APIs / documents. "We use Salesforce as CRM, iyzico for payments, Mailchimp for email". Each integration enters the proposal scope; if missing, the agency assumes "a standard REST API", and the difference shows up later.
Useful additional files to have ready: (a) user flow diagram (Whimsical / Excalidraw), (b) wireframe sketch (paper drawing is fine), (c) existing analytics report (Google Analytics dump), (d) competitor analysis (1 page).
Practical tip: prepare a single Notion / Google Doc page. 1-2 paragraphs + links per section. Send the link to the agency — proposal quality visibly improves.

Conclusion: 1 day of preparation saves 6 months

Filling these 6 sections takes an experienced project owner 1 day; someone going through this for the first time, 2-3 days. But this investment directly determines the quality of the next 6 months. Instead of taking unprepared proposals and being surprised for 6 months, spend 3 days on prep + clean proposal process.
When you present instead of waiting for the agency to ask, you get faster and more reliable proposals. You can also compare different agencies' proposals one-to-one; 3 proposals on the same brief are genuinely comparable.
If preparing a project brief feels overwhelming, you can start through our project request form — its question/answer format naturally walks you through the 6 sections.

City-based landing pages

Related articles

Other articles that support the same decision

Next step

If you are planning a similar project, we can clarify the scope and shape the right proposal flow together.

Start a project request

About the author

T

Tolga Ege

Founder — CreativeCode

10+ years of production experience in mobile apps, web software, SaaS, and custom software. End-to-end delivery on Flutter, React Native, Next.js, Node.js, and the modern AI/LLM ecosystem (OpenAI, Anthropic, Google). Founded CreativeCode in 2017; shipped 100+ projects across mobile, web, and SaaS verticals.

Mobile AppsSaaS ProductsAI/LLM IntegrationProgrammatic SEOTechnical Leadership