Q&A with K2 CEO Adriaan van Wyk: Why Disposable Apps could be the Next Big Thing


Q&A with K2 CEO Adriaan van Wyk: Why Disposable Apps could be the Next Big Thing

There’s an emerging trend around business process development called “disposable apps” and, despite the name, they’re not to be thrown away. As K2 CEO Adriaan van Wyk explains, they’re a mindset of an engaged group of companies building their own business apps for a growing range of novel, experimental and often temporary uses.

Q: When we say disposable apps, are we talking about particular software products or is this more a phenomenon that happens when companies get proficient at building their own business applications with K2?

A: Disposable apps are really a result of what we do: we build software that allows people to build apps quickly. K2 has Fortune 100 customers that take our software and build their own apps.  Wells Fargo, for instance, automates a lot of their business and banking processes using K2.  Kimberly-Clark Corporation built 400 business process apps that run within the organization and integrate with SAP, allowing them to run their business better.  But there’s a new class emerging who’s saying, “Wow, it’s so easy to build these things. I don’t just have to build them for something that’s going to run for five or seven or nine years; I can actually build them for something that I need for two weeks.”

Q:  So this is something that customers are taking into their own hands?

A: Correct.  It’s actually kind of interesting.  When you start making a wish list of problems to solve with disposable apps, the biggest challenge sometimes is to get people thinking outside the box and to keep them thinking that way.  That’s because they’re not used to being able to solve problems like this on their own.  So what happens is you start with fairly simple examples and as they start working from day to day, they realize, “Heck, it’d be nice if I had an app for this new issue or that problem.” And suddenly the list just explodes with all the things you can do within the company.  It’s actually quite an interesting exercise to go through.

Q: Can you talk about a use case or success story for a disposable app?

A:  We had a manufacturing client with a product design who wanted to involve their customers in reviewing some of the product features.  Typically, there’s almost no way to do that other than sending out emails and asking for their feedback.  But this company wanted to have an app where customers could take pictures of the product with their phone to point out problems and give feedback on features and how the product worked.  This was only applicable during a certain design stage and it came fairly late in the game.  So they used K2 to build the solution, ran the cycle and did it all parallel to the normal design process.  Close to 1,000 people participated in only about ten days and when they were done, they realized there were key elements of the product that needed changing.  So they made the changes before launch and ended up delivering a better product.

Q: Sounds like this was only possible because they could react in a very short period of time. 

A: Yes, and that’s just one example from the manufacturing section. Clinical trials and event management are other examples of situations where the disposable app approach can apply.

Q:  How should a company go about building a disposable app?

A: There are some very important differences in how to build a core application vs. how to go about building a disposable app.  When you start building a core, mission-critical application – for example if a large bank wants to build a new asset finance process – they typically start with deep analysis and design and eventually get to the point where they start building the application (which ends up taking the least amount of time). Alternatively, with disposable applications you start with the outcome or end result and work your way backwards. That’s because the way in which you solve the problem – the process, workflow and other elements –essentially evolve as a result of the problem that is trying to be solved.