References

Please provide 2-5 customer references who we can contact.

We would be happy to provide references to clients similar to your own organization in terms of size, funding, and/or technical experience to ensure that their experiences are relevant to you. We will need to know more about your company and funding before we can make that determination.  Should we send you to a Harvard University computer scientist? Should we send you to a non-technical entrepreneur funding out of his own pocket? Should we send you to an executive at Twitter? We are also very careful with our clients' time and so only ask them to act as references in the final stages of starting an engagement once all other aspects of the engagement are agreed to be acceptable. 

 Billing

Please describe your billing model. Do you accept part payment at certain stages of the project. Will will be aiming to hold back a significant percentage until full delivery of the project.

We ask clients to pay for 30 work days of development in advance, and invoice at least monthly with payment due by wire within two weeks.  For clients unable to pay 30 days in advance, we can accept 15 days in advance and weekly invoicing with payment due within seven days. Some clients with exceptionally strong credit ratings or funding are exempt from payment in advance (e.g. we did not ask Twitter or Morgan Stanley to pay in advance).

If we follow our normal agile development methodology based on time-and-materials billing, we deliver fully integrated and operational iterations of a client's product each week. Each feature of the product is individually approved by a business or technical representative of the client as it is developed (and adjusted accordingly if it is not accepted).

We guarantee our time-and-materials agile development work.  If a client is not satisfied for any reason with our work, or what we have delivered within the first 45 days of an engagment, they can simply end the engagement and not be liable for their payment on their first invoice. Their deposit will be refunded by wire. No one has ever taken us up on that offer, but we wouldn't dream of charging someone who wasn't satisfied.

 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, transferrable 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.

 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.

 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 (http://Pivotaltracker.com) 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 managment 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 need just drag 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 estimated 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 realtime 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 sent 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 take place using automatically generated graphs: release burn down, current iteration burn-up, velocity, story-breakdown (feature/bug/chore).

 Your work and experience

Do you have any live URLs of work you are proud of? Have you completed projects that have similar features and functionality to http://basecamphq.com/? We are especially interested in any "Web 2.0" applications with multi-user accounts and payment systems.

• We have implemented a few payment systems using Paypal and Google checkout, however, none are currently visible to the public as they have restricted access.
• Our http://eastagile.com main site actually has a lot of internal 37signals influenced features. We have a simple chat room, project with the ability to add files, and also, beyond 37signals, a CMS that allows blogging, review and publishing, and most parts of the site to be edited live without development assistance. We can provide you with a private demo of this, and a code review.
• http://knowmyfood.com, 
• http://www.thentic.com/, 
• http://sensr.net, 
• http://apps.facebook.com/mybrain/ is a Facebook game application built for Lumos Labs of San Francisco.
• Twitter.com is a live example of a site we are very proud of, however, the algorithm and interface work we did at Twitter are not visible to the public.
• In the last few weeks we released http://140h.me, a collaboration space for Twitter discussions around hashtags.

 Phone apps

Do you have any experience of developing iPhone apps? 

We have a mobile platform development team. We develop for iPhone, Android, Blackberry, Symbian, and Palm WebOS. Our iPhone team has particular strength in geo-location and mapping applications. We have also been selected by Palm, Inc. as a recommended phone application developer. 

 Security

What security measures would you take to protect an application of this nature? Eg from external sources - unauthorised access, hacks, DOS attacks etc. In addition, do you have experience of ensuring that registered users do not have access to other user accounts/data from within the same application? Are you aware of these risks? How would you prevent them?

We usually use RESFUL authentication framework when authentication system is required. There are several such frameworks in Rails, open-source and carefully tested. In some particular situation, OAuth can also be used to avoid or mitigate risk. For DOS attack, currently we mainly depend on the host service provider.

 Deployments

Please describe how you would deploy an application of this nature including reference to any development, staging and production servers. What systems would you put in place to roll out upgrades after the application goes live? Also, how would you create a 'down for maintenance' page if we needed to do some emergency work to alter the application without loss of user data?

- For deployment, we prefer the use of Capistrano since it supports remote deployment, rolling back and release version control. In addition, Capistrano also supports the configuration of “down for maintenance”  page.
- Normally, we use git style management features to handle different environments. Usually, we have 2 branches: production with stable code and development with newly-implemented code. Two branches will be merged after the new code is approved.

- In some cases we have a local test environment (our iMac dev machines and local servers), a cloud-based development server, a cloud-based staging server for final configuration and testing before deployment, and a scalable cloud-based production environment.

We have best practices, but adjust to meet client demands that can vary depending on their existing systems, preferences, and budget.

 Technology platforms

If you were asked to build an application like http://basecamphq.com/, what technology platform would you use? Eg PHP, Ruby on Rails, .Net, MySQL, SQL Server, Apache, IIS etc. We know this depends on a lot of things but please just give us your first impressions.
What payment system choices would you initially recommend?
Please explain your choices above. We would like to get an idea of your preferred technologies and your expertise with them.

If we were implementing a system such as the one described we would use Ruby on Rails on Engine Yard managed Amazon EC2 infrastructure (Linux, MySQL).  Rails is a natural, proven, scalable choice for this sort of application that would enable rapid test driven development with strong security, strong standards, and manageable code. We have many thousands of hours of experience with Rails.

We are an Engine Yard Select Partner, have implemented on their platform, and know and trust their staff, and most importantly their technology stack is appropriate for a startup that wants to manage cost yet still have unlimited ability to scale. A lot of the standard technology stack elements, as well as backup and some key deployment elements are taken care of by Engine Yard so we can focus on the application. Cloud infrastructure makes a lot of sense since each individual client account is likely to be small, interaction between accounts will be minimal or non-existent, and the financial cost of infrastructure will be more-or-less linear and in line with revenue. Amazon EC2 allows on-demand deployment throughout the US, and in Ireland to serve the EU.

At a slightly lower cost point, while still maintaining strong scalability and reliability, Joyent provides scalable hosting on an Open Solaris platform on which we have a lot of experience. However, they do not have a UK data centre.