How we built it

The beginning

We were very excited when we first learned about the RFQ. The RFQ aligned very well with our area of expertise and competencies. We've been following the 18F work and blog and have worked with our own customers in introducing ideas from the team. Having just received the GSA schedule, this would be the first task we would bid on. The idea of submitting a working prototype as opposed to pages of proposal text made it all the more enticing.

Reality check

We went thru the entire RFQ (thanks to the 18F team for posting it on their blog, for some reason the RFQ did not show up on our ebuy advantage portal) and the requirements for submitting the proposal. Everythng we read encouraged us to go ahead with the submission until we saw the due date. As a small company all of us are actively working on existing projects and the short delivery cycle meant that it would be very challenging to deliver the proposal while continuing our day job. But we we still went ahead with the work, I guess that is the difference between a small company and a large one. As a small company we were willing to put all our energy and effort in responding to the proposal against all odds. It certainly didn't seem we would make the deadline when we started, but we went ahead with the proposal to stress test our own methodology and use it as an opportunity make it more efficient.

Huddle

The next challenge was to pick the idea for the prototype. The team brainstormed on possible ideas and approaches for the prototype documented here. While the idea of ingesting the data from the API service and listing it sounded attractive as it would have allowed the development team to focus on work items related to meeting the objective and criteria for porposal evaluation due to the limited amount of time available for the prototype. A competing idea came up that would align with the spirit of the RFQ as well as be motivating and challenging enough for the team to work on. Magic happens when the team is convinved of the objective and identifies with the cause. The development team eventually decided to create an innovative application of the data available from the API service. We lost a day (whatever hours we had outside of our day jobs) in deciding on the idea, but in the end it was worth it. The team will work on releasing the final product for the public after the evaluation period is over.

The Idea

The idea for the prototype is very simple. Provide a means for the public to keep a list of medications they take in a way that is easy for them to share with their physicans. In case of emerginces, the medication list reference can be scanned or looked up by the care giver to make medical decisions. The next phase of the product would provide notifications on recalls and would allow users to keep a log of the side effect or benefits that could be shared with the manufacturer.

It's game time

We started working on the prototype and in parallel worked on the CI and deployment requirements for the application. We tried out couple of frameworks and deployment options that would make the entire solution work according to the requirements of the RFQ. We use jira, confluence and github for all our agile projects and started with the same tools but had to switch to github issues and github pages after reading thru the final modification of the RFQ. We also utilized the 18f-guides-template for building this documentation. About July 2nd 2015, we had our entire end to end solution working with the integration and deployment workflow. Putting the documentation together seemed to take as much time as building the prototype. Throughout the project we've had to make difficult decisions in terms of choosing options that are best and right for the project (somthing we would want if someone else was building it for us) vs merely fulfilling the rfq requirements. We are very happy with the choices we made more so because we stayed true to the reasons on why we started our company. And we would like to keep it that way.

Parting words

It's been a fun 2 weeks working on the prototype and we enjoyed every bit of it. We wish there were more of these. We've put all this information with the intention that it will help future RFQ that use this approach for getting proposals. Some of the areas of improvement we would suggest are 1. Provide more time for the deliverable - I guess the inital RFQ assumed that resources will be dedicated full time in responding to the RFQ which is a little challenging for small businesses 2. Provide more specifics - Many production systems started as a proof of concept or prototype and were switched to production when management liked what they saw. It is not clear on how good the prototype needs to be.

Above all Keep calm and keep shipping!!