"What's that thing called where you take picture with your phone and then convert it to data? That would be cool, huh?".

Around 4 weeks ago, that was the brief conversation I had with one of my long term clients, Sergio Mottola from Ideando. It was in reference to what became a very exciting, very intensive project build that involved a number of new technologies, techniques and things I'd not done before - mixed in with some things that we are already very well versed in.

A Brief Recap:

2 years ago, my team was hired to build a fully custom web-based ePOS till system for a flagship restaurant in Soho, London. For a more information about this particular project, see this link. Owning and running an operational store was my clients way of realising his vision for improving the quality and cost of food, whilst setting a new standard in nutritional information transparency.

The software we built was the result of being able to deliver on Foodsecret's requirements for a full integrated till system that would be able to act as the interactive touchpoint for staff and customers, operational administrative system for stock management, reporting, staff incentives and a marketing / promotional engine, with integral loyalty schemes and discounts built in. To complete the cycle, this was also integrated with an optional public e-commerce platform - for the store to sell direct to customers outside of their four walls. 

As it turned out, they came to realise that it didn't take making and selling food, running a kitchen, paying rent on an expensive prime-location retail outlet to realise the vision, but instead to take the smarts of their nutritional algorithm out to the wider industry.

The ePOS system was rebranded as NutryPOS, and is set to be made available to restaurants and fast food premises that want a fully baked, web-based till, administration and e-commerce platform with the ability to deliver transparency of nutritional information to their customers  - an increasingly conscientious consumer who cares about what is going into their bodies and a society that is increasingly demanding to have clear, honest transparency into the supply chain at the point of sale.

Nutribu is Born

NUTRIBU api.png

So, it was time for a strategic review, the result of which was to understand the key value proposition that made most sense for realising Sergio's vision.

The key was to make sense of the complex, difficult to understand and not very fun world of nutritional data and make it readily & easily available to the industry, through application developers, own-built products and partnerships in order to create a common language around nutrition that is social, competitive and fun.

Nutribu is an API that makes complex and fragmented nutritional information available to developers, in order to build useful and intriguing applications with nutrition at their core.

Just like we did with NutryPOS.

nutribu-active-docs.png

So building on that work, we broke out the nutritional components, raw database, patented algorithm and logic into a standalone, centralised database with an interface for application developers to register, gain access to various methods to use the data, handle developer access, commercial options, analytics and performance metrics.

3rd Party API Proxy or Build Your Own

One early decision we had to make, was whether to reduce the amount of investment in API software development required to have an operational platform, by paying for service such as those offered by popular 3rd party API proxy providers like Mashery or Apigee.

Given the tight project parameters (budget and timeline - more on that in a minute), but with an eye on the future, we were looking for a solution that would offer a good mix of low barrier to entry, in particular, by way of small or no startup costs. Mashery doesn't make pricing public, but after a couple of calls to Boston and San Francisco, it was clear that although their service is probably the most slick and with some top clients on their roster, it wasn't going to be an easy or quick process to negotiate a suitably low starting agreement.

Apigee, however, was free to get started and that was attractive, coupled with the fact they are a top provider once again, with some high profile clients. I'd met and heard Apigee Vice President Strategy, Sam Ramji talk at the Power of One conference back in 2011 and was interested in their service. But one issue that stuck in my mind, was that whilst their pricing tariff is simple - base level FREE, paid upgrade $9000 per month. That's quite a hefty jump and I wash't convinced that was right for us.

After a fairly in-depth research and review, I was struck by a number of posts on Quora by staff at another API provider, 3Scale, based in Barcelona. Their answers were particularly interesting, in that they came across as genuinely helpful, impartial and seemed to offer the type of solution we were looking for:

  • Free to get started
  • Provision of services we needed, such as developer token management, analytics etc. but;
  • Allowed us to keep control and ownership of the proxy and traffic to the API - reducing overhead and latency (I suppose) for the service.
  • More granular pricing tariffs gave me a clear roadmap of costs versus traction of the API over time.

So, we set about building the API. And quickly. Clock ticking 'n-all.

As I mentioned, timing was critical as we decided that the new brand and product would be great to promote and relaunch at the Launch Festival in San Francisco - just 3 weeks later!

But alas, an API is not really very interesting from a demonstration perspective in it's own right. Sure, there's some nice tech in the background, but no-one knows about or understands that (well, outside of the developer community). So what would make a great demo for an event like this? Well, we could present NutryPOS of course, a fantastic example of how Nutribu can be used to add value to a market and product that needs to put transparency at his heart.

But still, we weren't convinced that this would make the best demo. It is after all, a multi-faceted product with lots of components and sub-components specific to the operational requirements of running a restaurant. Not a consumer oriented technology event. We needed something else, we needed something tight, clean, intriguing and an innovative use of Nutribu API.

Feedo

So, as if 3 weeks wasn't tight enough to build an API from scratch (with everything that comes with doing that), we deciding to build a native iOS application, called Feedo.

Feedo is a an app for capturing a recipe with your mobile device, analysing the ingredients list and returning a personalised nutritional calculation to the user.

This introduced some very interesting challenges - we needed an OCR (Optical Character Recognition) engine (along with some ways reduce the inherent errors that exist within these technologies). We needed an interface for isolating and selecting the ingredients from the image and we needed a working API to process and validate the ingredients, generate products and return our Nutribu score.

I'll follow this post up later with more on how we did that, and some of the more specific product and technical challenges we faced - but needless to say, we're very happy with the result.

So, as I write this, I'm sat on the plane following a pretty amazing team performance to design and build the new database infrastructure, identify and produce the necessary API methods, API portal, branding, product website, event launch materials. Well done team.

As well as my technical team doing a blinding job, a big mention to our designer, Alfredo Violante, who worked on the Nutribu and Feedo brands, the website and iOS designs in a very very short space of time. I think you'll agree it looks fab. You should take a look at his work, he's the don. Thanks Alfredo.