How can we help?
More Information
Your Question, Answered.
How many years have you been in business?
The Stanyan Group, the first part of the East Agile global enterprise, was founded in San Francisco, in 1997. Since then, other parts of the enterprise were set up in India (1999), Hong Kong (2009), and Vietnam (2007).
What currency do you invoice in?
We typically invoice in US dollars, but we can invoice in another major currency if that is important to a client. Invoices are issued by East Agile Limited in Hong Kong and paid by wire transfer.
Will you be able to provide a fixed cost for the work?
Yes. However, we strongly discourage such engagements since it limits our agile development methodology's ability to respond to changing priorities, ideas, and emphasis during the development process.
What type of work do you typically do?
We implement new online ventures for entrepreneurs (startups) or more established ventures (e.g. Twitter). We also build advanced analytics infrastructure and provide advanced business analytics (e.g. machine learning) to customers from finance (Morgan Stanley) to mobile games (ngmoco, mig33).
How big are your typical projects in terms of time and money spent on them?
Most online applications take between six weeks and six months to implement. This is usually a client choice since we can usually adjust team strength, such as from two developers to six developers. Costs range from USD 30,000 to well over a million dollars. Some clients engage our developers on an ongoing basis in large teams.
Will all the development take place in-house or would you outsource as well?
We do all development in-house.
Development process
Please provide details of your process and the way you like to run projects. Do you use an Agile or iterative system - will we see regular releases throughout development?. Do you like to communicate via email, phone, IM? Do you have an issue tracker that you use with clients? Do you have weekly status meetings with clients? Do you send status reports every few days? Do you provide one point of contact? How do you handle change requests?

Whenever we have the option, we develop using eXtreme Programming methodologies. Pivotal Tracker ( manages our tasks, progress, client interaction, and bugs, chores, and issues.

We ask clients to provide at least 4 hours per week of time from a business or product manager who understands the product, how it should work from a user perspective, and most importantly is able to make business decisions about priorities. We work with that person on a daily or at least once weekly basis.

We typically do not use one point of contact, although one developer could be designated as such. Typically, all developers, or at least each pair, interact with the client product manager on a regular basis, primarily through Pivotal Tracker.

Our eXtreme Programming methodology involves Test Driven Development (TDD), paired programming (See Wikipedia, other discussions on this site), and weekly emergent iterations implementing prioritized features. We work with a (client) product or business manager to break up a product into relatively small user stories and features which we estimate time to deliver on (trivial to a full day of work). The client then chooses priorities by dragging and dropping these into our work queue in our Pivotal Tracker project management software, which we implement on a strict priority basis. As work is done, the client sees "accept/reject" reject buttons on features, driving their role of deciding if the feature has met business objectives. Other tasks are also managed through this process, including chores and bugs. As work is done, a velocity is calculated using actual relationships between estimation and actual completion time, and all future work is automatically forecasted out using these current actual measurements. We attempt to make a release-ready version of an application every week or two. 

Development proceeds such that a release is a business decision and not an engineering one. Typically, clients see live functionality created on a daily basis.

Similarly, completion of a project is a business decision not an engineering one. Because we implement features from most important to least important, all the highest value and business critical features are done first. Over time each iteration should add less value than previous ones (except when innovation takes place during development, which does happen frequently). At some point, there might be nothing left to do, or we may be done from a business perspective when all the features that add strong business value have been done, and only marginal ideas or features remain in the "icebox" of tasks.

Changes requests are trivial in our agile methodology (on a time-and-materials contract). A client just drags an unstarted feature in Pivotal Tracker from one location to another to change when it is done. Or a new one can be thrown into the icebox, our engineers asked to estimate it, and then the client can drag it to any point in the future to have it executed. All time estimates and release schedules are recalculated in real time using actual performance measurements.  

In a fixed-bid contract the change request process could work much the same way: a client could add anything they wanted to the "icebox" of ideas, ask us to estimate it (minor, half day, full day). However, some sort of written agreement or notification would be needed before dragging a new feature into the project. And similarly, some sort of  written agreement or notification would be needed before removing a feature (and getting credit for that). The agreement/notification process would need to be defined in a contract.

We do send daily progress reports, but much of our discussions and information get exchanged within Pivotal Tracker. We augment this with conference calls, email, and IM and screen sharing. Progress monitoring also takes place using automatically generated graphs: release burn down, current iteration burn-up, velocity, story-breakdown (feature/bug/chore).

Testing & QA
How do you test your applications? What QA processes do you have? How do you handle issues discovered during user acceptance testing? Are these fixed promptly at no additional cost?

Testing drives our development process. We follow rigorous Test Driven Development (TDD) methodologies. Before we write code for any feature, developers first implement tests, then they write code to make their tests pass. Both tests and code are constantly refactored during development. Typically for each 1000 lines of code there will be a 1000 lines of associated tests. A wide range of tests are created during development, including tests of user interface functionality using Selenium. Tests are run continuously throughout the day as part of the development process. Writing the tests first helps us better understand how to write strong code. All testing is done by the developers who test the code. 

User (client) acceptance testing is a continuous part of our development process.  After each feature in a project has been implemented, it is submitted through Pivotal Tracker to the business/product manager at our client. The client reviews the live, working feature and determines if it meets the original business requirements and either accepts or rejects the feature. If it is rejected, feedback is provided and the feature is returned to the development queue to be restarted. This feedback loop is a natural part of the development communication process and not a sign of gross incompetence that should not be billed. Both parties work to confirm agreement and ensure what was "meant" is implemented, even when that is not what was "said" or "understood". This process is fully billable.

Please check out this article for more information.

Intellectual property
Please describe your policy on intellectual property (IP) in relation to your customers' creative ideas. How do you protect their IP? Are you happy to sign a non-disclosure agreement? We will need the contract to be "work for hire" where we retain full intellectual property and copyright in all work done on the project.

We do work under NDA. We protect IP through NDAs with all employees and would aggressively support prosecution of any employees violating client IP protected under an NDA with East Agile.   We understand IP, including many of the subtle complexities. 

We have internally developed code and libraries that we can grant clients a non-exclusive, transferable right to use.  Or we can re-invent those wheels using developers with no knowledge of our pre-existing solutions.  

We do grant exclusive rights to original code we develop for clients. However, we do retain the rights to general knowledge and general know-how. For example, if we originally implement Twitter oauth for one client, we retain the right to implement it for other clients, from scratch, even though the final implementation may be very similar. However, unique inventions, solutions or methods remain the exclusive property of clients. When other clients face similar problems, we develop novel, and hopefully better solutions for them, or we ask the client technical staff to propose a solution, or we bring in a developer without proprietary knowledge of the solution.

With permission from clients, we can also work with open source code, identified as such, and located in external libraries for segregation from non-open source code.

Why Agile works for your project?

Please check out this article.