{"id":988455,"date":"2026-09-18T14:00:00","date_gmt":"2026-09-18T14:00:00","guid":{"rendered":"https:\/\/croncodestudio.com\/en\/?post_type=croncode_post&p=988455"},"modified":"2026-09-08T22:58:41","modified_gmt":"2026-09-08T22:58:41","slug":"what-to-send-when-requesting-a-software-quote","status":"publish","type":"croncode_post","link":"https:\/\/croncodestudio.com\/en\/journal\/what-to-send-when-requesting-a-software-quote\/","title":{"rendered":"What to Send for a Software Quote"},"content":{"rendered":"
\n

A software quote is only as honest as the packet behind it. If you send a slogan, you will get a number that hides a fight. If you send a job, an object, and the constraints, you will get a scope you can argue with. This is the packet Croncode asks for. Other studios should ask for something close to it.<\/p>\n

\n

Send a software quote packet with the user job, the object, who owns accounts, languages, and a not-now list. A slogan and a Pinterest board are not a brief.<\/p>\n<\/blockquote>\n

What is the minimum packet?<\/h2>\n
    \n
  1. Job:<\/strong> who is stuck, and what \u201cdone\u201d looks like in one session.<\/li>\n
  2. Object:<\/strong> order, garment, case, journey, or your noun.<\/li>\n
  3. Users:<\/strong> how many roles, not a TAM slide.<\/li>\n
  4. Platforms:<\/strong> iOS, web, both, and which is first.<\/li>\n
  5. Languages:<\/strong> English, Turkish, others, and who writes them.<\/li>\n
  6. Accounts:<\/strong> who owns Apple, domains, and the repo today.<\/li>\n
  7. Constraints:<\/strong> legal, payments, offline, on-device.<\/li>\n
  8. Not now:<\/strong> at least five items you can live without.<\/li>\n<\/ol>\n

    If the work includes a model, add the AI brief from how to brief an AI app studio<\/a>. Do not paste keys. Do not send live customer files to a personal chat.<\/p>\n

    What optional files actually help?<\/h2>\n\n\n\n\n\n\n\n\n
    File<\/th>\nUseful when<\/th>\nSkip when<\/th>\n<\/tr>\n<\/thead>\n
    Figma<\/td>\nFlows exist<\/td>\nIt is only a mood<\/td>\n<\/tr>\n
    Store listing draft<\/td>\nYou know the promise<\/td>\nIt contradicts the job<\/td>\n<\/tr>\n
    Analytics<\/td>\nA product already lives<\/td>\nVanity charts only<\/td>\n<\/tr>\n
    Brand PDF<\/td>\nTokens exist<\/td>\nIt is 80 pages of values<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    A landing-page draft helps if the first release needs traffic. See landing pages that send traffic to the App Store<\/a>. An ecommerce map helps if revenue is the point. See the 2026 checklist<\/a>.<\/p>\n

    How do we read the packet?<\/h2>\n

    We look for a first increment we could put on TestFlight. We look for a store gate if iOS is in scope. We look for a conflict between the promise and the not-now list. Process choice is separate: fixed scope vs agile<\/a>. Sequence: idea to App Store<\/a>.<\/p>\n

    If you are choosing a vendor, the packet also tests them. A studio that quotes without asking about accounts is a risk. See how to choose an iOS studio<\/a> and studio vs freelancer vs agency<\/a>.<\/p>\n

    When is the packet not enough?<\/h2>\n

    When two founders disagree on the job. When the object has no owner. When the only success metric is a download count. We will ask you to pick. Data later should beat opinions. Related: users vs data<\/a>.<\/p>\n

    What should you leave out?<\/h2>\n