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 fit well with the basic range of app development costs, but startup costs might vary greatly.
Every startup development project contains three parts:
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.
Contact us and get an estimate free of charge.
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 ensure the team helps you with startup development by delivering the result you want based on your priorities and your startup budget.
The team:
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:
As a result, you estimate startup costs and verify the team delivers a solution for your vision.
IT Craft’s estimation process allows to handle different types of requests:
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.
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.
We schedule a video call to learn more about your project. You meet your main contacts: project manager, business development manager, business analyst/lead developer. They ask you to reveal more project details to understand your project’s “big picture.” And we introduce you to our company.
This step contains several sub-steps:
a) The team prepares a feature list for required functionality.
b) You verify and approve it. If needed, it can be modified.
c) The team estimates the scope of work.
Several extra calls are possible at this juncture to define all project details.
You then get an estimate of required working hours for your project. The estimate also includes required project activities and team composition.
At this step, the team prepares a development proposal. It includes:
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. Three types of outcomes are possible depending on risks and complexity:
This step contains several sub-steps:
Detailed feature list
WBS
This could be:
Wireframes
Use case diagram
ERD
User flow diagram
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 estimate startup costs for commercial development.
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. In its turn, businesses too estimate startup costs more precisely.
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 the same or similar activities on previous projects and compare them 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 similar technology, and understating 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, worst-case, and most-probable scenarios. 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., log in using email costs 1 Story point; log in 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.
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.
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.
Several factors facilitate dialog and pave the way for a more precise, relevant estimate:
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.
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 for software development. Startups launch with manageable trade-offs.
Developers work to deadlines—if not yours, then theirs. For startups, meeting fact-based deadlines could be the key to survival. They must be handled carefully and discussed in advance to avoid unrealistic goals.
Some industries are subject to strict regulations. Different rules might apply when software goes globally (e.g., HIPAA/GDPR for healthcare development). This adds to the scope of work on a project and to startup costs.
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.
Yes, IT Craft is confident in estimates. Here is why:
We consider what brings the greatest value to business startup costs and how we can deliver under given circumstances.
We decide on:
Developers who work on the project know how they want to deliver it. They decide on estimation techniques and methods that suit their needs and yours. No outside interference is possible.
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.
Yes, a reduction in a cost estimate is achievable. 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 attainable:
Tactics IT Craft NEVER uses that could lead to lower quality:
Here is more on costs of building an MVP for a startup.
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:
Make sure to consider the factors above when you estimate startup costs.
Important note. At IT Craft, we neither transfer estimates indiscriminately between our teams nor accept other companies’ estimates.
Make sure to consider the factors above when you estimate startup costs.
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 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 to look 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.
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. Be prepared to estimate in a range when you estimate startup costs: the development process is full of unknowns. Even the best developers might deliver late or ask for a certain increase in budget. But they will deliver.
Things get worse with inexperienced or dishonest service providers. An unreliable team will break its promises, produce low-quality source code, or even take source code as hostage forcing the founder 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:
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 just to walk away and look for another team.
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.
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.
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 references. Or be prepared for at least a nine-month timeline and increased total startup costs.
Does a new project manager appear in the middle of negotiations without 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.
Read more about top app development companies and how you can find them for you.
It’s simple. Contact us.
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.
Deliverables such as a feature list, wireframes, user flows, etc., ensure the client and the team remain on the same page when they estimate startup costs. 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 discussing project deadlines and limitations.
A professional team always does the following:
Software development estimation includes the following steps:
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.
Software estimates’ accuracy depends on 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.
Otherwise, startup development projects contain uncertainties. Uncertainties result from:
For those projects, only approximate estimates are possible.
The best estimation method depends on type and completeness of requirements. Most common methods include:
For the best results, developers use several methods simultaneously.
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.
Get insights about startups, hiring, devops, and the best of our blog posts twice a month.
