Estimates separate professionals from amateurs. Estimates mark the point at which every reliable development team becomes precise about its promises. Why? The devil is in the details. Your project could well fit in with the basic range of app development costs, but startup costs might vary greatly. Why? Every startup development project contains three parts:

  • known (e.g., log in using social network account [FB, LI, Gmail])
  • unknown known but can be figured out (e.g., adding payment system)
  • unknown unknown (e.g., adding an AI algorithm)

Estimates make it possible to categorize single elements of the entire startup development process then balance them on a project roadmap based on project limitations (budget, timeline).

Check out how IT Craft developers provide estimates on software development for startups.

Short on time and just want to get going on your project?

No problem. Contact us and get an estimate free of charge. No obligation.

Why estimates are important to you, a startup

A map is not the actual land. The same is true with project estimates. Although estimates are well-informed speculation and not the final word on startup costs, they provide enormous value.

They set up expectations concerning the startup development process and project deliverables.

On one side, you—a business—want to make sure the team helps you with startup development by delivering the result you want based on your priorities and your startup budget.

The team:

  • Understands project goals.
  • Possesses required skills and resources.
  • Is keen to deliver great results and not just trying to get the contract.
  • Remains transparent; no hidden costs.

On the other side, the development team makes sure it understands project goals. It gets acquainted with project details and determines whether the declared goals are achievable based on input provided.

The team determines:

  • What processes, team members, and resources are needed.
  • How they are going to achieve the result.
  • How long it might take.
  • Possible pitfalls, bottlenecks, and tradeoffs that might affect the end result.

How does IT Craft produce estimates?

IT Craft’s estimation process makes it possible to handle different types of requests:

  • general descriptions of app idea
  • elaborated software requirements
  • changes for ongoing projects
  • requests for team augmentation

And more—whatever software development startups need.

Each request undergoes a four-step process to ensure we can turn a preliminary, ballpark estimate into an elaborate development proposal.

Foodie
  • Step 1. Request management

    We start with signing an NDA, so you can discuss idea details and plans safely.

    One of our business development managers receives a request with your commentaries (notes, links, sketches, wireframes, etc.). The team analyzes them and prepares clarifying questions.

  • Step 2. Initial call

    We schedule a video call where we get to know more about your project. You meet your main contact points: project manager, business development manager, business analyst/lead developer. They ask you clarifying questions to understand the “big picture” of your project. And we introduce you to our company.

  • Step 3. Estimation process

    This step contains several sub-steps:

    • The team prepares a feature list for required functionality.
    • You verify and approve it. If needed, it can be modified.
    • The team estimates the scope of work.

    To clarify all project details, several extra calls are possible at this juncture.

    You then get an estimate of required working hours for your project. The estimate also includes required project activities and team composition.

  • Step 4. Proposal preparation

    At this step, the team prepares a development proposal.

    It includes:

    • approved feature list
    • goals and deliverables
    • team squad
    • project timeline
    • cost estimates and hourly rates

Project too complex, estimate too general. What then?

If only a general estimate is possible based on information given for the project, we initiate the Discovery Phase to clarify requirements, identify risks, and specify estimates of startup costs.

The Discovery Phase is crucial for moving forward with complex projects. Depending on risks and complexity, three types of outcomes are possible,

  • A detailed estimate

    That can include:

    • Detailed feature list from which the team breaks down main features into smaller ones.
    • WBS (work-base statement) that includes planned, non-development project activities (design, testing, business analysis, project management) needed to get the project up and running.
  • A visual presentation

    This could be:

    Visual presentations are required for startup development projects with too many unknown details or for complex domains where a detailed feature list might not be enough to determine startup costs for commercial development.

  • Prototype
    • Clickable prototype – Visual presentation of a future product or its part.
    • Technical prototype – Study of any key technical points that present the biggest risks.

    The development team does prototypes first to start small, study how things work, and avoid producing irrelevant software.

    The team estimates prototypes separately and then provides an estimate for software development based on the finished prototypes.

  • Here is more on estimation approaches

    Different request types require different estimation techniques. The following techniques make it possible to provide preliminary ballpark estimates for startup development quickly:

    • Top-Down and Bottom-Up

      Project manager divides the entire project into smaller, hierarchical parts. These parts represent software components and activities needed to build them. The team either estimates major deliverables (top down) and/or makes a detailed estimation of separate tasks and totals them (bottom up). Developers do both.

    • Analogy Estimation

      Developers check their estimates for same or similar activities on previous projects and compare with the time they actually spent. When there is a large discrepancy between an estimate and actual working time, they might expect challenges and add buffer time.

    More estimation techniques apply for task estimations during the Discovery Phase and ongoing projects. They are time consuming:

    • Expert Estimate

      If there is neither data nor experience, an expert provides an estimate based on previous industry experience, working with a similar technology, and understating of possible risks.

    • Wideband Delphi

      Team members prepare estimates on specific tasks. Then the team discusses estimates in a group meeting with a special focus on those activities where estimated hours vary greatly. Sessions continue until the team agrees on estimates.

    • Three-point technique

      Team members provide three estimates for best-case scenario, worst-case scenario, and most-probable scenario. Based on provided numbers, developers determine a weighted average estimate.

    Correct estimates become challenging for projects with many unknowns, e.g., achieving a tight deadline under a budget constraint or managing flexible requirements. In this case, they use the Agile approach for estimates, including:

    • Value estimation

      The team decides on top priorities, i.e., features that bring greatest business value, and delivers them first. The entire feature list is prioritized based on importance, keeping in mind dependencies between parts of the system.

    • User stories

      Developers formulate short statements on what users make in the system (e.g., login using email). The team prioritizes them and provides estimates on work needed to complete and finalize a user story. Developers use experience they accumulate while working on user stories to refine estimates. A project manager organizes user stories in the backlog for further reflection on project progress.

    • Story Points

      Story Points lets a team measure efforts spent on a User Story. User Stories are relative to each other, i.e., when a User Story A takes 1 Story Point and a User Story B takes 5 Story Points, User Story B requires from the team five times more effort and time (e.g., login using email costs 1 Story point; login using FB costs 5 Story Points. Therefore, developers will spend five times more on it). A Story Point includes all aspects of software development needed to complete a certain User Story.

    • Planning poker

      Planning poker is a variation of Wideband Delphi for Agile development. Team members estimate items on the list of User Stories by laying down cards with the number of Story Points. The team negotiates on workload until consensus is reached.

Factors affecting estimates

Several factors facilitate dialog and pave the way for a more precise, relevant estimate:

  • Project details

    Business details and technical details are equally important. If the team clarifies your business goals and understands why you initiate the project, they will identify a more direct, faster path to your target market.

  • Budgeting

    Although clients are sometimes reluctant to disclose their startup budgets, knowing often means parties can reach the best possible agreement. When the team knows about budget constraints, it provides good-better-best scenarios on software development. Startups launch with manageable trade-offs.

  • Deadlines

    Developers work to deadlines—if not yours, then theirs. For startups, meeting fact-based deadlines could be the key to survival. To avoid unrealistic goals, they must be handled carefully and discussed in advance.

  • Regulations

    Some industries are subject to strict regulations. Different rules might apply when software goes globally (e.g., HIPAA/GDPR for medical software development). This adds to the scope of work on a project and to startup costs.

  • Flexibility

    In startup development, the team often works on a project without having finalized requirements. In this case, a general estimate is possible which becomes more precise as the team introduces more functionality.

Are you confident in estimates?

Yes, IT Craft is confident in estimates. Here is why:

  • Focus on value

    We consider what brings the greatest value to business startup costs and how we can deliver under given circumstances.

    We decide on:

    • what to deliver first
    • then next and next and next…
    • how to deliver a sustainable product.
  • Estimation Autonomy

    Developers who work on the project know how they want to deliver it. They decide on estimation techniques and methods that best suit their needs and yours. No outside interference is possible.

  • Estimation Ownership

    Each team takes responsibility for the estimation techniques it uses and estimates it gives. It also means that the team regularly revises its estimates and addresses gaps and issues if they arise.

Is it possible to reduce an estimate?

Yes, a reduction in a cost estimate is possible. IT Craft developers always remain open to dialog. Every client has a unique situation. Startup costs for business might be too high at certain startup development phases. Because of this, we strive to do the best possible to ensure long-term, successful software development for a startup.

The rule of thumb for decreasing startup costs for a business: maintain high quality, cut scope.

This is what is possible:

  • Revise scope of work – fit in with desired budget range and/or timeline.

  • Provide an estimate based on an alternative tech stack – use of third-party modules saves a client’s development budget and reduces development time.

  • Start with an MVP – focus on key functionality to publish fast and open up time to look for further financial backing.

Tactics IT Craft NEVER uses that could lead to lower quality:

  • IT Craft never allows intervention from outside parties during the estimation process – the team provides estimates based on its experience and knowledge taking ownership of their estimates. Recommendations are not accepted.

  • IT Craft never skips project steps crucial for high quality – for example, QA is the key part of the startup development process and cannot be skipped.

  • IT Craft never negotiates with its hourly rate – our company’s rate is based on multiple factors, including bringing in experts to the project to guarantee a high-quality finished project.

Estimates may vary. Why?

You might have shown the same requirements to several companies and they have returned different estimates.

This is normal: companies CAN ensure lower costs of software development for startups. Also, low estimates are red flags. Check the following reasons:

  • different hourly rates (Central/Eastern European hourly rates are 3 – 5 times lower than North American)
  • difference in companies’ pricing policies (easier to provide money back than improve quality source code)
  • difference in experience (less experienced teams charge lower rates but take longer to build and finish projects)
  • particular niche focus (niche companies tend to charge higher. (NB! They might build faster. Do the math.)
  • choice of tech stack (e.g., use of React or Nest.js framework decrease scope of front-end development)
  • items included in the feature list (often a source of hidden costs; see below)
  • different degrees of risk (due to tech novelty or lack of experience)
  • personal estimation (several scenarios are weighed, see Estimation approaches)

An important note. At IT Craft, we neither transfer estimates indiscriminately between our teams nor accept other companies’ estimates.

We had clients whose business startup costs were too high due to multiple expenditures on fixing buggy source code produced by a previous development company. Moreover, their startup costs would have been lower if they had started startup development anew. Therefore, even if something seems “almost” fine, we make sure we can deliver promises.

Furthermore, when an IT Craft team prepares an initial estimate on possible costs of software development, a startup might take several months looking for investment. The project might go to a new team after the initial team took another project.

In this case, the new team might use the other team’s notes but it prepares its own estimate. We must ensure the new team understands the project and stays on the same page with the client.

Consider these signs of hidden costs when negotiating with a company

Experienced, reliable developers do not give ad-hoc guesses on startup development prior to studying the project’s requirements. Estimates, they caution, are a way to measure complexity and duration. They are NOT the final word.

Delays emerge due to unexpected technological challenges: the startup development process is full of unknowns. Even the best developers might deliver late or ask for a certain increase in startup budgets. But they will deliver.

Things get bad with inexperienced or dishonest startup development providers. An unreliable team will break its promises, produce low-quality source code, or even take source code as hostage forcing the startup to pay more than originally agreed—and then never deliver.

How do you determine hidden costs before you sign the dotted line? The following signs warn you should be accounting for startup costs that are hidden from you:

  • Not asking for details on your project idea

    The project manager pays little attention to your concerns on a call. There will be little to no responsibility taken during project development. Does he/she readily say yes to everything? Does the company urge you to sign a contract for an immediate start? If all that company seems to care about is your signature, better to just walk away and look for another team.

  • Generalized estimate

    A ballpark estimate is perfectly fine for a general app idea. However, the team should offer a discovery stage to produce a roadmap based on your plan before actual development starts. No roadmap, no plan to follow usually results in startup costs skyrocketing.

  • Suggesting different path

    Did you ask for a Web app and the manager offers native mobile app development without giving any reason? If a company does not listen to you at the beginning, it will not listen to you or read your messages during the project.

  • Low estimates

    The team promises to complete the project within two months when other teams ask for 4-5 months. Does it say it has done the same project recently? Ask for the references. Or be prepared for at least a nine-month timeline and increased total startup costs.

  • Sudden changes

    Does a new project manager appear in the middle of negotiations with no explanation? If a project manager disappears and is replaced, anticipate the same will happen with senior developers. You won’t even know about it. Each replacement increases startup costs for a business and negatively impacts source code quality.

In conclusion: Points to keep in mind when reviewing an estimate

Estimates present the starting point of a discussion to help both client and development team clarify where they are, where they want to be, and what it could take to get from here to there.

Estimates ensure the client and the team remain on the same page. The client knows the team understands project goals, challenges, and deliverables. The client understands the team strives to provide the best solution and is open to discuss project deadlines and limitations.

A professional team always does the following:

  • Focuses on business value.
  • Uses several techniques to estimate accurately and offers good-better-best scenarios.
  • Takes responsibility for providing fact-based estimates.

Most common questions about software development estimates

  • What are main steps of software development estimates?

    Software development estimation includes the following steps:

    • Getting your request
    • Initial (introduction) call
    • Estimation process (extra clarification calls are possible)
    • Proposal preparation
  • Can I merge time-and-material and fixed-time approaches?

    Yes, it is possible to fix an absolute hourly or budget limit on your project and then negotiate with the team on an hourly rate or scope of work. The team will alert you in advance about an approaching limit. You decide to either accept an overage or shift work to the next month.

  • How accurate are software estimates?

    The accuracy of software estimates depends on both the amount of detail given at the beginning and the scope of work. Precise estimates work for small projects with clearly defined scope e.g., WordPress website development for small business.

    Otherwise, startup development projects contain uncertainties.

    Uncertainties result from:

    • project complexity
    • technological novelty
    • requirements elaboration

    For those projects, only approximate estimates are possible.

  • Which estimation method is the best?

    The best estimation method depends on type and completeness of requirements. Most common methods include:

    • Top-Down and Bottom-Up
    • Analogy Estimation
    • Expert Estimate
    • Wideband Delphi
    • Three-point technique
    • Value estimation
    • User stories
    • Planning poker

    For the best results, developers use several methods simultaneously.

  • How can software estimates be improved?

    The fuzziest estimates are at the beginning of a project when too many uncertainties exist. Estimates become more accurate after a couple of milestones when the team gets acquainted with the project.

    Also, going through the discovery stage, preparing wireframes, and prototyping remove many uncertainties and help improve estimates.

Do you want to know a free estimate for your business?

It’s simple. Contact us.