Viewing entries in

4 weeks of Forge, Hammer and Anvil

It's been 4 weeks since I officially took over Hammer, Forge and Anvil, so I thought I'd write up some notes on the experience, things I've learned and encountered along the way.

The beauty of this acquisition was that there were already a fairly healthy bunch of users already using the platform, and some of them were also paying for the service. Before I set about writing a single line of code, I wanted to learn as much as possible as I could about how people were using the products, so I did a few things:

Communicating With Customers

By setting up Hootsuite to manage the Social Accounts

Each of the products has its own twitter account - @getforge @hammerformac @anvilformac. Along with my own personal twitter account and the new Twitter account I created for Beach (since Beach replaced my old service company Double Digital), this is setting up to be a Social Media Management pain in butt.

We don't employ anyone to manage our own social media full time, so it means we typically do our own social media pretty poorly. With Forge, there's a number of ways to communicate with our customers, but with Hammer and Anvil, it's much more difficult as we don't know who they are.

So, Twitter is a very important channel, until I can establish Forge as the main platform for all of our customers to use with whichever Beach product they are using.

Using Hootsuite at least gives me a fighting chance to keep on top of @replies and mentions, support requests and product feedback.

It was particularly useful when Forge went down a few times, to relay important platform status information and therefore limit the customer support requests that would inevitably come in.


Getting to Know Our Customers

By installing Intercom into Forge

One of my favourite products, one I've used on all of my products since way back in 2012, is Intercom. The first thing I did on Forge was install it and start talking to customers directly. I made sure I was on hand to respond quickly and thoroughly to all users of the service, to really understand what they thought of Forge and what their concerns were. 


The main support requests I received related to Deployments getting stuck. Sometimes this happens and users would just see the endless spinner syndrome - not a great experience. Most of the time, it's due to something fairly innocuous in the uploaded archive, but also the deployment just fails sometimes and can easily be fixed with an intervention on the technical support side.

Forge is actually doing quite a bit of work behind the scenes whilst the site is deploying, and it's great that this is invisible to users most of the time, but when things do go wrong, it's also really important to provide enough information to be useful in understanding what's gone wrong and how it can be fixed. Watch out for some improvements coming in that area soon, including some slightly more elegant logging and console tools.



Understanding Our Value

By creating a survey on Typeform

I issued a very simple customer survey via one of my favourite products of the moment, Typeform. This gave me a very impactful way to understand the challenge ahead of me. I wasn't really sure how existing customers felt about our products right now and I felt I needed some insight to better approach the future.

The feedback from customers was very consistent. There was a genuine love of the products, the design and simplicity of how the products went about their business. It's shown me just how important it will be to keep this guiding principal as I start to evolve the products.

There was, understandably, an overall tone of frustration. People were on the cusp of giving up all hope that these products would still be alive in the days or weeks to come. So, I was met with some scepticism, but genuine optimism at someone new stepping up and taking these products over. People really loved Hammer, and I think, would really like to love it again. 


Championing Our Customers

By creating a customer showcase

There are some super smart, incredibly creative people people using our products to do amazing things and that makes me so proud. I'm a big fan of championing customers, making them the stars of the show.

My first step was to reach out to those I'd identified and invite those who felt they related to the idea, to showcase their profiles on the Forge website. It was fascinating to understand how they use and love our products in their daily workflow, some relying on all three - Hammer, Forge and Anvil, whereas others really only relying on just one product. That's fine, but it's crucial in my eyes that everyone is celebrated for the great work they do and to inspire others.

The first 4 went up last week and I'm build out applications from many more customers, all of whom I'm incredibly envious of their talents.

I'll be publishing more in depth interviews and profiles on each of them very soon on the Forge blog, which will be the main resource for updates and news about each of our products.


Working on the Roadmaps

By creating public roadmaps on Trello

I've always been a fan of bringing ideas out into the open and sharing in how those ideas evolve and get implemented into products. So, it was a no-brainer for me to firstly establish the principal of public roadmaps for these products. Trello is my go to choice, since I already use it daily for managing internal product development tasks.

The feedback I received from the Customer Survey and from directly talking to people through Intercom, all goes into these boards, starting with the one for Forge.


Users and Customers are free to add ideas, comment and vote on others which helps me to understand demand and prioritise our workflow. It always takes a bit of time for people to get into the habit of contributing directly here, but is an area I really hope will build out organically as we gather momentum.

In August I'll be releasing the Hammer roadmap for people to contribute and stay informed on the progress.


Learning About Our Business

 Using Stripe, Chart Mogul and App Figures

We use Stripe for processing payments on Forge. For Hammer, we rely on the Mac App Store.

Both of these services are very well served by some supporting services that provide a way of looking at the data to get a better understanding of the nature of your business, instead of purely looking at timeline transactional data, but looking in terms of your key metrics.

Until I figure out what our "2000 Users" killer metric is, I'm really interested in understanding how new customers find our products (funnel), which product they choose to buy (pricing model) and how long they stay for (churn).

Screen Shot 2015-07-20 at 13.24.16.png


I found that Chart Mogul is a great service for making the most of Stripe data, though I also quite like the native Stripe apps. Chart Mogul provides information in relation to churn rates, and when I get deeper into this, I'm sure will provide much more value still.

The App Store data via iTunes Connect is typically crappy, so I'm using AppFigures for tracking the performance of Hammer. Despite the obvious frustration since stagnating the development, people are still downloading the tool and still love it. So, I'm really hopeful that when I get into the next version development, we can re-establish the trust and passion for Hammer that it once showed such promise for.

Through this initial research, I made some quick decisions on evolving our pricing model. I felt that the free version was too generous and creating too much of a comfortable zone for new users to exist in. Instead of the 5GB limit, I reduced it to 1GB. 

The $10 plan, I felt was also not driving enough value to prompt people to take that big step of putting their hands in their pockets to pay for the service, so I doubled the number of sites that can be created from 5 to 10.

I didn't think there was then enough of a significant difference in value from the basic plan to the paid plan, so I took a big step to remove the limit on sites entirely - you can create unlimited sites with custom domain for $50 per month.

A big feature of each of the paid plans is the Customer Support. It was never something that was really part of the feature set, but hopefully I've made a successful attempt to establish my intention to ensure that we really focus on supporting our customers, through all of the tools that we have available.


Tackling the Crooks

Using Intercom and Rack::Attack to block the crims.

All of a sudden, Forge went down. Panic. Was it something I did? I'm still figuring my around the stack, did I botch up the CDN settings? Did I knock out an EC2 instance? Arrghhh.

Turns out, no.

As I was getting to learn about the Forge user base, I discovered that there were around 100 accounts registered on the platform with Nigerian locales. On deeper inspection, it turns out that many of these accounts were using Forge to create suspected phishing sites and Amazon weren't thrilled about it.

Once I figured this out, I went through and removed offending accounts, sites and established some rules for new user signups to prevent this type of thing happening again. 

One way is simply to monitor the new account registration activity, this is time consuming, but a very important exercise to understand how people are using Forge. Intercom is a great tool for this, particularly when I have it setup to fire notifications into a dedicated Slack channel.

The other way is to maintain an active blacklist of IP addresses, using Rack::Attack.

I have a feeling this wont be the last we see of this issue, the virtues of a free account service, but we will monitor and do our best to prevent breaches of our terms of service.


So, that's an overview of some the main aspects of what we've been working on the past few weeks - I wont bore you with the drudgery of actually managing a transition of tech from one party to another.

I'm very excited that we're now starting to pick up the challenges of some of the Forge roadmap, from stabilising and updating the underlying technology, improving performance of existing critical features and starting some new shiny things too.

Why Forge, Hammer and Anvil?

Today is a great day and I am very happy.

I quietly announced that my company,, has acquired three small products: Hammer for Mac, Forge and Anvil, from the guys at Riot.

A few thoughts on Hammer

Back in 2012, Hammer was born with a flurry of excitement. Back from the initial commit by Elliott to the Hammer server-side repo on June 10 2012, up to the announcement pretty much bang on 6 months later that the app was flying

People loved Hammer. It was a breath of fresh air for Mac-touting front end dev's everywhere.

I know this sentiment very well. I wasn't the first user of Hammer - in fact after signing up for the initial BETA, I didn't quite understand what it was for until I really got stuck into the first release.

It was a REVELATION to me

I wrote this guide to Hammer back in September 2013.

Since then, I haven't done anything static that didn't involve Hammer.

  • I prototyped new UI concepts for Currys / PC World
  • I used it to build Brand Swatches and Style Guides for Breast Cancer Campaign
  • I prototyped early static screens and clickable prototypes for Nourish Care
  • I built and ran value proposition experiments and lead generation for Ferticentro
  • I built product websites for Nuwe, HealthHackers, Nutribu, Beach, Double Digital
  • I used it during Hackathons
  • I converted many themeforest themes into Hammer templates just so I could use them without drowning in long HTML files...
  • I converted the Startup Framework into Hammer templates

2 years after Hammer's first release, I'm still an active customer and user of the product. But the world of Developer Tools moves so fast. We've seen the rise of javascript libraries and frameworks, from Backbone to Ember to Angular to React and Mithril. We've all been struggling to keep up, to place our bets on what will stick and what will fall by the wayside. 

In this time, we've seen other tools with similar promise to Hammer rise in popularity as the products have continued to adapt as the development technologies we use have evolved. Codekit, LiveReload, PreProc, CactusCrunch and Koala to name a few. [Editor: See additional notes at the bottom of the article]

I've tried them all in this time, but there's something about Hammer that keeps me coming back.

But, it seemed something was not right with Hammer, the updates stopped coming. New releases were not made. All was quiet. Meanwhile...

A few thoughts on Forge

Having been a Hammer user since early 2013, when I found out about the new service from Riot, called Forge, I was keen to dive in. In October 2013, when Forge opened its doors, I was right there to give it a try.

I had been having a torrid time with basic hosting, using Fasthosts VPS. It had caused me no end of bother, considering I didn't really want to be doing hosting in the first place, but when you're running client projects, it's something you end up just doing to avoid the inevitable hand holding of a client-managed hosting setup.

So, as soon as Forge came out, I moved a number of my simpler static sites straight over. That wasn't before I'd also wrestled with Amazon S3 for static site hosting, and found updating S3 buckets, configuring permissions and Route53 settings to be a pig of a job for something that should be so straightforward.

That's exactly what Forge was. Dead, dead simple. Drag, drop and forget.

I remember getting so pee'd off with the whole thing, I even ran a couple of demo sites straight out of a public Dropbox folder, I mean, jeez - so when Forge released Dropbox (and Github) integration, I was like "...are these guys reading my freakin' mind?"

Forge is like a bit of a secret weapon for me. In a way, I never really wanted to tell people about it, like they would discover my kryptonite or something. I've hosted everything from coming soon pages, to single page web sites all the way up to a rather nice React app with integration on Forge. It's not as "static" as you might think.

I always thought to myself, I'd love to have some products like these, Forge and Hammer are just awesome - amazingly well executed, beautifully designed, simple propositions which really do have an impact on the way developers work.

Since Forge was released, we've seen a number of other static site hosting services, none more significant than Github's own pages service. Then there's Divshot, BitBalloon, Roots, Netlify, Site44, Paperplane and Brace (acquired by Squarespace)

Once again, as I could tell that Forge was not progressing at the velocity that I had hoped, I tried all of these services, but somehow, kept finding my way back to Forge.

A few thoughts on Nuwe and Me

I am CTO and co-founder of a startup, named Nuwe, which we founded in 2014. I have a small tech company, a bit like Riot, called Beach and we specialise in web and mobile app development, mainly focussed on products.

At Nuwe, we are building a developer platform which provides a Platform as a Service for people making new mHealth apps and services. I love ideas with real Social Capital.

We were recently accelerated by Startup Bootcamp, as part of the Barcelona IoT and Data Cohort of 2015.

I come from a rich background of experience in running large and small projects, from PHP-based web apps, e-commerce and CMS builds to more recently, the last few years focussing mainly on Ruby (rails), Node.js and native iOS projects. I'm a developer, product manager, team leader, entrepreneur.

I have 2 small boys, 2 basset hounds and a very understanding wife.

With Nuwe, we've been helping 20 or so companies to build their mHealth apps with significant cost and time savings, during our closed BETA phase. What I've seen in this process up close, is that although the technologies we use to build products vary massively (a huge challenge for us being truly platform agnostic), that the real problem and barrier to growth comes with the understanding and application of the skills required to build and iterate on new ideas from the ground up. Those aren't technical challenges. They are a mindset barrier.

I've seen, first hand, the tendency to assume too much, to believe our own instincts and write feature requirement after feature requirement - often forgetting the real people who you want to buy the product and drowning behind the desk in the belief that what we're building is the right thing, the thing that people want. I've seen it with startups, indie developers and with large multinational corporates.

A big challenge for the creators of new Health services, apps and services in general for that matter, is in obtaining and practising better product development processes and that starts even before we even lay down one line of code on our product.

One of the best parts of the accelerator process for us, was to disconnect from the need to build software and reconnect with our audience. We designed, tested and iterated our value proposition over and again until we found something that resonated - in language, tone, style and structure. 

Doing that somehow free'd us to build later, faster and in a more targeted way. All we needed was a website, a view of the problem and way to communicate the solutions we had in mind.

Through all this, I knew we needed to help educate our customers to maximise the use of our platform and that we'd need to invest in the content and the tools to provide this.

The Convergence of Pathways

It was a chance conversation between myself and Elliott over twitter, since I knew of his move a while back to Dropbox, to ask him what his plans were for Forge, in particular, when we started talking about the future of these products.

Within a few hours we were talking about a deal that would see me take over the on going management of Forge.

And within a couple of weeks, we'd struck a deal for me to take over the ownership of Forge, Hammer and Anvil.

You see, Elliott and I have similar visions for the products they originally created. Elliott still has unfinished business for sure and so I was delighted when both he and Hector agreed to stay close to the products as key advisors and to share in any future success as the original creators.

There's a number of things that need to be addressed quickly, in my mind as a customer of the products and I'm sure you'll agree with those.

There's many routes that these products could take, and I'm sure we'll become more divided on those ideas as we progress, since the landscape is evolving all the time.

One things is for certain, these products don't deserve to end up on the crap pile. They're too damn good, too damn valuable and have too much bloody potential as yet unfulfilled.

My Simple Manifesto

I think that it would be rather premature to tell you what I plan to do, so it might make more sense to outline what I believe in.

Customer Service is Top Priority
One of the things I want Forge to be known for is Amazing Customer Service. It's going to be hard, we're a very small team to start with, but I see the potential for this product and I will do everything I can to make sure the service you receive kicks the cr*p out of the larger, less personal and more sales-driven companies. The service will be personal and the best way to reach us is via the new Intercom tool in your Forge admin area. Look out for this...


Openness, Transparency and Collaboration
I'm going to bring openness and transparency to the roadmap, I want all of our Customers to have a say in the way that Forge takes shape.

Build and Enable Great Products
I believe in Products. And whilst Forge itself is a product, the customers using Forge are also building and promoting their own products. So I think Forge is a tool for creating better products and better businesses and this will guide what we do with Forge.

Simplicity Is Beautiful
I love simplicity. And that's why I love Forge and Hammer, it really was the easiest way to host and build my websites. Even so, some things are still not as simple as they could be and there's lots of things I'd like to add. Remembering this value will be crucial.

Social Capital is Really Important
I like working on things that provide an amount of Social Capital. If you're in Education or you're building products for Health, then I'd especially love to hear from you to see how we can help you further.

I'd love to hear your thoughts on any of the products, ideas you've been mulling over and waiting for over the past couple of years and your own visions of the future.

Follow Forge on Twitter

Follow Hammer on Twitter

Follow Anvil on Twitter



Edit: Thanks to @TheLoneCuber and Bryan Jones (@bdkjones) from Codekit for pointing out the potential for interpreting the article in a way that I hadn't intended.

It seems it could have been read that I was suggesting Hammer was the first tool of its kind in the market - that wasn't the intention. I was merely trying to make the point that since Hammer was released, other apps have continued to evolve and establish a place in the market and Hammer has not evolved at the same pace over recent months.

To clarify, and as both had pointed out, Codekit (thanks to Bryan's exhaustive and often entertaining public release notes) actually went live into Public Beta in November 2011 and according to the project's repo, Hammer's first commit wasn't until summer 2012.




10 Best Practice Tips for User Onboarding to a Mobile Application.

10 Best Practice Tips for User Onboarding to a Mobile Application.

1.The Goal.

The main goal is to accommodate your user and to get them using your product, ASAP. It’s highly important to make a fantastic first impression and to then carefully familiarize your users with the product so that they come back.


2. Communication is key.

You don’t want to talk their ear off but you want to be as charming as possible. Simply: Tell the user what they need to know. In as few words as possible, make them like you, being as witty or delightful as you can while doing it. It is also important to make sure you type in the correct formality for your members.


3. Welcome them properly.

It doesn't feel great spending so much time filling out registration and membership forms to then only walk in through the door with every single staff member acting as if you don’t exist.


A major part of the on boarding process is making a new member feel welcome. You want to be able to thank them for taking the time to join your product instead of just sending the invite to the junk box. If you haven’t set up a welcome email, then make one. It doesn't need to be long.


4. Making it easy.

This is where you will lose sign ups. Life is complicated enough as it is and if you do not make your sign up simple, you will be losing customers. Take some time to figure out what you actually want to know from your customers- the bare basics.


5.  Save them time.

Nobody, including ourselves, like being asked to fill out questionnaires or registration forms by people in the streets. You’re in a rush, you have to go to the doctor with your headphones in.  I’ve used all the excuses in the world not to stop to be asked to fill out a questionnaire. We don’t have a lot of spare time. We value our information and don’t necessarily feel comfortable sharing a lot of information right from the start.



Social log-in is a great time saver that is appreciated by a vast majority of consumers. You’re going to have some people who do not want to use this option, but you can offer a different mode for them. Pinterest is a great example of this. They have an option for a social log-in, or you can create a direct account. Do the same thing for your visitors.

The on boarding process should be warm in tone, fun and offer additional guidance if necessary. For example, if you've got a video available on how to make the most of their experience, this information should be included both in the email you send out and in their welcome  page.

6.  Creating a compelling CTA.

No matter what market you’re in, chances are you are facing some stiff competition out there. What can you do to make signing up for your customer a “must”? Take a step back and distil what it is that makes you unique into no more than 2 sentences. Your tagline should be placed in a prominent spot on your landing page.

7. Making Referrals.


The best way to make an influential person shout about your company? Start including friend referencing on your boarding process.  A fantastic example of this is Facebook. When you sign up and are getting your profile ready, you have the option of inviting friends/existing contacts.

There is nothing more influential than a customer who is totally excited about what you have to offer and wants to be the first person to share it with friends.

The added benefit of a referral goes back to your growth funnel. It takes a lot of people pouring into the funnel to keep it full so why not let your customers help you keep it full.

8. Don’t break the flow.

Designers usually strive to get the users into a state of “flow” in which a person performing an activity is fully immersed in a feeling of focus, full involvement in the process of the activity. There are many tools to help designers make this happen that can also be implemented into the design of your on boarding process.


One of the main requirements is to be as unobtrusive as possible. For example, don’t surprise your users with unexpected pop ups and messages. The best way to prepare the user is show them what steps are coming up and what they have left. For a fluid experience, context is important.



9. On boarding is a relationship and is ongoing.

Relationships are built on trust so don’t mislead your users and make it easy for them to trust you. Your users are new and are figuring out there way around your product. You need to nurture the relationship between yourself and them to keep the relationship going. Engage your users in a natural yet friendly way. You should spend time very early on in the on boarding process getting to know your users and what their needs are. This could be sending me them a personalized note to each individual right after the moment of email verification.10. Ease them in gently. People, including myself hate it when you visit a page or an application where it’s so busy and over complex, it makes me want to stay away. This isn't to say that you should not do something personal and fascinating.  What you don’t want to do is overwhelm the new users on their first visits to your application.There some examples of pages and apps where all the white space is full of content. Colours, images and words. It can all be a bit too much for a new user to handle. With some effort, the experience can be elegant and informative without over stimulating the user. Short tips and pop up notifications are a good way to guide new users through the appropriate steps. Be sure to show them one at a time. Tell them directly what they need to know and when they need to know it. Don’t make them remember too much as they will forget it. Instead, use reminders.Overall, on boarding new users should be a fun and creative experience to help develop your product. There are hundreds of tools out there to help you optimize your product. Experiment with different tools and features to your advantage.



Sources and Further Reading



Reigniting an Old Flame || Fuelr

When I was 18 (I think, it was such a frickin' long time ago), I used to sit in office buildings for 12 hours straight, working site security to pay for my university fees (well, beer money). I was fascinated by the idea of offering prescribed physical activity for people with chronic conditions, and for the prevention of disease in at-risk populations. 

I had completed a module in my sports studies degree, on this very subject. The NHS had not long released the framework for quality assurance, for the prescription of exercise and exercise referral schemes.

I used to write business plan after business plan, how I would construct a company to offer such services. I would talk to GPs and practise managers. I would do cashflow forecasts and P&Ls. I would research the equipment needs, and create startup cost budgets. 

Then I did nothing about it. Until now. 14 years later.

Not only am I now working on a next-generation Social Care platform, which is all about re-enablement and self-management of conditions, but I'm also working on a health and wellness platform for tracking and improving your overall wellbeing, by improving your knowledge and behaviour through the use of smart technologies and connected devices. I am now positioned to build something that does what I wanted, only a decade ago.

But, this is not the same plan - such has been the journey and has lead me back to this point. My education, in particular over the past 4 - 5 years, has armed me with what I was missing back then.

- Technical skills and the ability to execute.

- The mental processes that force me to ship a product

- Confirmation that my passion for this space is unyielding.

- Knowledge of a global market opportunity, enabled through technology, for distribution and scaleable business models.

The original idea was nice. But it wasn't scaleable. It was a lifestyle business idea, like a hairdressers, or an activity centre owner, or a restaurant owner.

I was in San Francisco 2 years ago, when I saw the idea, realised, working and gaining traction. A US startup called Wello had pulled together nascent real time video streaming protocols, such as webRTC, and modern web application development techniques, to offer a marketplace for exercise professionals.


Go to the site, and you can take part in pilates, yoga, circuits, cross-training, strength training... you name it. Delivered by real experts, in real time, at any time, wherever you or they are.

Now, this really appeals to me, both conceptually and technically.

So, this thread of posts is going to follow my exploration into building a very similar service offering, with I think, some key differentiators. We'll tackle the main technical concepts, including:

  • Building a web services / API using Ruby on Rails
  • Building a native iOS application, specifically for iPad
  • Using webRTC and the different options available to make this easier
  • Creating an admin area for the business
  • Creating the web application front end views




Fidgetstick - Under New Management

As you may recall, I sun-setted my social network for adventurous people, Fidgetstick, after a few years of trying to figure out how to build a business out of a verticalised social network.

The lessons were plentiful, the mistakes were hilariously obvious, the product was crap, the intent was genuine, the execution sadly lacking.

Mobile technology was nascent, social platforms were not so widely adopted. Timing was wrong. I didn't have the technical, design or product skills I have now. I didn't truly connect with the market.

But I have some unfinished business, and to address that I realised that someone else would need to continue my mission - their mission, with some help and guidance. 

I'm pleased to say that someone will be my younger brother Ben


He's a young, passionate adventure sports enthusiast - kayaker, climber, activity instructor, long boarder. He's a little illiterate (excuse his text speak, I will knock it out of him). Mostly, he's passionate, honest and determined and for me that's good enough. Everything else can be learned.

Ben inherits an existing community of 12,000+ adventurous people that are on Facebook and will reignite the activity around curation and distribution of the best adventure-sports related content from around the web, topical discussion and leverage the power of community to return value to its members - through exclusive offers, discounts, prizes etc. that community members will delight in.

As Ben gathers insights from his own experience and from interactions with the community, we'll start to plan what the next version of Fidgetstick should become... 

A community hub?
A store?
A micro-site?
A tool?
An information repository?
A media sharing site?
A product?
An app?

Right now, we're not guessing. But we are hoping that by restarting the conversation, getting excited about the outdoors, being adventurous, pushing the boundaries, scaring ourselves, trying new things with new people, we'll figure out what challenges lie ahead. and how technical solutions can help.

If you have any thoughts, tweet @fidgetstick  or 'like' the facebook page and join the conversation.


Nutribu - a simple, social language for Nutrition

Nutrition and the broader health tech industry is HOT right now. 

MyFitnessPal raised £18m in VC money from Accel and others
Fitbit Raises $43 Million From Qualcomm Ventures, SAP Ventures, And SoftBank Capital
Jawbone Acquires BodyMedia For Over $100 Million To Give It An Edge In Wearable Health Tracking

And that is just great. Because you may recall, that I have a bit of an interest in this area. From my tinkering and slight addiction to my Nike Fuel band, tracking my activity on a daily basis and monitoring against my goals - to the extent that I built my own little Fuel Band dashboard which you can see here.

But really, my interest in the space goes much further. You may recall this post, from back in March, where we took the Nutribu API and our nifty little iOS app Feedo to the Launch Festival in San Francisco. 

Since March, the team have been hard at work figuring out how best to go to market. We've been around the garden, in the pond, over the fence, back into the house and back to the garden again. We've talked about, mocked up, spec'd out and subsequently parked a number of different applications.

We've talked enterprise apps. 

We've talked API-only models.

We've talked consumer apps. 

We've talked products for SME's.

But, through this process one thing has really proven out. A lean approach to product development, a constant and relentless testing of hypotheses, fast decisions and challenging of specification to achieve the MVP (minimum viable product). 

Our founder and CEO Sergio Mottola has really grown in his role as an entrepreneur, particularly within the technology / software domain. His relentless pursuit of an ideal, a proposition to the marketplace to simplify and socialise nutrition to the extent that normal people understand it, to the extent that they actually talk about it openly and even compete to be "better" in the context of what they eat. 

And that's a very key point, which took me a little while to understand. The key is not to be better at eating more or less. It's not about eating less calories or any other single measure or macro-nutrient. 

It's about 1) understanding your personal nutritional requirements and 2) about being the best at eating the most balanced diet you can according to those needs. 

You see, the Guideline Daily Amounts that you see all over products are frankly nonsense. They're based on a standard profile of person who is not you. This is drummed home to me, when you look at a box of cereal, which is what my little boy of 2 eats, and the GDA's are based on a 35 year old! 

So, we resolved to build an application that would help people to understand their personal nutritional needs and easily, quickly track their consumption and performance over time with simple, clear measurements.  

Testing the Nutribu app sharing via Instagram

Testing the Nutribu app sharing via Instagram

These measurements become objects of conversation and interest among peers, as we compete to build the most nutritionally balanced versions of our dishes and over the course of a day, week, month, year or lifetime, be more balanced and conscious of what we're eating. They are visual, social and engaging - not overly complex, scientific or boring as we see right now. 

So, as we prepare to launch the Nutribu app in the next couple of months, it's clear that we're in the right space, that interest is high, capital is available and at the end of the day, when we ask ourselves "should this exist in the world and does it make a positive difference" we can confidently answer "yes". And that's a pretty damn good place to be.


Silicon Beach Pitch Event - Bournemouth & Poole College

Silicon Beach Pitch Event - Bournemouth & Poole College

 Last night I hot footed down to Bournemouth & Poole College, to the "Peter Jones Academy", for an evening rubbing shoulders with local angel investors, startup companies and student startups projects.

This was my first event of this nature locally, so I was very curious to see what it would be like, the atmosphere, the culture, how open and friendly people would be.

I was surprised initially at the number of suits in the room. I'm used to London startup events which are much more informal, but then, they are not events which have (I estimate) a 70 : 30 ratio of investors to entrepreneurs.

I was pleased to run into David Ford, from Poole based agency Bright Blue Day & part of the Silicon Beach Business Angels Network, who was similarly down-dressed and put me at ease.

After a brief convo with a few known faces, it was pitch-time. There will be a video of the pitches, so I wont regurgitate them, but I will give my initial reactions.

These are just my thoughts, sometimes contentious, often critical but mostly balanced. I wear my heart on my sleave (a quote from a previous boss during a PDR) ... 

Green Desk

A sound pitch of their suite of eco-business management software. Seemed to have significant domain expertise and some early traction with significant customers and growth potential. The financial numbers were a little on the sceptical side, would have preferred to see something a little more exciting here.

Two main issues for me.

1. Kicking things off with this presentation really didn't set an energetic tone for those to follow - whilst it was interesting, it wasn't engaging, passionate or exciting in it's delivery.

2. There was a lot of focus put onto a core "middle area" of the product, which was the companies secret-sauce. This all-important, competitor beating area consisted of a suite of 10 apps. I think mobile apps. But seriously - 10! And then they moved on, skipping any further information into this mission critical, highly complex but ultimately most powerful aspect of their pitch.

I remember writing straight away the following questions:

10 apps? why 10 apps? why not 1 app?

what do they do?

do they exist?

if so, which ones? all of them?

Tell me more... TELL ME MORE. But alas, there was a gaping whole in the presentation around the most crucial part, so for me, it was a shame as for the most part, it was one of the best pitches.


Following up one fairly dry presentation was.... yet another one. I could tell, once again that the presenter had vast domain expertise and has been a successful entrepreneur with a good track record. But, the presentation was dry, visualisation of the software was lacking any appeal and there appeared to be holes in the business model, given the amount of investment made to date and the level of traction in the form of genuine revenues.

I think that either this will be a business that you don't ever see but will touch you as a consumer or company in some way in the future without you knowing or with some effort in product design and user experience, could be a very powerful end product / service in its own right.

At this point in time, after these two presentations, I'm thinking we have a very compelling case for an Unsexy Startups Meetup. Very sound, very valid startup propositions led by devoted, highly qualified experts in areas which are not consumer oriented, not sexy.

Buzz Networks

Continuing the trend of disappointing presentations, Buzz networks committed a significant number of pitch faux pas.

1. Played 2 explainer videos during the pitch, each a few minutes long.

2. As a result of 1. and the general complexity of the pitch, overran the alloted time significantly

N.B. note to organisers - get strict on the timeframe allowed for pitches, make it clearly known by pitching company beforehand, stick to it - cut them off if you need to.

The Bubba product was interesting and disappointing in the same breath. 

1. If you've got a piece of hardware - bring it, show it, get it out.

Caveat to 1. If it's ugly, think twice, if it makes a cool demo, still bring the device.

2. If you developed it, show me patents, tell me about the IP. If you didn't and you're merely distributing it - what are you doing on the stage? Just get out there and sell! I'm not clear which one applies.

3. Focus on design. A new benchmark exists - you only have to browse Kickstarter to see how hardware industrial design has taken a huge kick up the arse and now anything less than great will not get the interest, it;s that simple.

4. What a cool device - I'd love to have one of these with me in my beach hut, in my tent/caravan, on a boat. Remote / mobile internet access is still bad when I want to be out being active and pursuing my lifestyle by design. This would really help, if only it didn't look like a

One of the other products was a Google Voice style "one number, anywhere" proposition that wasn't compelling and I wont bother going over it.

Bet Live Sport

Oh dear, yet another terribly constructed pitch. OK, so we're going to have to lower expectations on this front for now. We've got some work to do.

The business? Well, I'm not entirely sure what it is - a content-company-come-affiliate-betting business? Using the medium of internet radio (because it's unregulated, unlike commercial radio) which, according to one of the presenters, means that it's a global company for some obscure reason.

We were told how in order for this venture to succeed, they would need to reach listeners. Right, ok - and how do we propose to do that?

"...well these days, Google favours original content."

OK so, it's an SEO play. For radio.

"Because we will transcribe and syndicate the spoken conversation from the shows to drive traffic."

Oh. Really. Interesting assumption, remaining highly sceptical here. The SEO for Dummies course was not well received.

Alright, so I'm being a bit flippant, but really, many aspects of the pitch were really not where they needed to be, they lacked any evidence of proper research or actions to prove or disprove the assumptions.

But, one ray of hope. Listed as one of the co-founders is none other than TV & Sport's Andrew Castle. Oh, well, sign me up.

The one positive was that the third founder actually had some significant domain expertise, having started and run William Hill's own sports betting radio station.

Borrow My Doggy

Aha! A breath of fresh air. This is someone who can present in a fashion which I am more accustomed to.

"Spreading pawprints of happiness" was their motto, and finally, just the enthusiasm and passion of the presenter left at least one or two pawprints for me.

Clearly evidence of some more modern entrepreneur education (thanks to Seedcamp, Lean Startup Machine et al.), and a business that is firmly routed in a hot and growing trend of the "sharing economy".

As such, and due to the object of the business being a highly emotional and personal one (even for the 80% of the room who actually owned a dog), Borrow My Doggy has been able to gather a significant amount of PR and some early traction as a result.

It's all looking good, so far.

Then here comes the business model & pricing strategy and some clear issues arise.

1. The focus of the platform quickly gets diluted into a "warts and all" hub for everything doggy. A dog social network. Facebook for dogs. Please, please do not do this. Stay focussed, concentrate on the core and make the experience for dog, dog owner and dog borrower as wonderful as it should be.

2. Verification tied to the subscription tier is the WRONG way to go. The whole business is one horrific press story of doggy mistreatment away from crashing. Verification, validation, reference checking, home checking, personality and character checking IS THE BRAND. It is an overhead of the business and an opportunity to keep competitors at bay. Split this out from the product tiers right now and focus on value added services and privileges within the subscription model. 

After the pitches, it was break out time where the companies hosted interested investors for Q&A. I got slightly way-laid as I got talking to one of the founders of a Somerset based CRM platform, a bootstrapped startup of 12 people, called IntouchCRM. Not a bad effort from the West Country startup, would be great to see them build on the British-made option for integrated CRM / CMS technology.

Overall, the event was pretty good. More than anything, I felt that there was a very positive buzz around the attendees - a genuine interest in being involved in startups, entrepreneurship and investment through Silicon Beach Business Angels and most importantly, in the Bournemouth, Poole and Christchurch area.

We have some way to go to ensure that local startups get the best visibility with investors, press and most importantly, potential early customers if these presentations are anything to go by - but that's quite easy to solve with a better support and mentoring structure in place.

Learning Ruby on Rails Development - My Progress

Learning Ruby on Rails Development - My Progress

As I took the very easy decision (albeit painful, lonely and stressful at times) to create Braindu I also undertook to learn some new technical skills.

Braindu is a complex web application that uses a number of cutting edge web application development technologies, which I've discussed briefly before.

On the server side, the platform is built using the now popular and impressive Ruby on Rails platform. My development team are extremely experienced Rails developers, but for this project, I wanted to get stuck in myself and learn to code Rails apps from scratch.

I've talked before about how I'm sudo-addicted to online learning platforms, such as Code School, Codecademy, Treehouse &

But alas, with everything you have to take in, everything you come across from tutorials, courses, videos, documents, articles, e-books, plugins, gemfiles, extensions, frameworks, libraries... it opens you up to a whole world of information that you need to navigate, store, manage, curate and constantly refer to on a regular basis as you advance your practical knowledge and experience with a framework like Rails - it's a frickin' nightmare.

How I Learn Ruby on Rails with Braindu

How I Learn Ruby on Rails with Braindu

Fortunately for me I've got Braindu. The product that is encouraging me to learn Rails is also the app that is helping me to learn rails (and many other companion technologies, such as SASS, HAML, SVG, CoffeeScript) and now I cannot live without it.

Now I know I have a slight conflict of interest, but seriously, my learning process has been transformed.

And with Braindu, I can share with you my collection of resources - a live and organic repository of information relating to my mission to hold my own at developing web applications and software. Amazing considering that I couldn't even build a website but 4 years ago.

Sit back and Browse with the Read View.

Sit back and Browse with the Read View.

I've got a long way to go to be able to have at least a modicum of technical credibility among the experts that I work with every day, but the ability to get closer to the technical team's challenges through better technical skill development and knowledge is already paying dividends.

Right, back to a brief coffee break and a dabble with the Evernote API via the new Codecademy API pathways. How I've changed.

From Startup to Stay Up - Bournemouth Uni EBC Event

From Startup to Stay Up - Bournemouth Uni EBC Event

Tonight I attended what I hope to be the first of many more local events aimed at Entrepreneurship, Technology, Business, Startups & Digital Media. This particular event, held on the 7th Floor of the Executive Business Center of Bournemouth University, fits into the category of general business advice.

Steve Taylor talks about his theory of Systematic Business Innovation, a subject that he has covered alongside well known startups & creative industry organisations like NESTA, Creative England & the British Council in helping entrepreneurs throughout the UK and in developing economies such as China and India.

The talk itself covered a lot of general issues faced by all new business owners, without focus on any specific category or industry sector. Though, Steve was explicit in defining the particular stage of company, characterised by the number of employees, where he particularly specialised.

Start Up to Stay Up - 10/12 employees

Stay Up to Grow Up - 30 / 35 employees

The Startup to Stay Up phase of a company (hence the name of the event) is where Steve concentrates his expertise and experience. It is at this stage where signals of stress on the company will culminate in the prevention of growth - something that Steve says can be overcome through a strategy for Systematic Business Innovation.

The key steps towards such a strategy, in Steve's words are;

  1. Benchmarking - a real and honest look at the business' position today.
  2. Draw your Vision - the ability to visualise your vision in a graphical format
  3. Build an Integrated Roadmap - a systematic view of the business and interdependencies e.g. see Disney example
  4. Bake Innovation Skills into the Management Team - the learning process of innovation skills 
  5. Apply Innovation Across Business Model & Engine - treat the innovation of business processes in the same way you did the original idea / product / concept
  6. Get Management Information Flowing - real, useful business data (which many companies just don't have or use) is imperative to quality, innovative decision making.
  7. Develop the Entrepreneur's Business Skills - As the business grows, the demands on the entrepreneur means that often the need to grow business management skills outpaces the actual growth.
  8. Develop a Senior Management Team - A top level strategic cluster that can effectively step out of the operational activities and apply strategy in the face of the day to day demands of the business.

Now, I know I've missed or consolidated some of the main points, but I think illustrates it well.

Braindu Chart of notes, links and additional sources.

Braindu Chart of notes, links and additional sources.

My opinion on the content of the talk was that it was a bit fluffy, in general, skirting around areas which could have been better served with real examples, definitive and specific applications of the theory instead of vague associations. Not sure if this was due to client confidentiality reasons (Steve is, I gather, a paid consultant), a dumbing down of the content for an incorrect perception of the audience or just room for improvement next time.

The Q&A was a little cringe worthy as Steve struggled to answer with clarity and conviction, and instead resorting to slightly off topic answers that didn't really address the question asker's need.

Nonetheless, done so in a light hearted and not too dissatisfying way, in that the general underlying subject of the talk provided some significant value - being able to step outside the day to day of the business, visualise and communicate a vision, create a strategy towards that vision that can galvanise a small company to work towards a cohesive, common goal (albeit a very fluid and iterative one).

My feeling is that a day's session with Steve would be very useful to get a crystallised sense of your vision or make you realise just how different the path's of you and your co-founders are on. Be warned.

My Event Score:

Venue ****

Refreshments ***

Content **

Networking **

Into the eyes of the VC

Into the eyes of the VC

I created an Import feature for my old MySpareBrain charts to be brought into Braindu. One of my favourites is my curated collection of information about London VC's - notes, contact info, backgrounds, portfolios, office maps etc.

London Venture Capitalists

London Venture Capitalists

After the import, I was cleaning up and adjusting the icon images via the Braindu image adjustment feature, when I came to zoom in on the guys from Accel Ventures. Most of the images positions had defaulted to just show the eyes and some small additional facial features.

I found myself staring at the collection of eyes, wondering to myself what story they told, which eyes would I trust, which eyes would be welcoming to my story, which eyes offered a balance of critical thinking and supportive encouragement, which eyes would I want to stare into at a board meeting or over coffee?

Freak huh? Look at your VC in the eye and see what it tells you...

Take a look at my London VC Chart here if you like...

Glass: I'm Eating This - Google Glass has me excited

Glass: I'm Eating This - Google Glass has me excited

I just watched Google Glass developer advocate Timothy Jordan's 50 minute long presentation from SXSW, where he publicly presented the Google Glass Project, some interesting use-cases and a first look at the Mirror API.

The whole platform feels sleek, elegant and simple. The API is similarly so, where the interaction and information transactions are small, timely and impactful snippets that augment what you are doing right now and otherwise, get the hell out of the way.

Design for Glass - The Glass design is unique and fundamentally different than existing mobile platforms. It's important to build and test specifically for Glass to create a great service.
Don't get in the way - Services should be there when you want them and out of the way when you don't. They should never take precedence over what else the user may be doing.
Keep it timely - Glass is most effective when in-the-moment and up-to-date. User requests should be handled immediately and information should always be fresh.
Avoid the unexpected - Giving users unexpected and unpleasant functionality is bad on any platform, but particularly bad on Glass given how close it is to the user's senses.

I've been working on a fascinating project with Nutribu, a startup looking to transform how we interact with the complex and boring world of nutrition into a fun, social and competitive experience.

Google Glass could be the answer to how we may capture real-time transactions, like eating a meal, in an unobtrusive or overly clunky way - a problem which currently exists with web and mobile nutrition diaries and calorie counters.

Instead, Glass potentially offers all sorts of mechanics to make nutrition, eating consciously and with access to relevant information about our consumption a fun, data-driven and socially interactive experience.

It also gets me thinking about we access our personal information repositories, with services like my very own Braindu, so that our data is available to us in an actionable, real-time mechanic. I'm very excited to try out the API and build Mirror API-based services.

You can see my Braindu chart on the subject of Google Glass here with links, videos, images and notes that I expect will grow over time.

Nutribu, Feedo and the Launch Festival

"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.


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.


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.

Braindu - Hacking the Project Management Workflow

As you may or may not be aware, the last couple of months have been all about the Braindu. In some ways, a bit of quiet time over Christmas was welcome so we could really concentrate on creating, completely from scratch, a brand new product that built on the work I was doing at MySpareBrain and taking it to a whole new level.

Many of the core concepts of Braindu are driven by the same vision I had for MySpareBrain and obviously, from a standing start, the basic product features - the ability to add information as objects on a flexible workspace, within which you can store notes static content and optionally extend the information to 3rd party services, but that's where the similarities - such as those similarities with other such services, like Pearltrees,, and the tens of mindmapping services are put to bed.

Braindu is so much more. 

I'm very excited about many of the features I've shoe-horned into the first release, stuff I've wanted for ages in my own app and own workflow and managed to convince the team that it's for the greater good.

First up, the extended 3rd party add ons include Dropbox, Google Drive and now Odesk. Add my choice of Project Management system and Code Repository and my agency workflow can all take place within Braindu - awesome! I'll be able to track all my core apps for each project in one chart, along with the supplementary info, documents, notes, files that are stored everywhere else in no end of different apps.

Here's what my project specific collection of apps used to look like, regardless of project size or specification.

  • Dropbox folder, with Templated, Nested sub-folder structure for files, assets, copies of docs etc.
  • Lighthouse Project
  • Odesk Assignments - team members reference projects by project number and PM system task number in their time tracking. Additional team members recruited and added according to special project needs.
  • Beanstalkapp (for private projects) GIT/SVN Repository
  • Google Drive Folder & Documents - Project Budgets, Team Time-sheet Reconciliation, Receipts, Project Specifications / Briefing Documents
  • Smartsheet / Gantter - Project timeline / GANTT Chart

Then there's the casual apps

  • Campfire - Developer Team Room
  • Skype - Client / Team 1 on 1 Comms
  • Wunderlist - To Do's / Task Reminders
  • Evernote - Notes

Not to mention all the project specific research, tutorials, articles and other resources.

In some pretty unscientific testing, I reckon that I must touch at least 75 different root applications and resources per project regardless of size. And for complex projects, such as building Braindu or the API / iOS app that I'm building right now, it's more like 200 - 300 apps and resources at least.

Now that takes quite some managing. Not only that, it takes quite some time to actually setup, most of these apps require some sort of administration before you can actually use them, which involves (hopefully) remembering your login, setting up a new project instance of whatever the app purpose is serving, adding some information and then adding more information as the project progresses. You only have to do that on a few apps and there's a morning gone. Sure some of this is integral to a solid project management process, but there's considerable management wastage and inefficiency aswell.

This is compounded when we approach projects from a team perspective. We rarely work entirely alone, whether we are part of a larger agency-side team of project managers, designers, developers and/or working with our clients to provide the best service we can - we are part of a group dynamic. But our tools, even the most collaborative one's like Dropbox, Google Drive and project management systems like Basecamp or Lighthouse, are not designed to enable a fully collaborative workflow - they focus on very specific use-cases. 

As such, from a team perspective, there are huge inefficiencies within the project process when it comes to the collecting, organising and managing of information. A high percentage of duplication, information that never leaves the individual's own information repository and therefore is a lost opportunity for the project team and the inability to find or retrieve historically stored information that may be useful or pertinent in the moment.

My ambition is to reduce the amount of time it takes to setup for a new project to a third of the time. To reduce the amount of unshared information in a project team by 50%. To reduce the number of tabs you need to have open in the browser on a day to day basis just to track your live apps by a third.

So far the signs are good. Actually they're better than good but they're not quite great and that's the focus right now.

Consider that nearly $1 Trillion of cost annually is attributed to the US economy due to information overwhelm and that at a very localised level, as individuals, we spend up to 50% of our working day just managing information, you can see just how significant a problem this is and how attractive the solution could be. 

I hope Braindu will be able to help you, like it's already helping me, my teams and my clients.

Braindu - Collect, Organise and Share Information to Learn.

Well, I thought it was about time I show you what I've been up to for the past 6 weeks or so and I'm very excited to show you because it's been one hell of a ride.

Ever since I wrote this post, updating you on the changes at MySpareBrain, it's been all about the new project. Braindu was born.

The Braindu Product Website

Braindu continues and builds upon the work I was doing previously, but takes a more refined and targeted approach to providing a platform for collecting, organising, managing an sharing information - not only as an individual, but collaboratively.

The key here is balancing features and functionality with simplicity & elegance of design - a constant trade off that we must remain cognisant of.

I'll follow up in more detail about some of the new technologies, new features and functionality as they are added, as we build up to a more publicly accessible product launch. But here's a little teaser of the new application's core interface.

Building a Startup Team - Build a better you.

You may have heard me explain my philosophy for building teams before. If you haven't, it's fairly simple.

Identify the resources I need, define & allocate roles and then hire people that are better than me to fill those roles.

As a startup entrepreneur I know that at the beginning, I need to fill multiple roles and show competence, heck even some degree of excellence, at more than one of them at a time. This applies to design, sales, marketing, finance or product development - all of which I have done myself or recruited/outsourced for.

I also have a clear understanding of where my abilities do not come up to scratch and I am very cognisant of my shortcomings. So, hiring for some roles has been easy, such as in engineering for example, as the benchmark I set was pretty low.

It was only 4 years ago that I didn't have a clue how to create a website. I shudder at my lack of knowledge as I blindly blundered my way into building a social network with only my passion for adventure sports and ability to learn quickly to guide me. 

It wasn't hard to find someone better than me then, in fact anyone was better than me.

But since that time, I've progressed. I've built things. I've built teams that have built things. I've learned so much that has helped me understand the difference between a good developer and a great developer. Who can build products, who can do tasks, who can create and manage infrastructure. These are all potentially different people.

So, I have tried to be a better non-technical founder. I've tried to be interested in technical issues and understand the background processes to making technical decisions. I've been trying to learn to code. I've experimented with lots of different languages, markups, libraries and frameworks. I am still a master of none, and I don't intend that to necessarily change (at least currently).

If I am working with clients, I want the solution to fit the need, not to fit my own limited abilities. If I'm working on an internal project, I want the project to further my understanding of different technologies, not labour on perhaps my outdated and under utilised knowledge of a specific technology.

But, whilst many techies may believe a little knowledge to be more dangerous than beneficial, I have certainly found that a broad understanding of technical principles, scripting languages, markups, processes and methodologies has helped me in a few key ways.

  • Raising the benchmark for team members - as I improve, so does my team and knowledge of building teams and recruiting specialist talent.
  • Embracing new technologies - my naivety has proved successful in opening up new pathways that may not have been obvious before, rather than the (often frustrating levels of) fear that more established devs may have of new tech (I've seen it).
  • Building relationships - The improvement in my knowledge has had a direct correlation to my improved ability to establish and maintain positive relationships with my technical teams. A better understanding of the issues, the challenges, the motivations of my developments teams helps foster a much more dynamic and mutually beneficial working culture.

Resources that have helped me

Codecademy 50th Achievement

I will shortly publish a very full and extensive list of resources that I use, but I find that blog posts really aren't conducive to doing that in a way that is truly useful, so I will avoid it for now. Needless to say, I am working to solve that with my latest project. and you'll be the first to hear about it.

In the meantime, I will share a small milestone with you. I have been playing with Codecademy off and on this year. In typical fashion, I've varied my learning, from the grass roots Fundamentals of HTML, to CSS, to Javascript and in particular, the JQuery library, to the programming language Ruby. I just hit my 50th Achievement on the learning platform, which I think is quite nice. I'm waiting for some more Ruby courses to be released and in the meantime will continue with the Javascript courses.

Christmas Prezzies from the Tech World

I wrote about my impending Christmas of heads down grafting on a new, improved product for managing your online information. Well, Christmas has come and gone, leaving only an empty box of Lindt Lindor chocolates, 1/2 stone in excess body fat and a little 21 month old boy even more addicted to trains than he was before.

And true to my intentions, we've been busy.

I'll be giving you regular updates on that from now on, as and when there's something significant to show and tell. But in the meantime, I want to say that having delved into the world of real-time, complex web-app development from scratch, how impressed I am with the open source eco-system. 

The technologies, tools, libraries and frameworks at our disposal our numerous, with more being created all the time. This post is a brief overview of those which we have decided to implement as core, or test as necessary. Some you will certainly know, some you may not... all worth noting and adding to your list of tech-to-try.


Heroku - Although it is my first real experience building on Heroku, the choice was an easy one. Free setup, easy to scale, support for and easy installation of 3rd party apps like SendGrid, New Relic and others, the list goes on. I've had to become a little more familiar with GIT (I use SVN normally) but deploying to our repo at  has been pretty easy.

Server Side

MongoDB - Another first has been a foray into the world of noSQL databases. Not because it's trendy, hip or fashionable to do so, but because we felt this would be the best fit for database needs - primarily due to our perceived "need for speed". We took a lot of guidance from the team at Trello, who have been kind enough to detail lots of thoughts on their choice of stack.  I'm not qualified to debate on SQL over noSQL, but experience with query speeds using mySQL previously (on just about every other project I've built) urged me to try something new, and for this product, definitely seems to be a good fit.

Ruby on Rails - At MySpareBrain, the app was built on Google App Engine and thus, any server side scripting was written in Python. For this new product, we discounted Python due to new team skills and experience. We toyed with using Node.js which has been growing in popularity, but in the end opted to progress with Ruby on Rails providing the server side MVC we need, which also works very well with MongoDB.

Devise for RoR - Devise is a modular authentication solution for RoR. We've used Devise in conjunction with Facebook and Twitter social login API's for what we think is a nicely rounded model for creating and managing user accounts with different roles & capabilities. Check out the docs on Github

Client Side

Backbone.js - Backbone is, as the name suggests, at the er, *heart*, of our web application providing structure and order to the complex front-end javascript code required for something like this. Backbone's only dependency is Underscore.js, a utility-belt of functional programming support for Javascript.

Raphael.js - a nifty little javascript library for working with vector graphics on the web, we've been playing with Raphael predominantly due to it's SVG support (as opposed to other HTML5 canvas-based libraries. It's been quite useful for quickly rendering objects within the app's UI, but we have started to hit some limitations/complications for more complex uses - particularly when trying to append HTML to extend basic Raphael objects. We've got around it so far, in one case, by opting to paint in the additional interactive elements, but jury's out on it's longer term viability. Another test will be performance under stress of high volumes of objects rendering simultaneously   

D3js - D3 is a library for manipulating javascript documents using data. Some initial scoping tests suggest this may be a suitable alternative to Raphael, but we're still testing/reviewing the docs. From a pure product perspective, I'm interested in the physics engine and it's possible uses for the app, though this maybe a bit of a creative tangent.

Angular.js - This is a little misleading, as we're not currently using Angular. Consider it a bonus. But I have been playing with it a bit (I have the makings of a nifty little to-do list app). It's interesting because it enables you to write functional code into the html which makes it quick, relatively easy and clear to read when building web applications.

CoffeeScript - Hey, it's just javascript. But having done a few javascript courses and tutorials (check out my Codecademy badges) I can see how the reduction in braces and semi colons could really help speed up my learning, development and reduce stupid errors. More importantly, the devs can rattle out CoffeeScript like there's no tomorrow and therein lies the real benefit for us.

Animate.css - A sweet little CSS3 library for CSS animations that's very easy to use, cross-browser compatible. Use with class and subtlety. Overuse will kill you. 

Kinetic.js - Since we made the decision to use SVG for objects in the new product, Kinetic wasn't really going to be all that much help to us. But, I found a little time to use it to fake the drag and drop of objects that we create in the app using Raphael, in a little section of my attempt to take the online Pitch Deck to the next level. I'll be posting about that soon... Kinetic is good for lots of reasons, just a quick look at some of the demos / examples show just how complex graphical animations can be produced.

SASS - Less or SASS, Less or SASS? OK, SASS. Development team choice, I think related to personal preference of indentations and workflow with HAML, which SASS takes it's own inspiration from. See this to help you decide which to use. 

HAML - Our pursuit for beautiful code, something which we decided we wanted to get right from the off, led us to use HAML, for simplified template creation - particularly useful for RoR apps. Our development principles align with HAMLs stated objectives:

  • Markup should be beautiful
  • Markup should be DRY
  • Markup should be well indented
  • HTML structure should be clear

Startups: Rise and Fall and Rise Again

November and December have been TOUGH, work-wise. I'll tell you why, as it's something which we, as entrepreneurs and startup founders, will have to face, draw inspiration from and persevere.

First, I'll give you the background.


If you know me, you'll know that for the past 12 months, I have thrown my energy and passion into a startup project, called MySpareBrain (MSB). MSB was a web application, which was built as a proof of engineering by Tim Meadowcroft - a very talented  and experienced software developer who built some highly noteable and complex products, including i2's Law Enforcement and Fraud Prevention systems (now owned by IBM after £450m  acquisition in 2010) and SwapsWire (now Markit).

As Tim's wife once said to me, "if Tim doesn't know how to do something, he'll read about it until he does". That's Tim.

I met Tim when he applied with his initial concept to pitch at one of my events, This Week in Startups London Meetup, when Jason Calacanis came over last year. I had been looking into the space for a while beforehand, having worked with complex projects, copious web applications and spent an unhealthy amount of time online drowning in information -  so immediately connected with Tim's mission. The product was a little raw for the event, but after a number late night telephone conversations, failed skype calls, GChats discussing the software, suggesting improvements to the design and user interface, features and other such things that I wanted to see as a user, I had bought into the concept.

Tim and I met a few times for dinner and pints, and I was really pleasantly surprised to see how reactive Tim was to early suggestions - implementing new features and integrations seemingly at will and pushing them straight up to the app, which was in an invite-only closed BETA phase.

We decided to team up, and in March 2012 we incorporated the company and took the product to the Launch Conference in San Francisco. Having applied for the main 1.0 event. I was disappointed that, in the build up to the event, we weren't able to significantly advance the product enough to be considered. Sure, our technology was great - but you need a certain sex appeal for these competitions-slash-penis-parades that we obviously hadn't mastered in time.

Instead, we took part in the Demo Pit, among a hall of other startups vying for attention of the judges to get selected to go up on stage anyway. Frustratingly, I spent the two days chasing ghosts, as the Judges tasked with picking out the startups they liked seemed to miss out our table - I don't recall speaking to one of them with the product at hand, and when I did, was told that the baton had been passed to someone else - argh! Anyway, we did get to demo our butts off to fellow entrepreneurs and investors to extremely positive feedback.

This is one of the Coolest Things I’ve Seen!
— Adeo Ressi, Founder Institute
One of my favourite startups at Launch
— Boonsri Dickinson, Business Insider
“Mysparebrain was perhaps the most impressive start-up I encountered at LAUNCH. Let’s stay in touch.”
— Brandon Adams, Pro Poker Player

We were in SF for just over a week, as after the event, Tim and I headed down to Mountain View to hang out with other startup folks, check out the scene and hopefully meet some investors. It was during this time that looking back, I think my relationship with Tim took a strange an unexpected turn.

Whether it was homesickness, frustrations from not achieving perhaps what we'd set out to at Launch or, as Tim suggested at the time, frustrations of not being "productive". I think that meant, time not coding and adding new features, fixing bugs - to be honest, I don't know what it meant but I really should have found out, because it was clearly bugging Tim. Tim turned from a helpful, thoughtful knowledgeable guy, to an overly aggressive, impulsive, hot-headed, know-it-all for a period, and was clearly getting agitated by things.

I put it down to missing his son, being away from home and I acknowledged it, but decided to push on regardless.


After the Launch Conference, the plan was to use any momentum we had gained to work towards opening the app up and securing some late seed stage investment. By that, I mean raising circa £500 - £700,000 in venture capital.

We met with numerous VC's - from Accel, Balderton, Eden, Hoxton. I value Hussein Kanji's opinion and took the opportunity to get it when I could. I met with the true seed stage fund, Raj Ramamandi's Number One Seed and received a lot of interest.

The VC's, who supposedly did early stage, all wanted "traction". None could define traction, or even their own version of it, but they wanted it. They wanted a graph that shows a familiarly and frequently banded growth trend - "el hockius stickius".

What I took from that, was that they wanted to get on the Cruise Ship just after it left the dock, fighting with the other people who had done the same thing and pay a premium price for someone to give them a left on a posh speedboat or helicopter ride to catch up. Lesson learned.

So, I went back to the product and to business development to try and drum up some customers, some users. Anything we could do to show user adoption, activation, engagement, retention.

I spoke at Josh Liu's first Unsexy Startups meetup, and talked about the startup's dilemma - consumer or enterprise? and how the lines are greyer than ever before.

MSB could be a great individual consumer application. It worked great for individuals, privately, securely, there and then. Right now. But, it would work even better as a collaborative tool, where users could co-invest in the process of collecting, gathering, organising and interacting with information like they have never been able to before.

MSB would equally be a extraordinarily useful tool for teams, groups, departments, companies to collectively share information around organisations - cutting the huge amount of cost, wasted time and inefficiencies that searching for information and information overwhelm has caused the economies of the developed world.

But, as a team of two unfunded founders, where do you start? Is it a leap of faith? Go with your gut? Or can you collect some data? Qualitative? Quantitative? What type of samples do I need?

On the train to London one day, I was preparing a deck for a meeting and a guy got on the train and looked at my Macbook's screen from across the aisle.

"SpareBrain? I could do with one of those!". That was a common reaction to the brand.

For the next two hours, the man and I spoke in depth and excitedly about the product, my vision, and his failed attempts to find the right solution for the University where he was Dean and Head of Faculty.

I met up with the man, more politely known as Professor Oren Leiberman from the acclaimed Arts University Bournemouth, many times after that and in September 2012, we ran a pilot of MSB with his Masters Architecture course.

Through this time, I became convinced that this product would be great for students, academics and teachers to interact with information. But, something was missing to make this viable from what we had right now. Users needed to be able to collaborate. 

This was reinforced to me when I visited the Business Faculty at the University of Winchester (where I studied). The investment and advancement in facilities was staggering and all geared around collaboration - collaborative spaces, large screens with communal study/seating, connectivity everywhere. Collaboration is key.

The other reason was economics. I could spend 2 to 3 months researching and courting higher education Institutions to sell our product. I would invest that time because I know that by securing an advocate, the product would organically proliferate to the rest of the internal-community. through natural, useful, organic collaboration. But alas we didn't have it. Instead, I would have to sell once to get a point of entry, then sell again to every individual to convince them to use the solution - not cost effective, not sustainable, not viable.

Tim asserted that although collaboration was on his roadmap, it was a significantly complex feature set that wouldn't be done anytime soon and made it clear that it depended on the securing of VC funds to enable it.

So, I changed tack and investigated the consumer play.

It was much harder to get any meaningful data here, other than emotional, qualitative responses of our early users (circa 200) and their reactions, feedback and thoughts on the product. This is one example:

“First of all, I was already impressed with the demo, but once I opened up the live, beta site and saw your chart of “tools, libs, references” the lightbulb went to super-bright. It all came together as I browsed your chart. Wow – I can see how that must have really helped a lot while organizing the MySpareBrain tools and resources! I immediately started thinking, “What do I have that I can organize?” ;-)
As you can see, I’m a “try stuff out before reading the manual” type of guy, and I was constantly impressed by the fact that things I tried out “just worked”!

I love the app! You guys have done a terrific job, and I hope the app does really well when it is released. I’m getting addicted to it, and I’m even trying to find things to organize/brainstorm just so I can use the app :)

Thanks again for the access to the beta - It has been a pleasure to experience what you are working on!”
— Brian Hannah, Software Engineer

I was convinced, based on my own use (I came to depend on the app and my 100+ charts, 1000's of nodes of information, notes etc.) and from feedback like this and more of it, that at a consumer level, this product had legs.

I wanted to see how we could move from Private Individual App, to that plus more socially integrated publishing tools. I had a vision of people using MSB as a way to publish their "workings" of the different information resources they collect around a particular subject. MSB allows the free-form visual layout flexibility that makes information tactile, expressive and allows for freeform creative thinking. You may use it for planning projects, gathering source material for writing essays or blog posts, researching the competitive landscape, gathering tools and libraries for building websites - all sorts.  

The time invested in curating that content, adding one's own unique notes and annotations, adding meta information, assigning relationships - both explicit (via links) and inferred (by placement, color, size, clustering, chunking) is extremely valuable, but notably, the output can be damn useful to other people interested in the same topics.

I could see full charts (a collection of objects or nodes of information) being shared on social networks, individual objects being shared from the context of the chart. I could see charts being embedded along with the blog article, essay or report for a deeper look at the sources which, keep up to date with active information in real-time.

To do this, again would require some evolution of the MSB product and more development. It already had the ability to distinguish Private and Public charts. But the interface for sharing Public charts was far from optimised for such purposes. It was just an interactive view of all my Public charts displayed in the app, which to someone who had never used the app before, is a very daunting first experience and not one that is geared to immediate understanding and subsequent adoption.  

But, that's what I had to work with, so I ran some tests. I picked up on some topical and popular conversation threads via the Open Coffee forum in London. One of which that kept appearing was the subject of Explainer Videos - who much do they cost? how do I get one made? how can I guarantee quality? how much traffic will I get? does anyone know a script writer/motion graphics artist/animator/illustrator/voiceover artist?

So I spent a couple of hours preparing a chart of information on the subject - prices, research, tips, techniques, agencies, freelancers, sample videos - you name it - it was in there.

I shared that chart with the small community (remember, in a not ideal format) and that resulted in 10 registrations for the pre-launch BETA and activated accounts. I did that few more times with other subjects to similar results. With some proper optimisation, and putting relevant contextual information into the right places, I could get 50 registrations per chart published. That's me, with no real reach or influence, particularly in some of the topics for which I was publishing curated content.

If I could get influencers in their domain to do this, with a well designed public facing interface for sharing charts, I'm convinced that the viral co-efficient of the product would be epic. There is no better way currently - other apps and tools fall short, way short.

I explained this to Tim, when I got chance (Tim had become much more difficult to speak to, contact, get response from - meetings were fleeting and usually resulted in raising voices, frustrations and differing opinions), but similar to the Collaboration issue, Tim wasn't budging.

On the other hand, Tim felt very passionately about solving a particular issue - people saying "I don't get it" when receiving a cold intro the the app. It was true that, as a new interface for the web browser, it could be confusing - especially when you see someone else's chart full of information laid out in a way that is meaningful to them and no-one else. 

And he was right, there was no point opening up the app only to have a sky-high bounce rate right at the entrance to the funnel.

So we did set about designing and building an interactive demo page - a step by step walk-through of the interface, core features and user benefits. We built it over 4 or 5 weeks, and tested it with new users to some success.

The Beginning Of the End

By this point, it's summer and Tim had taken a contract with an investment bank which started as a part-time thing and quickly sucked up all of his time. Any contact we had before this basically reduced to zero - zero response, zero input, zero action. The interactive demo page which was supposed to enable us to open up the app remained in the background, tested but not implemented to the live app. 

Frustration was growing as time drifted by. I decided to try different tacks for getting Tim to do something, anything, to progress the product inline with my vision. He held all the keys to the product, he stood in front of all the gates. To him, it was his product, his code and although we were equal shareholders, by this time it was clear who was calling the shots and those shots were to not do anything. We were now acting slower than a lumbering blue-chip.

Tim's responses to my requests were becoming increasingly aggressive, like a parent talking to a stroppy teenager. And I may well have been acting like one - have you ever tried telling an entrepreneur that he can't do something? At one point, Tim told me:

I’ve already said no to you on this.

It’s not important, it’s not priority, and we’re not doing this now.
Leave it alone.

Please don’t make me repeat myself.”

To which, hugely offended and frustration reaching boiling point, I responded with:

I’m Done

He then asked me to clarify what I meant by that. What I did mean when I wrote it was, "that's it, I've had enough, I quit". But after a few deep breaths, I brushed it aside by saying that I was done asking about this particular task.

I decided to persevere with the Biz Dev opportunities, hoping that developments on the Customer side of things would help reinvigorate Tim's motivation and desire to get back to building - base don not what I said I wanted, but what customers and users said they wanted.

The pilot for AUB was setup to start with a talk / intro a gave on the 1st October. I requested some invites to be setup in bulk for the students, via Oren's account. This required Tim to flick a switch - nothing more. I got not reply to my request. I went to the meeting without this in place which was embarrassing and hugely frustrating. At this point in time, I knew that was it, I'd lost Tim or Tim had decided to lose me - either way, it really wasn't going to work out.

Eventually, we setup a management meeting - the first in months - where I thought we'd be able to discuss the issues, iron out the problems and get back to aligning our vision and agreeing a way to move forward together - driven by our common goal that joined us in the first instance.

Instead, after some small talk and niceties exchanged by Tim and I, whilst we waited for Tim's wife Sam, also a shareholder (minority) in MSB to arrive, I was coldly and succinctly told that Tim intended to stop our venture together, dissolve the company, take his product (the source code - in it's crudest definition) and basically do whatever he wanted to later on. I, on the other hand, would be left with nothing for my efforts.

Well, not quite nothing.

After quickly deciding that there was nothing more to be said there and then, somewhat  taken by surprise by the ambush, upset by the outcome, surprised by the coldness of the situation, I retreated and took a walk around London to think and clear my head.

I knew I'd have to seek legal council, as I was unclear as to my position - something I really should have had contingency for.

I spoke to my Lawyer, who having confirmed as I expected that having never got Tim to assign IP rights to the company for his source code from prior to our incorporation of the company and our dual input, I had little option. I could sue him, or I could suck it up and crack on.

I'm not going to sue anyone. I hold no grudge against Tim, on the contrary I have huge respect for his knowledge, his character (I saw the side of Tim that shows just how considerate and kind a person can be) and in hindsight, it was absolutely the right thing to do. It clearly wasn't working out for either of us and a decision had to be made. That decision was never going to be easy, but it could be dignified. I'm sure I was not faultless in whatever the causes were. But I know that I tried the best I could with the resources that I had. I truly hope that Tim and I can be professional, even friends as we presumably set out to realise our own visions which may or may not cross paths.

A week or so later, I was due to give a talk on the subject of the realities of entrepreneurship, and in particular, the importance of work experience. I nearly didn't go, but a few words of support from my wife I drove the hour to King's School Winchester, to unexpectedly, be met with an entire assembly hall of year 10 students who probably wanted to be anywhere but. To say I meant every word I said and how I said it was an understatement and it was refreshing and invigorating to get the feedback from these young aspiring business people.

I benefited in many, albeit less tangible ways from my time at MySpareBrain and working with a talented software engineer like Tim. 12 months ago, I could never have dreamed about building something so complex, so cutting-edge. My knowledge of the information architecture required to build such a product, for a non-engineer, is not insignificant.

And ultimately, I had to remind myself that being bound to MySpareBrain and being associated with Tim was not the goal* - the goal was to create a product that people love, that changes the way people manage and interact with online information and with each other using technology.

And it remains and always will be the driving force.

*initially, it was part of the goal. As a non-technical (well, non-technical-ish ,depends who you are asking) co-founder in a hi-tech internet startup, everywhere you'll read, from all the usual commentators, investors  and commentators-masquerading-as-investors that you need a CTO. You need a great geek. Well, I found one and went into partnership with one. Tim had all the credentials, Tim had built a solid early stage prototype. Tim could talk the talk and walk the walk. But that, in and of itself is not enough (in the UK, anyway). The technical conversation was lost on all the investors we met and never did anyone probe deep enough to understand the deep technical rationale and philosophy behind the product, the evolution of the market and the insights we had. So, it didn't matter - having a CTO is not important, at least not for raising money, unless not having one also precludes you from investment, but I don't think so. It is important for someone to take control of the technical implementation of the product, but not the product itself. The product is defined by the market and the market, or more specifically, the customers - and in turn they define the investment case. You have customers, there are more customers to be had (a lot more), you are growing - you get investment. No customers, get out of the fucking door and come back when you do.

The Rising

So, with a fresh, clean slate. A new project opened up in my code editor. A new and evolved set of tools and resources. An exciting, talented, technical and creative new team. The relationships and insights from talking with real customers who are just craving the product we know they want, and the knowledge that customers are waiting to pay for it and use it. Fresh designs and no restrictions (well some restrictions, but none that will stand in my way), I set out to build the product and the Global Technology Company that I, my family, friends, colleagues, customers, investors and peers will be proud of. 

Because that's how I deal with set backs. That's how I take failure. That's how much I love being kicked in the nuts. I'm back in the game, I'm all in. I'm funding it with whatever I can get my hands on - credit card debt, limited spare cash. But now I'm driving and in control.

We will build something that we love, and I don't think you and I are that dissimilar. Oh, and we will build it very soon (hint: Christmas will be very busy).

Merry Christmas One and All. Here's to an amazing 2013.

Disclaimer: I officially resigned as Director of MySpareBrain Limited on 6th December 2012, following consultation with Tim and agreement of the restrictions (there are none) of my business activities. This is my side of the story from the best of my recollection, and I expect anyone mentioned to have the right and privilege to express theirs accordingly, should anyone care to read it.

CEO Tech Forum at Hamilton Bradshaw

I accepted an invite to attend a CEO Tech Forum at Hamilton Bradshaw Venture Partners. Yes, that's right, James Caan's company (as they always seem to point out first of all, d'uh). No, not the actor, d'uh. I thought it would be an interesting way to spend a few hours with fellow tech CEO's and VCs.

The agenda looked promising - 

Technology Trends

Growing a Technology Business

Technological Excellence & Scaling

Realising Value

Raising Finance

But alas. 

If by technology trends you mean chuck around a few buzz words, with no real insight or application.

If you mean growing a technology business you mean "make sure you recruit top people whatever it costs (I know I'm a recruitment company, but come on son, you can afford it)",

By technological excellence and scaling you mean, actually I'm not really sure what the point was here other than it seemed to be very B2B focussed and drew some opposing views from fellow OC member Iqbal Gandham

If by Realising Value, you mean make sure you pay some good quality consultants to help you through the minefield that is Due Diligence (by the way, is an IPO not an exit strategy anymore?)

If by raising finance, you mean "it's frothy out there, there's loads of money, what do you mean you're not funded yet? There's angel groups popping up all over the place", followed by "let me help you raise money, I'll do the cold calling on your behalf, no win no fee"

All seemed a bit superficial, which was a shame, but not unexpected.

Now, I may be overly critical at this stage, but there was really very little value added by the talks. I'd have been more interested if the expert Venture Partners had actually sat back and asked the people with their fingers on the pulse to cover these topics and educate them.

But it felt more like a polite entry point to the sales pipeline of HVP and that someone internally thought, "I know this'll be a good idea". My feedback - listen more to the guys on the front line, get to know the real issues and don't assume to to know more about technology than us - maybe you do, but perhaps, maybe you don't.

If you pull out a sheet of paper and tell me that "my Alexa ranking is 3m+ and have more work to do there, sonny" like a) Alexa is some fantastic new secret weapon you've found to assert authority over others, and b) talk about the Interest Graph as a "thingy", then seriously, you have to listen more. To be fair, he was probably joking, but I just had a feeling he might not be...

No disrespect intended. The team at HBVP are clearly excellent and their track records speak for themselves. It was the first meetup of its kind and I hope they've got the appetite to push on and improve the format and content.

It was a nice polite event - it was, how can I put it - smiley, there were plenty of smiles. Some people went on a bit too long and diverted off topic for their own cause. The wine and canapes were a welcome site. I'd go again, if only to help improve the format, because although this wasn't great, I appreciate the effort, the sentiment and hope that is wasn't quite as shallow as it felt. The proof will be in the follow up.

James Caan made a brief appearance at the door of the conference room, but didn't stick around (another slight disappointment, for novelty sake it must be said).

For a look at who was at the event, check this out on the mysparebrain blog.

The Bootstrappers Manifesto

More After Effects tomfoolery. But under the Who-Framed-Roger-Rabbit-Judge-Doom-style voice, there's a clear message for all of us early stage entrepreneurs.

Original text by Seth Godin (King of Marketing-World)