एक संस्थापक ने मुझे नवंबर 2024 में फोन किया, क्रिसमस से दो हफ्ते पहले, बिल्कुल क्रोधित। उसे एक वेब एजेंसी से एक कस्टम लॉजिस्टिक्स डैशबोर्ड के लिए £14,000 का कोट मिला था। उसने साइन कर दिया। छः महीने बाद अंतिम इनवॉइस £61,000 पर आया। किसी ने उससे झूठ नहीं बोला था, तकनीकी रूप से। लेकिन किसी ने उसे सच भी नहीं बताया -- क्योंकि किसी ने भी उसका पैसा लेने से पहले ठीक से एस्टिमेट करने की कोशिश ही नहीं की थी।
मुख्य निष्कर्ष: कस्टम सॉफ़्टवेयर के उद्धरण निर्माण में नहीं, बल्कि स्कोपिंग में गलत होते हैं; डेटा मॉडल की जटिलता, इंटीग्रेशन और समीक्षा चक्रों से अनुमान लगाएँ, और खोज चरण को अलग से मूल्य दें।Custom software quotes go wrong at scoping, not building; estimate from data model complexity, integrations, and review cycles, and price the discovery phase separately.
मैं बारह साल से ज्यादा समय से सॉफ्टवेयर बना रहा हूँ। Seahawk ने अकेले 12,000 से ज्यादा साइट और एप्लिकेशन लॉन्च किए हैं। और एक सबसे लगातार विफलता का बिंदु जो मैं देखता हूँ -- संस्थापकों के साथ, फ्रीलांसरों के साथ, एजेंसियों के साथ जो प्रोजेक्ट के लिए कोट देते हैं -- यह है कि किसी के पास कोड लिखने से पहले कॉस्ट एस्टिमेट करने का कोई सख्त तरीका नहीं है। लोग अंदाजा लगाते हैं। वे vibes पर anchor करते हैं। वे आखिरी प्रोजेक्ट को reference point के रूप में इस्तेमाल करते हैं बिना यह check किए कि वह दूर-दूर से comparable था या नहीं।
तो। यह फ्रेमवर्क है जो मैं असल में इस्तेमाल करता हूँ। खाली सेल्स वाली स्प्रेडशीट टेम्पलेट नहीं। एक असली मानसिक मॉडल, वर्तमान 2026 के नंबर्स के साथ, विशिष्ट टूल्स, और वह सावधानियाँ जो महत्वपूर्ण हैं।
---
ज्यादातर सॉफ्टवेयर कोट्स कल्पना क्यों हैं
समस्या dishonesty नहीं है (आमतौर पर)। यह है कि सॉफ्टवेयर एस्टिमेशन सच में मुश्किल है, और ज्यादातर लोग यह कम आंकते हैं कि यह कितना मुश्किल है -- इसलिए वे ऐसे shortcuts के लिए जाते हैं जो rigour जैसे लगते हैं लेकिन हैं नहीं।how hard -- so they reach for shortcuts that feel like rigour but aren't.
एक डेवलपर आपको gut-feel नंबर देता है। एक एजेंसी अपने day rate को किसी estimated sprint count से गुणा करती है। एक फ्रीलांसर Upwork पर एक similar gig को देखता है और पीछे की ओर काम करता है। ये कोई भी बिल्कुल गलत नहीं हैं, लेकिन ये कोई भी असली cost drivers को account में नहीं लेते: integration complexity, क्लाइंट की ओर से decision latency, ऐसे features पर scope creep जो minor लगते थे, testing overhead, और silent killer -- environment setup और DevOps जिसे कोई price करता ही नहीं है।
2021 में मैं Manchester में एक property-tech क्लाइंट के लिए एक प्रोजेक्ट चला रहा था। कागज पर काफी सरल: एक tenant portal जिसमें document uploads, rent tracking, और एक maintenance request workflow हो। शुरुआती एस्टिमेट £28,000 था। हमने similar builds किए थे। लेकिन यह क्लाइंट एक legacy property management system इस्तेमाल कर रहा था जिसका एक proprietary API था जिसे किसी ने चार साल में touch नहीं किया था। Integration अकेले तीन हफ्ते से ज्यादा हो गया। अंतिम कॉस्ट: £47,500। क्लाइंट इसके बारे में ठीक था क्योंकि हमने उसे flag किया था जैसे ही हमने API docs को देखा -- लेकिन शुरुआती एस्टिमेट अभी भी कल्पना था, और मैं इसका जिम्मेदार था।
Uncertainty की Cone वास्तविक है
Cone of uncertainty, Steve McConnell द्वारा लोकप्रिय, बताता है कि project estimates कैसे अधिक सटीक हो जाते हैं जैसे-जैसे आप delivery के करीब आते हैं। ideation में, आप किसी भी दिशा में 4x से हट सकते हैं। विस्तृत डिज़ाइन के बाद, शायद 1.25x। अधिकांश founders ideation स्तर पर quotes ले रहे हैं और उन्हें हस्ताक्षरित अनुबंध की तरह मान रहे हैं।, popularised by Steve McConnell, describes how project estimates get more accurate as you get closer to delivery. At ideation, you might be off by 4x in either direction. After detailed design, maybe 1.25x. Most founders are getting quotes at the ideation stage and treating them like signed contracts.
व्यावहारिक परिणाम: detailed specs लिखे जाने से पहले आपको मिलने वाले किसी भी कोट को एक नंबर नहीं, एक range के रूप में treat करना चाहिए। अगर कोई एजेंसी आपको एक single figure देता है इससे पहले कि वह आपका data model, user flows, और third-party dependencies देख चुका हो -- वह नंबर सजावटी है।range, not a number. If an agency gives you a single figure before they've seen your data model, user flows, and third-party dependencies -- that number is decorative.
---
चार वास्तविक लागत बाल्टियाँ
किसी भी एस्टिमेटर के काम करने से पहले, आपको प्रोजेक्ट को सही categories में split करना होगा। "frontend, backend, QA" नहीं -- ये roles हैं, cost drivers नहीं। असली buckets ये हैं:
1. Greenfield vs. Integration Work
Greenfield -- कुछ ऐसा बनाना जो scratch से हो आपने अपने database और business logic के खिलाफ -- लगभग हर प्रोजेक्ट का सस्ता, ज्यादा predictable आधा है। यह integration work है जो आपको मारता है। हर external API, legacy system, payment processor, या third-party auth provider non-linear complexity जोड़ता है। मैं आमतौर पर किसी भी scope line पर जो external systems को touch करता है 30-40% contingency add करता हूँ।
2. UI/UX डिज़ाइन (इस लाइन को छोड़ें मत)
बहुत से संस्थापक design को optional मानते हैं या इसे development estimate में roll करने की कोशिश करते हैं। गलती। Design जब ठीक से किया जाता है -- wireframes, Figma में interactive prototypes, एक tested component library -- आमतौर पर total project cost का 15-25% चलता है। इसे skip करो और तुम दो बार pay करोगे: एक बार developer rework में जब requirements ambiguous निकलते हैं, और फिर से user research में बाद में जब product convert नहीं होता।Figma, a tested component library -- typically runs 15-25% of total project cost. Skip it and you'll pay twice: once in developer rework when requirements turn out to be ambiguous, and again in user research later when the product doesn't convert.
3. इंफ्रास्ट्रक्चर और DevOps
कोई भी इसे सही तरीके से उद्धृत नहीं करता। स्टेजिंग एनवायरनमेंट, CI/CD पाइपलाइन (हम अब लगभग सब कुछ के लिए GitHub Actions इस्तेमाल करते हैं), Docker के साथ कंटेनराइजेशन, AWS या GCP पर क्लाउड होस्टिंग -- ये असली खर्च हैं जो इसलिए गायब नहीं हो जाते कि किसी ने उन्हें सूचीबद्ध नहीं किया। मध्यम जटिलता वाले SaaS के लिए, प्रारंभिक इंफ्रास्ट्रक्चर सेटअप के लिए न्यूनतम £3,000-£6,000 बजट करें, साथ ही चल रहे मासिक खर्च जो आम तौर पर उपयोग के आधार पर £200-£800 चलते हैं।
4. टेस्टिंग, QA और लॉन्च ओवरहेड
स्वचालित टेस्ट स्यूट, मैनुअल QA पास, परफॉर्मेंस टेस्टिंग, भुगतान या व्यक्तिगत डेटा को संभालने वाली किसी भी चीज़ के लिए सुरक्षा समीक्षा -- यह ठीक से किए जाने पर आमतौर पर कुल विकास समय का 20% है। अधिकांश एजेंसी कोट "टेस्टिंग" को एक लाइन आइटम के रूप में शामिल करते हैं और मतलब "एक डेव ने हैंडओवर कॉल से पहले एक दोपहर के लिए चारों ओर क्लिक किया।"
---
एक काम करने वाला एस्टिमेटर: मॉड्यूल मेथड
यह असली फ्रेमवर्क है। मैं इसे मॉड्यूल मेथड कहता हूँ क्योंकि यह आपको किसी प्रोजेक्ट को अलग-अलग, स्वतंत्र रूप से अनुमानित चंकों में तोड़ने के लिए बाध्य करता है, न कि इसे एकाश्म मानते हुए।
चरण 1: हर फीचर को यूजर स्टोरी के रूप में सूचीबद्ध करें। "यूजर मैनेजमेंट" नहीं -- यह बहुत अस्पष्ट है। "एक यूजर ईमेल और पासवर्ड से रजिस्टर कर सकता है, अपने ईमेल को सत्यापित कर सकता है, अपना पासवर्ड रीसेट कर सकता है, और अपनी प्रोफाइल फोटो अपडेट कर सकता है।" चार स्टोरीज़। हर एक का एक खर्च है।Not "user management" -- that's too vague. "A user can register with email and password, verify their email, reset their password, and update their profile photo." Four stories. Each one has a cost.
Step 2: हर story को complexity के आधार पर rate करें। मैं तीन tiers का उपयोग करता हूँ:I use three tiers:
- Simple (S): शुद्ध CRUD, कोई external dependencies नहीं, standard UI patterns। सोचिए: एक settings page, एक profile update form, एक data table with sorting।(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- Medium (M): कुछ business logic, एक external integration, या non-standard UI। सोचिए: एक filtered search with saved queries, एक webhook handler, एक Stripe subscription flow।(M): Some business logic, one external integration, or non-standard UI. Think: a filtered search with saved queries, a webhook handler, a Stripe subscription flow.
- Complex (C): कई integrations, real-time features, algorithmic logic, या भारी infrastructure। सोचिए: एक live chat system, एक recommendation engine, एक multi-tenant permission model।(C): Multiple integrations, real-time features, algorithmic logic, or heavy infrastructure. Think: a live chat system, a recommendation engine, a multi-tenant permission model.
स्टेप 3: पॉइंट एस्टिमेट नहीं, घंटों की रेंज असाइन करें।
2026 में, एक मिड-टियर UK एजेंसी या एक मजबूत nearshore टीम के साथ काम करते हुए, यहाँ मेरा बजट है:
- सरल स्टोरी: 4-8 घंटे
- मध्यम स्टोरी: 12-24 घंटे
- जटिल स्टोरी: 30-80 घंटे (हाँ, वह चौड़ाई -- जटिल वास्तव में अप्रत्याशित है)
चरण 4: अपनी दर लागू करें।
वर्तमान बाजार दरें जिन्हें जानना जरूरी है:
- लंदन स्थित सीनियर डेवलपर (फ्रीलांस): £90-£140/घंटा
- UK एजेंसी (पूरी टीम, प्रोजेक्ट प्रबंधित): £80-£120/घंटा ब्लेंडेड
- मजबूत निकटस्थ क्षेत्र (पूर्वी यूरोप, LatAm): £35-£65/घंटा
- ऑफशोर (दक्षिण एशिया, फिलीपींस): £15-£35/घंटा -- और हाँ, आप यहाँ उत्कृष्ट काम पा सकते हैं, लेकिन संचार ओवरहेड वास्तविक है और इसे मूल्य में शामिल करने की आवश्यकता है
चरण 5: ओवरहेड को स्पष्ट रूप से जोड़ें।
इन्हें अवशोषित न करें। उन्हें लाइन-आइटम करें:
- प्रोजेक्ट प्रबंधन: डेव घंटों का 10-15%
- डिजाइन (यदि पहले से स्कोप नहीं किया गया है): कुल का 15-25%
- DevOps/इंफ्रास्ट्रक्चर सेटअप: जटिलता के आधार पर £3,000-£8,000 निर्धारित
- QA: विकास घंटों का न्यूनतम 20%
- आकस्मिक खर्च: ग्रीनफील्ड कार्य पर 20%, महत्वपूर्ण इंटीग्रेशन वाली किसी भी चीज़ पर 35%
---
एक वास्तविक उदाहरण: SaaS Dashboard, 2026 मूल्य निर्धारण
मुझे कुछ ठोस उदाहरण से गुजारता हूँ। एक संस्थापक मेरे पास आता है जो एक B2B एनालिटिक्स डैशबोर्ड चाहता है -- एक SaaS प्रोडक्ट जहाँ उनके क्लायंट लॉग इन करते हैं, अपना परफॉर्मेंस डेटा देखते हैं जो Google Analytics 4 और एक कस्टम इवेंट डेटाबेस से खींचा जाता है, रिपोर्ट एक्सपोर्ट कर सकते हैं, और अपनी टीम की एक्सेस को प्रबंधित कर सकते हैं।
मैं इसे कैसे तोड़ूँ:
- Auth system (email + Google SSO, role-based access):2 Medium stories = 48 hrs2 Medium stories = 48 hrs
- GA4 integration + data pipeline:1 Complex story = 55 hrs1 Complex story = 55 hrs
- Custom event database schema + API:2 Medium stories = 40 hrs2 Medium stories = 40 hrs
- Dashboard UI (charts via Chart.js or Recharts, responsive):3 Medium stories = 65 hrs3 Medium stories = 65 hrs
- Report export to PDF/CSV:1 Medium story = 18 hrs1 Medium story = 18 hrs
- Team management (invite, remove, role assignment):2 Simple + 1 Medium stories = 28 hrs2 Simple + 1 Medium stories = 28 hrs
- Billing via Stripe (subscriptions, upgrade/downgrade):1 Complex story = 45 hrs1 Complex story = 45 hrs
Raw development total: ~299 hours
£95/hr की UK agency दर लागू करें:£28,405£28,405
Add:
- Design (20%): £5,681
- DevOps setup: £4,500
- QA (20% of dev hours, same rate): £5,681
- PM (12%): £3,409
- Integration contingency (30% on GA4 and Stripe work): £3,000
Total estimate: ~£50,676
यह एक वास्तविक संख्या है एक वास्तविक उत्पाद के लिए। बिल्कुल चौंकाने वाली नहीं है अगर आप समझते हैं कि इसमें क्या है। पूरी तरह चौंकाने वाली है अगर आप £18,000 की उम्मीद लेकर आए हैं क्योंकि किसी ने आपके नेटवर्क में किसी संस्थापक को पिछले साल "कुछ इसी तरह" के लिए यही कहा था।
---
छिपी हुई लागतें जिनका कोई जिक्र नहीं करता
लाइसेंस और तीसरे पक्ष की सेवाएं
मैपिंग फीचर्स के लिए Mapbox। SMS के लिए Twilio। ट्रांजैक्शनल ईमेल के लिए SendGrid। अगर आपको सही सर्च की जरूरत है तो Algolia। ये चल रही लागतें हैं जिन्हें संस्थापक अपने सॉफ्टवेयर बजट से पूरी तरह छोड़ देते हैं क्योंकि वे इन्हें "सिर्फ APIs" मानते हैं। 10,000 सक्रिय उपयोगकर्ताओं वाला एक मध्य-स्तरीय SaaS हो सकता है कि तीसरे पक्ष की सेवाओं में £800-£2,000/माह का भुगतान कर रहा हो इससे पहले कि एक भी सर्वर बिल आए।
सुरक्षा और अनुपालन
अगर आप यूके में व्यक्तिगत डेटा संभाल रहे हैं, तो GDPR वैकल्पिक नहीं है। अगर आप पेमेंट छू रहे हैं, तो PCI DSS कंप्लायंस ओवरहेड जोड़ता है। अगर आप स्वास्थ्य या वित्त में हैं, तो आप अतिरिक्त ऑडिट लागतें देख रहे हैं जो सिर्फ प्रारंभिक सर्टिफिकेशन कार्य के लिए £5,000-£20,000 तक चल सकती हैं। मैंने संस्थापकों को इससे सच में चकित होते देखा है। हमारा एक फिनटेक क्लायंट 2023 में कंप्लायंस कार्य के लिए शून्य पाउंड का बजट रखता था और फिर लॉन्च करने से पहले उसे £14,000 की जरूरत थी।PCI DSS compliance adds overhead. If you're in health or finance, you're looking at additional audit costs that can run £5,000-£20,000 just for initial certification work. I've seen founders get genuinely blindsided by this. One fintech client of ours in 2023 had budgeted zero pounds for compliance work and then needed £14,000 of it before they could launch.
हस्तांतरण और प्रलेखन
अच्छी डॉक्यूमेंटेशन -- API डॉक्स, डिप्लॉयमेंट रनबुक्स, भविष्य के डेवलपर्स के लिए ऑनबोर्डिंग गाइड -- असली समय लगता है। कुल प्रोजेक्ट घंटों का 5-8% डॉक्यूमेंटेशन के लिए बजट करें अगर आप कभी चीज़ को बनाए रखना, विस्तारित करना, या बेचना चाहते हैं।
---
आप जो उद्धरण प्राप्त कर रहे हैं उसे दबाव-परीक्षण कैसे करें
आपके सामने एक प्रस्ताव है। यहाँ हस्ताक्षर करने से पहले इसे ऑडिट करने का तरीका है:
- संख्या के पीछे की फीचर ब्रेकडाउन माँगें। अगर वे आपको स्टोरी-लेवल ब्रेकडाउन नहीं दे सकते, तो उद्धरण एक अनुमान है।
- जाँचें कि DevOps, QA और PM लाइन आइटम हैं या एक मिश्रित दर में छिपे हुए हैं। छिपा हुआ आमतौर पर कम पकाया हुआ मतलब है।
- पूछें कि उनकी आकस्मिकता नीति क्या है। क्या वे ओवररन को सीमित करते हैं? टाइम-एंड-मेटेरियल्स या फिक्स्ड प्राइस? प्रत्येक के वास्तविक निहितार्थ हैं।
- पता लगाएं कि उन्होंने तीसरे पक्ष के एकीकरण के बारे में कौन सी मान्यताएं बनाई हैं। उनसे सीधे पूछें: "क्या आपने [विशिष्ट सेवा] के लिए API प्रलेखन को उद्धरण देने से पहले पढ़ा है?"
- पूछें कि स्प्रिंट 2 के बाद आवश्यकताएं बदल जाएं तो क्या होता है। जवाब आपको एजेंसी कैसे काम करती है इसके बारे में लगभग सब कुछ बताता है।
Basecamp की Shape Up पद्धति के पास इसके लिए एक वास्तव में उपयोगी फ्रेमिंग है: निश्चित समय, परिवर्तनशील स्कोप। किसी भी एजेंसी वार्ता में जाने से पहले इसे पढ़ने लायक है। has a genuinely useful framing for this: fixed time, variable scope. It's worth reading before you enter any agency negotiation.
---
2026 में AI Tools: वे क्या बदलते हैं (और क्या नहीं)
सभी जानना चाहते हैं कि क्या GitHub Copilot, Cursor, या agent-based coding tools की नई लहर (Devin, Replit Agent) ने सॉफ्टवेयर की लागत में महत्वपूर्ण कमी लाई है। ईमानदारी से? हाँ, थोड़ी है। लेकिन hype सुझाता है उससे कम।
मेरा मोटा अनुभव: मजबूत AI-सहायता प्राप्त डेवलपर्स greenfield CRUD कार्य पर लगभग 20-30% तेजी से काम कर रहे हैं। यह मध्य हिस्सा मानक फीचर्स का -- फॉर्म, टेबल, बेसिक auth फ्लो -- तेजी से निकलता है। लेकिन जटिल इंटीग्रेशन कार्य, आर्किटेक्चरल निर्णय, सूक्ष्म रेस कंडीशन को डीबग करना, और कुछ भी जिसमें गहरी प्रोडक्ट सोच की जरूरत है? AI वहाँ मदद नहीं करता, और कुछ मामलों में यह प्रशंसनीय-दिखने वाला कोड जेनरेट करता है जो नई समस्याएं लाता है।
अगर टीम की पुष्टि है कि वह 2026 में गंभीरता से AI टूलिंग का उपयोग कर रही है तो मैं साधारण और मध्यम स्टोरीज पर 10-15% दक्षता छूट लागू करूँगा। उससे अधिक नहीं। कोई भी आपको 50% कम खर्च में "क्योंकि हम AI का उपयोग करते हैं" बताना वास्तव में या तो एक बिल्कुल अलग तरह का प्रोजेक्ट चला रहा है जितना आप सोचते हैं, या आपको कुछ बहुत अच्छा बता रहा है।
---
FAQ
सॉफ्टवेयर estimate कितना सटीक हो सकता है specs लिखे जाने से पहले?
बहुत नहीं। विचार चरण में ±40-60% भिन्नता की उम्मीद करें। एक बार जब आपके पास विस्तृत यूजर फ्लो, एक डेटा मॉडल, और सभी तीसरे पक्ष की निर्भरताओं की सूची हो, तो आप ±20% तक पहुँच सकते हैं। वायरफ्रेम और तकनीकी आर्किटेक्चर के साथ एक डिस्कवरी स्प्रिंट के बाद: ±10-15%। पूर्ण बिल्ड बजट के लिए प्रतिबद्ध होने से पहले एक उचित डिस्कवरी एनगेजमेंट के लिए भुगतान करें -- यह आमतौर पर £2,000-£6,000 खर्च करता है और प्रोजेक्ट पर आप जो सर्वश्रेष्ठ पैसा खर्च करेंगे वह है।
क्या मुझे fixed-price लेना चाहिए या time-and-materials?
Fixed price आपको बजट की निश्चितता देता है लेकिन एजेंसी पर जोखिम डालता है -- जिसका मतलब है कि वे अनुमान को बढ़ा-चढ़ाकर देंगे और change-order clauses से अपना बचाव करेंगे। Time-and-materials ईमानदारी से पेश आता है लेकिन आपको scope को सक्रिय रूप से manage करना पड़ता है। ज्यादातर founders के लिए मेरी पसंद: प्रति sprint fixed price (आमतौर पर 2 हफ्ते), scope sprint की शुरुआत में defined हो। आपको predictability मिलता है बिना padding game के।
क्या nearshore या offshore development, management overhead को factor करने के बाद, सच में सस्ता है?
अक्सर, लेकिन हमेशा नहीं। Overhead असली है -- ज्यादा PM time, ज्यादा asynchronous communication, expectations के misalign होने से कभी-कभी rework। एक अच्छी तरह scoped project के लिए strong specs के साथ, nearshore (खासकर Eastern Europe) genuine value देता है। मैंने Polish और Ukrainian teams के साथ £40/hr blended पर successful projects चलाए हैं। किसी ambiguous और fast-moving चीज के लिए, मैं इसे घर के करीब रखूंगा।
Software proposal में red flag क्या होता है?
एक single-line quote बिना breakdown के। एक timeline जिसमें QA या deployment का कोई जिक्र न हो। Change requests को कैसे handle किया जाता है, इसका कोई mention नहीं। और honestly -- कोई भी agency जो quote देने से पहले आपके existing infrastructure के बारे में hard questions न पूछे। अगर वे आपकी constraints के बारे में curious नहीं हैं, तो उन्होंने आपके project के बारे में गंभीरता से सोचा ही नहीं है।
Post-launch maintenance के लिए बजट कैसे करूं?
Standard rule: initial build cost का 15-20% हर साल ongoing maintenance, bug fixes, और minor feature work के लिए। एक £50,000 build को £7,500-£10,000 annual maintenance budget की जरूरत है। अगर कोई आपसे कहे कि software launch पर "done" है, तो अलग software people ढूंढ लीजिए।
---
November का वह logistics founder? वह अपनी agency के पास गया, उन्होंने अपनी working process को refactor किया, और product March में ship हुआ। यह अच्छे से चल रहा है। लेकिन उसने मुझे बताया कि वह चाहता था कि किसी ने उसे ऐसा framework दे दिया होता जैसे यह कुछ और sign करने से पहले। तो। वहां यह है।