Why Working With Us Is Different
We focus on providing high-end services.
- They say you can only have two out of cheap, fast and good. We focus on getting the "fast" and "good" parts with our process. Strangely enough, it will often be cheaper than others, but that part is not our main focus.
- We spend on a day to day basis great part of our time to learn new technologies and "sharpen our axe". We coin ourselves as "high end" and we work hard to really stand by it. It allows us to build your application in a way that will leave your future users and competitors in awe.
- We don't like unpleasant surprises. I guess you too. We do like pleasant surprises though. We prefer to be realistic/pessimistic in our estimations, both on time and money. There are no hidden costs. Our estimations are usually very close to final cost if you don't change the requirements much.
- We believe in a fully transparent development process, our clients are always have all necessary information and control to manage the project. Over the years we distilled a process that is both transparent and effective.
- Our experience in how things work on internet combined with your understanding of business domain ensures the best possible results.
Starting Things Up
3 hours of free consulting, no payments, no obligations.
It is important from your perspective to fully trust us before you put your eggs in our basket. We also prefer to know our clients better before we commit to a relationship. We decided to provide up to 3 hours per project of free consulting, no payments, no obligations. This is the time that we will get to know each other better, you could see how we approach problems and see us in action before you have to reach for your wallet. And even if it doesn't work out, you might take away an idea or two out of this. We also try to accomodate ourselves to your working style, we can meet offline on a cup of coffee or online to start things up.
Estimation
Maximum flexibility and still in control of your budget and deadlines.
We understand that it is difficult to get engaged in a project without knowing price and time boundaries. On the other hand every project requirements we have seen changed a lot during the developmet process. To allow for maximum flexibility and still stay in control of your budget and deadlines we provide you with a rough estimation of development time and budget. Our methodology ensures that you always see how changes in project requirements affect the estimation and you always can adjust as we go.
As an interesting observation, we noticed that first stage of most projects takes about 2-3 months. If it takes much less, there is probably a place for more features. If it takes much more, it can be a sign of feature bloat. It could be wise to reduce the features to speed up time to market and get user feedbacks before implementing all 800 of those "must have" features.
Flexibility
You can feel free to adjust our speed to your needs.
Our methodology allows us to be very flexible and make the development process fully customized to your budget, time constraints and project requirements. We can develop full speed for a week or a year and then completely suspend the development until you come up with necessary market research or next round of funding or next batch of features. The project will be in production ready, deployable state after each iteration, so you can feel free to adjust our speed to your needs. We will also provide necessary training to your development team when you think you are ready to take the project in-house. We will never leave you hanging.
Security
Security is different. You can't compensate the lack of knowledge with an extra effort. If security is important to you then you'd better have a security expert on-board. We do.
Development Approach
UI Design
UI design is what your users will see, they won't see the project specs.
While not a requirement, it is strongly advised that all visual designs will be ready before starting the actual development. The great advantage of seeing the user interfaces is in putting us on the same page regarding all the project requirements. It is very easy to read differently a couple of sentences describing a feature, it is much harder to misunderstand the actual forms and buttons you see in front of you. Keep in mind that the UI design is what your users will see, they won't see the project specs. So thinking about the UI first will ensure that the project features are user oriented and well thought out from the user perspective.
Stories and Iterations
Break down the features list into user visible chunks of work.
When we're all ready to take off, we will work with you to break down the features list into small, digestible,
user visible chunks of work. Some people call them stories. These stories are minimal units of our process.
Each story describes a complete feature from users point of view, like
Stories are combined into iterations. Each iteration takes 2 weeks. After each iteration the project is in a stable, tested state and ready for production deployment.
We use PivotalTracker (done by great guys at PivotalLabs) for project management. It allows you to track project progress and pioritize stories and change iterations according to your needs at hand.
Testing and QA
We write automatic functional, regression and acceptance tests.
Each story is automatically tested before we commit it to source repository. While not a replacement for a human QA, automatic testing allows us, developers, delivering better code and eliminate as much bugs as possible on early stages of a code lifetime. Based on specific project needs we write functional, regression and acceptance tests, using best tools that we aware of.
We still urge our clients to perform acceptance testing themseves, it is a great way to see the project progress. As a by-product, new ideas will be abundant when you see the feature in realistic setting.
Frequent Deployments
Always in control of the project state.
Every time the story is complete and marked as "Delivered" in the tracker it is deployed to our development server. This means that you can go there and test-play with it. If the story indeed what you intended it to be, you can mark it as "Accepted" in the tracker. Otherwise you can mark is as "Rejected" and we will continue polishing it.
Frequent deployments ensure that you are always in control of the project state and delivered features are exactly what you had in mind.
Scalability
If you don't have scaling problems you are not growing fast enough.
The only time when you really need to have a scalable solution from the start is when you develop a new feature to an already established user base with known performance requirements (like Facebook did when they added the chat feature to all the users). Most other times writing it to handle "millions of users™" may not be a way to go and will definitely slow down the development process, increase time to market and budget.
Another problem is that most of the time you have no idea where the actuall bottlenecks will be until you hit the site with the real traffic, so scaling the site before it goes live usually leads to premature optimization and wasted resources, and at the end you still have unexpected performance problems.
Our strategy is that instead of implementing the million users architecture from the beginning, we have a scalability plan. We identify the places where we might have the next problem and plan how we will fix it when/if it arrives. We revisit the plan on each scaling step and avoid detailed planning too much ahead as those far-in-the-future plans usually worthless when the time comes.
Your Role in the Process
Nobody knows the project better than you.
Based on the above, your role is to participate in writing and proritizing of the stories, cause nobody knows the project, your business domain and current needs better than you do.
On the other side of development, you're in charge of acceptance testing to polish every feature to perfection.
Want to get those 3 hours of free consulting? Talk to us, we are friendly :-)
loading recent blog posts, hold on...