They say you can only have two out of three: cheap, fast and good.
We focus on getting the"fast"
and "good" parts.
Strangely enough, it will often turn out less expensive than others
as well, but that part is not our main focus.
We spend a great deal of time each day learning new technologies and "sharpening our edge". We call ourselves "high end" and we work hard to really stand by it. It's what lets us build your application in a way that will leave your future users and competitors in awe.
We don't like unpleasant surprises. You probably don't, either. We do like pleasant surprises, though. We prefer to be realistic, or even pessimistic, in our estimates, both on time and money. There are no hidden costs. Our estimates are usually very close to final cost if you don't change the requirements too much.
We believe in a fully transparent development process; our clients always have all the necessary information to manage and control the project. Over the years, we distilled a process that is both transparent and effective.
3 hours of free consultation; no payments, no obligations
It is important for you to fully trust us before putting your "baby" in our hands. We also prefer to know our clients better before committing to a business relationship.
That's why we decided to provide up to 3 hours per project of free consultation; no payments, no obligations. This is the time for us to get to know each other better; you can 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 may still come away with an idea or two. We also try to accommodate ourselves to your working style; we can meet offline over a cup of coffee or confer online to get things started.
Our experience in how things work on the Internet, combined with your understanding of your business domain, ensures the best possible results. The process is following:
1-pager defines a problem, a solution and a product that reflects the solution, it says what your product does and how value will be delivered to your users.
Learn more.What we learn: An understanding of your market, your users, what value your product aims to offer and the simplest way to deliver it.
How we keep it lean: Simplification is the holy grail here. We call it a 1-pager but it should be less than a page, ideally a paragraph.
What do we do with the 1-pager?
We create a short list of features needed to launch your product. We also identify your content flow which is the critical path defining your most value-driven usage cycle. This process determines what critical data needs to be generated by users, and what your software needs to do with it.
Learn more.What we learn: A clear distinction between need-to-haves and the nice-to-haves. What is our virtual“work perimeter” where we operate, and where ideas outside the scope are saved for future consideration.
How we keep it lean: The project scope is limited to a few pages and is used as a “line-in-the-sand” to keep work focused on launch goals.
Now what?
We evaluate how much time, what work and which resources are required to launch your product.
Maximum flexibility, while maintaining control of your budget and deadlines.
Learn more.We understand that it's difficult to engage in a project without clear price and time limits. On the other hand, in our experience, project requirements always change a great deal during the development process. In order to afford maximum flexibility, while allowing you to maintain full control of your budget and deadlines, we provide you with a rough estimate of development time and budget at the outset. Our methodology ensures that you always see how changes in project requirements affect our estimate, and you can always adjust your requirements as we go.
As an interesting observation, we've noticed that the first stage of most projects takes about 2-3 months. If it takes much less, there is probably room for more features. If it takes much more, it can be a sign of feature bloat. It may be a good idea to reduce the amount of features in order to speed up your time to market and get more user feedback before implementing all 800 of those "must have" features.
What we learn: The budget and timeframes required for your initial product launch.
How we keep it lean: We anchor our estimates to what you need, and avoid blowing out your budget on features that won’t bring immediate value.
Work is estimated, now we
Surprisingly, 80% of features planned for launch don’t directly feed into a product’s initial survival. With this in mind, we separate the critical 20% features you need from the rest that you don’t (for launch, anyway).
Learn more.What we learn: The core offering and functionality of your product, and the features that can wait until after launch.
How we keep it lean: Every feature must prove its “survival value” or it’s out (for now).
Now it’s time for
We use the mighty pencil and hand-draw wireframes showing the screens we need and the types of data to be generated and used.
Learn more.What we learn: The blueprint for your entire product. Technical wireframes are used by both design and development teams to communicate expectations for the work that follows.
How we keep it lean: We make rough, hand-drawn sketches that get the job done well and fast. We use the wireframes to simulate usage, detect problems and make corrections before design or code stages even start.
We usecontent creation flow™ approach to determinate how the data is created at the first place and then how it's consumed.
The technical wireframes are used to guide
Based on your technical wireframes, 5-7 key pages are designed to show 90% of the required features and elements.
Learn more.What we learn: What your product will look and feel like. You’ll have a visual prototype to show customers/investors/friends so that you can start getting feedback on what works and what needs more work.
How we keep it lean: Usage information can start flowing in offering insights before development starts.
The great advantage of seeing the user interface is that it puts us on the same page regarding all the project requirements. It's very easy to misunderstand 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. Thinking about the UI first ensures that all project features are user-oriented and well thought out from the user's perspective.
We’re now ready to
Describing user stories is the last step before development. It is breaking down the feature list into user-visible chunks of work.
Learn more.We take the technical wireframes, the design and the user stories and get to work building your product.
Learn more.When development is done, we check our code a number of ways including getting at least another pair of eyes to review, continuous integration and deployment and static code analysis.
As quick as possible and when it’s good and ready, your code is delivered to a staging server and every button, icon and feature are clicked and tested to make sure everything is performing as intended.
What we learn: How your product actually works, and how your users will potentially use it.
How we keep it lean: We use all our previous lean steps to keep development focused on the minimum required to go live. We also tidy up the code so that future work can stay lean.
Get out there and
Now that you’ve launched, focus shifts to reaching success.
To help you achieve this, we repeat the lean steps only this time we use real usage data as the foundation for design and development goals and decisions.
With your product live now, you can start getting feedback from users, understand what resonates and dive deep or pivot in relation to your market and product goals.
Feel free to adjust our speed to meet 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 at full speed for a week or a year and then completely suspend development until you come up with the necessary market research, or the next round of funding, or the next batch of features. The project will be production-ready and potentially deployable after each iteration, so you can feel free to adjust our speed to meet your needs. We will also provide your development team with any necessary training when you are ready to take the project in-house. We will never leave you hanging.
Security is different. You can't compensate for a lack of knowledge with extra effort. If security is important to you, you'd better have a security expert on-board. We do.
Automated functional, regression and acceptance testing
Each story is automatically tested before it is committed to the source repository. While not a replacement for human QA, automated testing allows us, the developers, to deliver better code and eliminate as many bugs as possible at an early stage of the code's lifetime. Based on specific project needs, we write functional, regression and acceptance tests, using the best tools we know of.
We still urge our clients to perform acceptance testing themselves; it's a great way to really see the project's progress. As an added bonus, seeing the feature in a realistic setting may inspire some great new ideas
Constant control of progress
Each time a story is completed and marked as "Delivered" in the tracker, it is deployed to our development server. This means that you can go there and play with it. If the story works as you intended it to, you can mark it as "Accepted" in the tracker. If not, you can mark is as "Rejected" and we will continue to fine-tune it.
Frequent deployments ensure that you are always in control of the project's progress, and that the delivered features are exactly what you had in mind.
If you don't have scaling problems you are not growing fast enough
The only time you really need to have a scalable solution from the start is when you develop a new feature for an established user base with known performance requirements, like Facebook did when they added a chat feature for all users. Most other times, writing a feature to handle "millions of users™" may not be a way to go and will definitely slow down the development process, increasing both your time to market and budget.
Another issue is that most of the time you have no idea where the actual bottlenecks will be until you hit the site with real traffic, so scaling the site before it goes live usually leads to premature optimization and wasted resources – and in the end you may still experience unexpected performance problems.
Instead of implementing the "million users" architecture from the beginning, our strategy is to create a scalability plan. We identify the places where we might have the next problem and plan how we will fix it, if and when it arrives. We revisit the plan at each scaling step, and avoid detailed planning too far in advance, as those distant-future plans are usually worthless when the time comes to implement them.
Nobody knows the project better than you
Based on the above, your role is to participate in writing and prioritizing your stories, because nobody knows your project, business domain and current needs better than you do.
At the other end of development, you're in charge of acceptance testing and making sure every feature is polished to perfection.
Want to get those 3 hours of free consulting? Talk to us, we are friendly :-)