Let’s talk about your software project’s budget.
Boomcycle has built software for clients for as low as $10K and as much as half a million dollars. What does that say? Not much, since each mobile, database or web application project is somewhat unique. Some potential clients with whom we speak want us to tell them after a 15 minute conversation: “So, how much is this going to cost”. But until “this” is thoroughly defined, we don’t yet have nearly enough information to tell them much of anything useful.
Let’s take stock of what we know about a client’s software project from the very beginning. These are the things that most people know before they start a project:
- A lot of information about their business model or concept
- Something about the software and systems they currently have
- A good idea of their budget or what they can afford
These are the things Boomcycle knows:
- How to design and create robust, secure and easy-to-use software systems
- What functionality is technically feasible (and unfeasible)
- How to optimize business workflow
- (…as well as a lot of other techie stuff!)
Note that each party has important information to share which the other party lacks. However, the client holds perhaps the single most important project guideline upon which they will ultimately make their decision: the budget.
The Budget Fear
Many new clients fear that “revealing” their budget will cause the price of the project to magically be exactly their budget. Add to this the fact that the web encourages a “comparison shopping” mindset — just about every eCommerce website we visit has buttons to compare different products or services. This sort of functionality is of course feasible due to the fact that all the products and services to be compared are extremely well-defined.
Is the software system you wish to build well-defined? Do you have a technical blueprint in hand? (If so, great! Tell us about your project!)
We create happy clients and long-term business relationships by exceeding expectations whenever possible. We want to build exactly the system your business requires. This means we need to work together.
A Software Project is a Collaboration
At Boomcycle, we believe the most logical way to begin a software project is to create a project “blueprint” in collaboration with the client. The “blueprint” is a complete functional and technical specification which describes clearly and in detail how the application is to be used.The blueprint is used to estimate the project’s timeline and develop a quote.
Generally, our clients do not approach us with a project blueprint and they need help in order to create one. To make matters more challenging, the client often receives sketchy quotes from other vendors. Unfortunately, without a project blueprint, every “quote” is simply a not-well-enough-informed guess.
Software engineering is as far from “guesswork” as any other form of engineering. Would you drive over a bridge whose builders took a guess as to how much weight the structure would support? Would you enter an underwater tunnel whose designers guessed at how much water pressure the tunnel would need to withstand? These projects don’t tolerate guesswork and neither should your project.
The Not-So-Secret Budget Secret
The cost of the system you wish to build is a function of the number of hours it takes to build.
Your software engineering team requires a definition of what is to be built. For most clients, developing such a definition on their own is a daunting challenge or perhaps even completely impractical. That’s why we strongly recommend that you develop your project’s blueprint in consultation with a Boomcycle software systems architect. For a simple system, the architectural process might require a few days. For more complex systems, the interview, Q&A and research process required to develop the blueprint might take several weeks.
In conjunction with the design of the system architecture, many times technical feasibility of an architecture must be explored. For example, perhaps your design may need a hundred map points to be drawn on the web browser within two seconds. Therefore you need to create a test harness in order to determine whether or not the major browsers can handle this type of a design requirement. This type of work is often referred to as “R&D”. The R&D step can be safely ignored in the case of trivial requirements (“The company logo must display in the upper left-hand corner”) but non-trivial, core requirements should always be tested before being baked into the architecture.
A reasonable industry-wide metric is that a software architectural blueprint will account for approximately 20% of your project budget. You may now more easily appreciate the unlikeliness of a salesman telling you how much your project is going to cost and how long it’s going to take after a phone call or two.
It’s easy to say yes to a low-ball sales-pitch quote and not get the system you need. It’s just as easy to blue-sky/over-design and end up with a system that won’t produce a healthy return on investment. In many cases it may be best to start with a small but robust system that provides a solid foundation for expansion, then add on features as your budget allows.
Working together with your software vendor in well-defined steps produces the most reliable and measurable results — not guesswork and guesstimating. As with most journeys in life, the first step is the most important one.
What’s the right approach for your project?
Let’s Get To Work!
Let us help you make smart software decisions. We are only a click away!