Building your complex website or mobile app can seem like a daunting challenge.
Fortunately, we’ve walked this road many times, and we know the way...
One of the best ways to ensure that your project moves from idea to completion is to secure the focused attention of the right development team. That’s why we will typically assign a team of at least 3 developers to your project. Each project receives a lead developer (typically, one of our senior developers), one or more collaborating developers, and a front-end developer/designer. This core team will have the skills needed to execute on your vision and launch your finished product.
The lead developer is responsible for understanding your overall project requirements and for devising a development plan that suits. The lead developer will be heavily engaged in the architecture and hands-on development activities on your project, and will become a primary point of contact on your project. When you want to discuss your project, you'll be talking directly with the lead developer— not with a salesperson or project manager. The lead developer will pull in additional team members who will lend their expertise as required by your project. This often includes a UX designer to create a beautiful interface, or an infrastructure specialist to work on server configuration and performance optimization.
And, of course, there is one more key member of the project team— you. You'll participate in regular project calls and working sessions with your developers at RDG to ensure that your best ideas are expressed in the finished product.
A small project might require 1-2 weeks of development time, while a large, complex project might span several months. It is exceedingly rare for a project to celebrate a birthday, so if you think in terms of weeks instead of days, and months instead of years, you're in the right ballpark.
When embarking on a new project, our clients often ask, "How much is this going to cost?"
That's a reasonable question to ask, but one that can be surprisingly difficult to answer. Why is that?
The Myth of "In Scope/Out of Scope"
Despite your best intentions and efforts, there are always many unknowns at the start of a project. We have seen lengthy project specification documents (designed for purposes of obtaining a fixed-bid estimate) that still barely begin to describe the eventual product that is developed.
We've also seen the opposite extreme — project descriptions that are so scant and loosely defined that they could mean anything. But neither of these extremes have proven reliable as a way to determine whether a feature or design idea falls "within scope" or "out of scope." Invariably, the fixed-bid approach to estimating software projects leaves somebody with the short end of the stick. Either the project is over-estimated for safety, or under-estimated based on incomplete facts. If the estimate is too far from reality, the result can be building the wrong finished project in slavish devotion to the original scope document — an unfortunate tug of war to determine what portion of the development should be considered in-scope or out of scope. There has to be a better way...
Because requirements and implementation details always evolve during design and development, our standard approach is to recommend a responsible budget that gives each project enough resources to be successful. Based on our review of your project requirements, competitor sites, and our conversations, we agree to an appropriate amount of developer hours that seems sensible for the kind of project you are looking to build. Then we divide the budget of hours into a series of weekly development sprints, reviewing progress and refining goals each week. In this way, you will have a clear view of progress as budget is applied, and together we will be able to prioritize new ideas that invariably emerge throughout the project timeline.
Our goal is to arrive at a usable product as early in the schedule as possible. You may pause or discontinue development at any point, and if you choose to do so, launch your project without using all of the allocated budget. Conversely, sometimes custom features or design ideas might be introduced after development is underway, and these may require additional hours beyond the approved project budget (or may require that other project elements be scaled back in order to stay within budget).
The key concept here is that we are all partners in building the best possible product for your company or organization, and we need to work together to apply the available resources as efficiently as possible. Some projects have fixed deadlines— a product or business launch; a tradeshow; a customer event. Others are perpetual— ongoing improvements for a business system. Our process is intended to deliver a high-quality end-product within the available budget and to keep you in control of your budget. You decide whether to continue using developer time or to pause development and launch.