We realize that all projects have a time and cost budget. Everyone wants to know what they will get for a certain amount of money and time. At the beginning of a project, we do create a very rough high level estimate for the entire scope of work. However, by definition all estimates are wrong. We know the very least about your project at the beginning and is why we work in iterations.
Once the project is approved, we work in iterations for the project. Meaning we sell individual blocks of time for a given set of functionality. At the end of each iteration, which usually last one to two weeks, a production ready feature set is given. If you are happy what we did for that iteration and you are a good fit as a customer, we can continue with another iteration.
We have found that this works best for customer budgets and scope. It also makes for a good no risk trial period.
Fixed bids are unfair to one party or another. The customer either pays too much or we are not paid enough. The only way that this works is when we are very efficent with estimates. Humans are notoriously bad at estimating. When was the last time you were late for a meeting that was in an area you have been to a million times before? This was due to bad estimating even though you "know" how much time it should take you.
We, in all likelyhood, do not know your domain. If we don't know the domain, we won't know how much revenue will be generated. Even if we do know the domain, we will rely on others to execute for us.
There may be a small chance we would be interested in this but it more then likely depends on the people involved rather then the idea. This would require a relationship to be built over time. This can be done but it won't be done overnight.
Perhaps. If the RFP does not require a fixed bid project and allows us a lot of freedoms, we may be interested. This however is a sign that we may not be the right fit for the customer. Since we value time, just the creation of RFPs as well as the required reading of them does not fit into our values.
This is not beneficial for either party in our opinion. Your internal IT team have their own culture and we have ours. If we can find a way for those to mesh, it may work out. We have found, through experience though, that this tends to slow down development.
If your internal team are not very test driven design oriented, it will not work. We simply do not know of another way to work.
If this is meant as a training opportunity and that is spelled out in front, we make room for a lot more inconsistancies. We love to help fellow developers as long as training is on equal footing as completing the project.
If you have a project that you would like us to consider, please fill out the project planner .