Meet BuyReply

Over the last year I’ve been working with my team to develop a new eCommerce, marketing and transactional platform called BuyReply.

We’ve been deliberately vague and haven’t given much away about the concept however today I get to spill the beans… exciting times.

BuyReply is an idea I had last year which was born from the frustration of being an online retailer and realising that people spend most of their time in the real-world rather than in front of their computers. Whilst eCommerce is great, the reality is that only a fraction of consumers buy via eCommerce.

In reality our smartphone enabled population is spending less time in front of their computers as their mobile devices are now more powerful and capable than ever before. Traditional eCommerce only represents a fraction of overall commerce, around 6% in the US and 4-5% in Australia.

This realisation has led me to believe that one of the largest opportunities which exists in business today is the opportunity to bridge the online and offline worlds of commerce by unlocking revenue from exiting and engaged audiences in the offline world. This is the trend that Groupon rode and they became the fastest growing business in history. This means using eCommerce technologies ‘outside of the browser’ by selling to large and engaged smartphone enabled audiences such as TV audiences, magazine subscribers, newspaper subscribers, radio listeners, live audiences and more.

The platform we are announcing today is designed to to exactly this. We’ve created a new paradigm of eCommerce, one that is totally different to the traditional browser based “” model.

We’ve built an innovative and novel transactional platform that enables anyone to buy a product from any medium without requiring an app. All you need to do to buy is send a one word email or tweet and that starts a transaction. If you have a BuyReply wallet your payment becomes a one-click payment via text message. You can see some examples here. Advertisers can add a transaction point to any advertisement by simply displaying a call-to-action on a printed page, television screen, billboard, scoreboard or even sky writing!

Yes… you could sell from the sky with BuyReply… as long as you can afford the jet fuel!

BuyReply is easy to use and simple to understand but the ways in which it can be used in commerce are practically unlimited – and the ability to buy and sell using Twitter adds an awesome social dynamic to your advertising campaigns. You can learn how it works here.

I’d like to thank the readers of this blog and those who have been interested enough to keep in touch as the journey of BuyReply has unfolded. What you see today is the tip of the iceberg. We have an incredible amount of product roadmap to build and we are hard at work on this already. This is day zero of an incredibly exciting journey that we believe has the potential to disrupt the way that media is consumed on a global basis.

Our platform can span currencies and countries and we can’t wait to see how you use it.

We already have some amazing global brands signed up. Last week BuyReply was used by Sportsgirl and Oroton at the Mercedes-Benz Fashion Festival Sydney to sell the latest looks directly off the runway. We will be announcing some more innovative use cases over the upcoming days and weeks that will show you some of the great ways that this flexible yet powerful platform can be used.

Please read our BuyReply welcome blog to learn more!



P.S. We are launching on an invitation only basis so sign up here.

Going Agile

It’s been a while since my last post and I feel like I should have written a few more times since then however I’ve been pretty much flat out working with our team to prepare the finishing touches of BuyReply. We are going to be launching in two weeks and are putting the finishing touches on our product.

When we first started building BuyReply there were a few of us designing and developing and we weren’t all working from the same office. I wrote a 95 page functional spec and designed around 450 screens for desktop and mobile then worked with my developers to turn this into a product. We spent 3 months planning before we wrote our first line of code.

While we were developing to a functional spec it was relatively easy to know what everyone had to do, however we are now in a situation where most of the spec has been developed. We are working on tasks such as our deployment processes , continual integration configuration, testing processes and minor feature updates that will set the stage for our business moving forward.

It became clear in the last week that we needed a process that could be used to manage our team and ensure everyone is on task, productive and aware of what each team member is doing at any point in time.

The solution to this problem is to implement business processes that we adhere to with discipline on a daily basis.

After some research we’ve decided to start using an Agile development approach. Agile works by breaking work into a Roadmap, Projects, Sprints and Tasks as well as meetings called scrums, planning sessions & sprint reviews.

Agile components 

Roadmap - This represents our long term plans and includes high level goals that would extend over a 6-12 month period. It includes major product features. An example of this might be ‘building analytics functionality’ or ‘enabling 3rd party inventory integration’.

Projects - This represents short term goals that can be broken down into sprints. These are more clear requirements. Examples include:

  • Launching version 1.0
  • Building a web hooks module
  • Exposing our orders and customers API

Sprints - Sprints are the building blocks of Agile and should be 2-4 weeks in length. Projects are broken down into two week sprints that include tasks. Once a sprint starts we do not make changes to the requirements. The scrum master polices this.

Tasks - Tasks are work units that can be broken down into 1-16hr blocks that can be completed by a single person. Sprints are broken down into as series of smaller tasks. Examples might include:

User story: If I have multiple cards in my wallet I should be able to select the default card and if that card is not accepted by the merchant it should land me on a page where I can see a list of cards that the merchant accepts, and enter a new card.

  • Add a radio button that enables a user to select a default credit card in their wallet [3hrs - Adam]
  • Create a page that displays the credit card form [3hrs - Adam]
  • Test an debug this function [1 hr - Adam]
  • Acceptance test this function [1 hr - Dave]
  • Document this function & update marketing site copy to include this [0.5 day - Dave]
  • Update marketing site [2 hrs - Joanne]



Every morning we will get together at 9:00am in the meeting room for a scrum which lasts no more than 15 minutes. We do this standing up as that forces us not to relax and getting conversations that waste time.

Scrums occur away from our computers and each individual has to report on three questions every single morning:

  1. What did you do yesterday?
  2. What are you working on today?
  3. Have any roadblocks that have arisen that have cause the sprint to slow down, and what are they?

It is the role of the scrum master to remove roadblocks however this must happen outside of the scrum itself to ensure the scrum lasts no longer than 15 minutes.

In this meeting attendees are not reporting to the scrum master or product owner, they are taking responsibility for the tasks and committing to completing them.

There are three core roles of the scrum

  1. Product owner – this person represents the voice of the customer. They are responsible for representing the voice of the customer, defining user stories and what is going to be built. This person can also be a member of the development team. I am going to assume the position of scrum master as I have a clear vision of the direction of our product.
  2. Development team – Usually 3-7 developers working together. This team should be self organising and work together to get software built. The product owner (myself) can be a member of this team, which I am at this point in time.
  3. Scrum master  - This is a person who protects the development team from distractions and fends of external influences that might cause them to lose focus.

Sprint Planning

Sprint planning are 3-4 hour sessions where a 2 week sprint is planning and every task is broken down into a 1-16hr block. Work is never assigned to a person – you sign up for work of your own choosing based on what needs to be done.

Sprint Review 

This is a demo of the work done in the sprint. It is not a presentation. You need to show working software.


Product backlog

A backlog of functions and features that can be turned into a sprint. Think of this as a pile of sprints and we choose one, feed it to the team, get it done, then take the next one. We constantly pre-prioritize the product backlog.

Sprint backlog

This spreadsheet represents a list of new work the is still required, and the estimated hours require to complete this over a 5 day period.

Burndown chart

This chart represents a number of hours required over time and shows you how fast they are burnt down. It represents the velocity of work.

I’m looking forward to implementing this process at BuyReply and expect that we will be more productive moving forward because of it. We are weighing up whether to use TFS, Asana, Greenhopper or Trello to manage this process. Any feedback would be welcomed!

Enhanced by Zemanta