FAQ

Because we do things differently, we get a lot of questions. These are the most common. If you don't see the answer to yours, please send us an email by filling out the form at the bottom of this page.

We use the SCRUM methodology in our development and we apply those same principles to our interactions with customers. The problem with most software development teams is that all relationships are as strong as the trust they're based on, but traditionally either the customer or the development team had to take all the trust. In our process
  • we we show you trust by presenting our ideas to solve your problem
  • you trust us enough to make a few choices and begin the project
  • we show you progress throughout the project and use your feedback to make sure we're on the right track
and so on. Nobody is extended further than is necessary, and only for a short while. We give you small pieces of production-ready products and build on them, so at any point you can decide to stop with what we've done and/or take the project in a different direction- no more time wasted on work that it turns out you didn't want done.
We can commit to a fixed price and be certain that our customers will be satisfied because of all the feedback that we give and require from our customers. Our process makes you a member of our team, and our success depends on you making wise business decisions. Nobody has ever come to us and said that we shouldn't have trusted them- you know your business better than we do, and we rely on that. We always give you a good idea of what your project will look and behave like before we start so that we're not blindly hoping that we did a good job, and if at some point we've misunderstood or you realize that you want something to be different, we've been planning to break our work into small pieces so that changing the work we haven't done yet isn't an issue.
Our team is made of people who can both write code and talk to people, while in most shops you have two different teams for that. Most shops want to split those roles up because it takes a lot of effort to figure out what a customer wants, but our process of just planning when necessary both keeps us able to change direction quickly and avoids time wasted planning work that doesn't end up getting done, so we all wear all the hats. Development projects are never really successful unless the customer knows what he or she wants, but you don't often know all the choices to make until you've seen the effects of others; our way of doing things helps us to work more effeciently and helps our customers figure out the best way to solve their problems.