Book a consultation

30 minute meeting

Thank you

We’ll reach out within one business day. If you don’t hear from us, check spam and promotions folders.

Contact us

Fill out the form to send us a message

Attach related materials (.pdf, .docx, .odt, .rtf, .txt, .pptx; max 5 MB)
Or

Hold On

Binary Studio is a boutique software development company with a 4.9/5 rating on Clutch. For 20 years of work, we have helped over 200 companies build successful products.

Let's discuss how we can help you!

Reducing Proposal Preparation Time from 16 Hours to 2 with star star star star star an AI Knowledge Engine

Reducing Proposal Preparation Time from 16 Hours to 2 with star star star star star an AI Knowledge Engine

  • LOCATION: flag Ukraine

  • Type of Service: Custom Software Development

  • INDUSTRY: Real Estate

  • KEY TECHNOLOGY: Python

  • Project Type: AI Knowledge Engine

  • DURATION: October 2025 – December 2025

  • 2

    hrs avg
    estimation time

  • 87.5

    % less manual
    estimation work

  • 14

    hrs of sales
    work saved monthly

The Problem

In a service business like custom software development, a proposal is the first proof that the team understands what a client needs and what resources it will take to deliver it. The quality of the estimate behind it sets expectations on both sides.

For two decades, Binary Studio's estimates relied heavily on engineers' experience and institutional knowledge. When a new request came in, an engineer reviewed the requirements and drew on similar past projects to identify likely features and scope the client hadn't explicitly stated. Much of this reasoning followed patterns the team had seen before, yet engineers had to repeat the same analysis for every proposal. On average, each estimate required around 16 hours of senior engineering time.

To reduce this manual effort, the first experiment tested whether a general-purpose language model could accelerate the estimation of new projects. The model could interpret individual requirements and generate plausible-looking scopes, but giving it historical context did not make the results reliably accurate. The challenge was not access to information; it was applying engineering judgment to determine which requirements implied additional scope and which past projects were actually relevant to a new estimate.

This shifted the engineering problem from giving AI access to company knowledge to building a system that could retrieve relevant delivery experience from past projects and apply it to new estimates.

A good software estimate depends on the quality of thinking behind it.

A good software estimate depends on the quality of thinking behind it. By automating repeatable analysis, we freed senior engineers to spend more time where their knowledge matters most: challenging assumptions, spotting gaps, simplifying solutions, and identifying delivery risks. Our clients now get estimates faster, with more engineering judgment shaping each proposed solution

AI Proposal Automation for Software Estimation-2

Volodymyr Koberniuk

Head of Delivery at Binary Studio

AI Proposal Automation for Software Estimation-3 UKRAINE

Objectives

The team translated this insight into three practical goals:

  • 01

    Give engineers a strong starting point for every software estimate.

    Use AI and historical delivery knowledge to prepare an initial estimate, so engineers can focus their time and judgment on improving the proposed solution.

  • 02

    Make every estimate more thorough and consistent.

    Ground estimates in Binary Studio’s delivery knowledge, so relevant experience from past projects is applied systematically and important scope is less likely to be missed.

  • 03

    Make AI-assisted estimation part of the existing workflow.

    Connect the process with the tools Sales and Delivery already use, so teams can adopt it without adding new tools or manual steps.

Сustom AI solutions development

Turn your company’s knowledge and expertise into AI solutions that automate high-value work and help teams apply expert judgment at scale.

Learn more

Solution and Outcome

  • The team ran two experiments in parallel and tested them against the same historical data. One gave the AI room to search past projects and reason on its own. The other boxed it into a narrow role and let deterministic rules handle the reasoning.
  • These experiments shaped the knowledge and reasoning engine that followed.
AI Proposal Automation for Software Estimation-4
Python
AI Proposal Automation for Software Estimation-5
n8n
AI Proposal Automation for Software Estimation-6
Ollama
  • Stage 1

    Turning 100+ projects into a machine-usable delivery knowledge

    The first task was turning Binary Studio's accumulated project history into knowledge the estimation engine could systematically reuse. Historical projects contained valuable information about scope, effort, timelines, and team composition. But simply making those documents available to an LLM would still leave the model to decide which experience was relevant to each new request.

    The team first tested two conventional approaches for finding relevant information across past projects. Both broke down at scale.

    Tested approach 

    Results

    Single-vector embeddings per document

    Worked on a small set, but as the dataset grew to a few dozen documents, retrieval started surfacing irrelevant technologies and blurring unrelated domains.

    Textual similarity matching 

    Matched requests based on shared vocabulary, causing projects from unrelated industries to score as highly similar simply because both mentioned users, databases, and search.

    The experiments showed that similarity alone wasn't a reliable basis for estimation. To connect new requests with relevant delivery experience more systematically, the team analyzed 100+ completed projects and organized the findings into a shared taxonomy covering three core dimensions: industry, integrations, and features.

    Each category contains anonymized delivery data on timelines and team configurations. This lets the engine combine evidence from multiple projects instead of treating one past project as the template for a new estimate.

    The result is a private, domain-specific knowledge layer grounded in how Binary Studio has actually delivered custom software development projects.

  • Stage 2

    Identifying requirements clients leave out

    The next challenge was harder than retrieval. Even with relevant historical knowledge, an estimate can still be incomplete because clients rarely describe every feature and dependency their system will require.

    A key architectural decision was not to ask the language model to generate the complete project scope directly. LLMs are effective at interpreting unstructured requirements, but allowing the model to perform the entire reasoning process would make critical scope decisions dependent on probabilistic generation.

    The team therefore separated the problem into two steps: the language model interprets the client's request; the deterministic engine uses rules to uncover what those requirements imply.

    First, a locally hosted open-source language model running through Ollama maps the request to a controlled vocabulary of features. This gives the system a consistent representation of what the client is asking for.

    The features then pass to a deterministic pattern engine written in Python, which applies the estimation logic based on:

    • 27+ expansion rules for implied scope
    • 100+ predefined features
    • 20+ domain and feature signals
    • relationships between features and the Stage 1 taxonomy

    The rules expand the initial scope based on the features and signals extracted from the request. One feature can imply additional functionality, while domain signals determine which rules apply. The Stage 1 taxonomy then connects the expanded scope to relevant historical delivery data.

    The system then validates the scope against historical data, assigns a confidence score, and produces a structured draft covering effort ranges, team composition, and timeline. The senior engineer then reviews the draft and focuses on decisions the engine can't make, such as the architectural approach, technical constraints, opportunities to simplify the solution, and potential cost or delivery risks.

  • Stage 3

    Automating the workflow from sales request to engineering review

    To reduce proposal preparation time, the estimation engine also needed to fit into the tools and workflows Sales and Delivery already used. Otherwise, managers would still have to collect project materials, prepare inputs, and move the results between systems manually.

    Sales works in Pipedrive, Delivery in Asana, and project materials are stored in Google Drive. The team connected these systems with n8n, self-hosted on Binary Studio's DigitalOcean infrastructure.

    The workflow is triggered by two key moments:

    • Lead intake: A new inquiry is parsed, added to Pipedrive with the available project materials, and routed to Sales.
    • Proposal request: When a Sales Manager moves the deal to “Proposal Requested,” the workflow organizes the project materials in Google Drive and sends them to the estimation engine. Once the analysis is complete, an Asana task is created with the estimate for engineering review.

    Together, these steps let the system coordinate the entire handoff: project materialsestimation enginestructured estimateengineering review.

    By the time the request reaches Delivery, the engineer has a proposed scope broken down into individual pieces of work, each with minimum and maximum effort estimates, along with the overall estimate, team composition, and budget. With this groundwork already done, the engineer can focus on the project-specific technical decisions needed to finalize the proposal.

    workflow automation.avif

    Automated proposal estimation workflow

The Results

  • Reducing manual estimation work from around 16 hours to 2 — an 87.5% drop per proposal — frees valuable senior engineering capacity for higher-value work during pre-sales. Instead of spending that time reconstructing what Binary Studio already knows from previous projects, engineers can put more thought into whether the proposed solution makes sense, where it can be simplified, and which technical choices could materially change the cost or delivery approach.
  • For clients, this means more senior engineering judgment before they commit to a project. They receive a faster response and a more considered recommendation, with senior engineers spending more of their time on the questions that can influence what the client ultimately builds and how much they invest.
  • For Binary Studio, the same engineering capacity can support more opportunities while giving each proposal a higher level of technical attention. Automation of the surrounding workflow also recovers around 14 hours of Sales work each month. This improves the economics of pre-sales while helping Binary Studio produce stronger, more tailored proposals — ultimately giving the company a better chance of winning the projects it pursues.

About Binary Studio

  • Binary Studio is a boutique software development company, regularly praised for its unique blend of engineering excellence and product ownership that enables its clients to build robust and scalable software products.
  • With our development team made up of top 0.5% international tech talent, we build web and mobile platforms using Node.js, .NET, React Native, Flutter, and integrating AI and ML. We also offer full-cycle QA and project management services to ensure the efficient delivery.
  • Our clients see us as a trusted partner dedicated to turning visions into great products. This is proven by 200+ delivered projects, more than two decades of business excellence, and stellar customer reviews.

Schedule a tech consultation

Client ManagerClient Manager

Christina Berko ⠀ 

Client Manager

Maria Kudriavtseva ⠀ 

Pre-Sales Project Manager

Thank you

We’ll reach out within one business day. If you don’t hear from us, check spam and promotions folders.

Send us a message

Attach related materials (.pdf, .docx, .odt, .rtf, .txt, .pptx; max 5 MB)