Blog | Disruptware

Lessons From The Failure of Vinay Patankars First Startup Could Make Process.St The Next Killer SaaS

Vinay Patankar, the founder of Process Street, a new SaaS startup, discusses the lessons learnt from his first startup failure, why Process Street solves a big itch for any business that needs to scale. We discuss why its important to focus on product feedback and validation, get traction (new customers) and focus on the user experience long before you attempt to get funding.

Todays' Podcast Highlights

[2.10 - being in San Francisco really helps your networking]
[3.16 – Build your product and get customers before talking to investors]
[4.49 - Mistakes to learn from – not getting traction, team too expensive to scale, no UX testing]
[8.25 - Balsamiq is a great tool for building wireframes]
[9.20 - UX (User experience) is more important than screen design]
[11.22 – Used a pitch deck to get Tech co-founder on board]
[12.44 – Get a tech partner who believes in the vision]
[13.56 - Outsource WordPress site build, recruiting a content marketer and mobile developer]
[15.49 – Scratched my own itch with outsourcers]
[16.29 – Wanted a rich experience with creating SOPs]
[17.31 – Could not find another solution]
[18.16 – We want to make it amazing]
[20.00 - Step by step checklist with Rich content to support it]
[20.25 – Helps remove yourself from being the bottleneck in your business]
[21.35 – The Lean Startup should be at the top of your reading list]
[21.57 – Make decisions based on real user data]
[22.17] - Your startup is proven when you’ve proved your product market fit and your growth hypothesis]
[25.20 – We see Process Street going a lot bigger than just outsourcing market]
[26.53 – Master one niche first, then expand]
[31.40 – Using a lot of great tools gives you insight into good user experience]
[34:00 – Only put in features that are essential]
[36.18 – Never promise a feature timeframe]
[36.40 – Technical Platform]
[38.00 – For $125 per month we have an infinitely scalable platform that’s super lean]

Disruptware is building the largest community of software entrepreneurs on the planet. Make sure you are on the list.

Full Transcript

Paul: Okay. I'm really keen to introduce you guys to Vinay Patankar from Process Street. Now Vinay is just in the process of launching his MVP. He's in beta phase and Process Street is a tool to manage basically teams tasks as a productivity tool. So if you think of standard operating procedures and outsourcing, then he's really come out with an ideal solution for a real market need. Vinay, welcome to the show.

Vinay: Thanks for having me Paul.

Paul: Excellent. First of all, tell me a bit about yourself. Who are you and what do you do with Process Street?

Vinay: Sure. My background is a bit of a mixed bag. I'm originally from Australia. I've got a background in IT and sales, marketing business. I worked with software recruiter for a while as well as worked in technology and for the last four years I've been traveling as a digital nomad running an online lead generation company, launched two startups. Process Street being my second one and I've been working building Process Street products for about the last six months.

Paul: Wow! You're not actually based in the U.S, are you? You're based in Argentina, Buenos Aires?

Vinay: Yeah, we're currently in Buenos Aires. Basically the last startup that I ran I was in San Francisco and we went through an accelerator and didn't get the traction we wanted so kind of ended up shutting that down. When building Process Street, we thought, okay, we could stay in San Francisco or go to another U.S city or we could just go to somewhere that is cheaper and having a new experience of living in a different city, kind of like a semi-holiday if you will. But because we were just building the product, we didn't really need to be near any of our customers or anything at that current stage of the company. It was just about going somewhere that would be fun and a good experience and just giving ourselves like the time and flexibility to put our heads down and actually just focus on building the product.

Paul: Do you think it's really important to sort of be in the valley, be in the bay area to actually get investors on board?

Vinay: I definitely really think it helps. There's a huge difference between the environment of being in San Francisco or in the valley than being anywhere else in the world because just everyday all your interactions, you're surrounded by people who can either help your business in some way or know somebody who can help your business in some way. By just going to the local Starbucks or going out to a bar for a beer in the evening or whatever - there's just like always people around that kind of work in that same space and are interested in what you're doing or have connections to people that might be useful. Whereas, in all the other cities … most of the other cities in the world there isn't that same type of exposure. I don't think, I mean if you have an amazing product, attraction, sure you don't need to be in there but I think that just from the networking perspective, you're going to get more opportunities to pitch more people, so you can generate more leads by being in San Francisco than not.

Paul: Got it. I often tell people that nowadays, because software is a lot faster to build and develop it really does pay to sort of get your first customers on board and show some traction before you go out to the investor community and start scaling. How do you feel about that notion?

Vinay: I absolutely 100% agree. If you check out my postmortem on my last startup which was Vitoto and just type in 'why this failed'. That was one of the things that I talked about and that was a big reason for why my last startup failed, was because I went in too early trying to raise money instead of just putting my head down and focusing on the product. So I think that there's different stages of a software startup and I don't think that you need to be in San Francisco like right now when you're actually building your MVP. In fact, the cost of living in San Francisco is so high that I probably recommend you don't go while you're building your MVP and use the money that you would spend living in San Francisco on making your product better and once you get to a point where you have some customers, have some traction, you know then and you think that it's ready to kind of take to a new growth stage. That's the point where you consider going back into San Francisco or raising money.

Paul: Okay. When you did your first startup, you hinted at this about some mistakes you made. What, looking back, would you never do again? What could you tell sort of you know to our tribe or what kind of advice could you give them when they're thinking about building their startup?

Vinay: Sure. There was a number of things that I think we did wrong. One of the first things was, like you mentioned before, was not getting traction. It was … what I basically … and not getting traction came down to kind of I guess a planning error. What that was, was with our budget and planning like, okay, we're just going to get an MVP out the door and once the MVP is out the door, it's going to be awesome and then we're going to get traction and get money. That was a huge mistake in thinking that we really need a budget up till the MVP, because once we launched the MVP we were like, oh man, we actually have six months worth of iterations and learning from customer feedback to actually get this to a point where it can get traction and we didn't have the runway or the budget to do all those post MVP iterations that were needed and without the traction it was very difficult to raise money, so it was kind of like this catch 22 situation where you need the money to get traction, you need the traction to get money and that wasn't planned for from the beginning and that was one of the crucial mistakes.

That was probably the most crucial mistake and then kind of the things that tapped into that were, for example the team. Basically the team that I kind of put together for Vitoto was a very experienced team, but also expensive. There were two guys from Australia and they had a lot of overhead, more because … offices, stuff like that that needed to be covered and Australia is definitely not cheap to operate in either. So that kind of meant that our runway didn't last as long. We kind of didn't … we didn't do enough UX testing so that was another problem. We should have done a lot more kind of paper testing or mock up testing of users to make sure that the UX flow was great because without a strong UX it was very difficult to get the traction we needed and we learnt that after the MVP came out and after we'd kind of spent a lot of the money whereas we should have learnt that before, at the beginning, and done cheap tests. I think there's an app called POP. Have you heard of POP?

Paul: I haven't heard of POP actually, no.

Vinay: POP is an app that … it's an iPhone app and basically what it lets you do is draw mockups of software … of screens for an app. So you can have like this is what my screen is going to look like, this is where a button is going to be, this is where a video is going to be, this is where comments are going to be. Then you can draw multiple screens and then you can actually link the screens together, so you can kind of fake the experience of your app using POP and then … so they say like a great way of doing kind of UX testing is to … and this is something that we should have done, but we didn't … is kind of mockup your app using this tool and then walk around and get people to use it. You can actually do UX testing without even spending a cent on development.

Paul: Right. Actually … so it's essentially like a wire frame tool, but you can actually build screens and their clickable.

Vinay: Yeah, it's a clickable wire framing tool. You can link those together and actually give it to someone and say, “Hey, try and use this.”

Paul: Got it.

Vinay: Then you can kind of watch them.

Paul: What I use is Balsamiq, which is similar … it's very quick to build wire frames and you can link all the buttons and everything together, so it is very, very clickable but it's the stage before getting a designer involved. You can actually test a concept with prospects straight away even though it doesn't look pretty, but it still enables you to test the workflow and get feedback immediately as a validation as to whether this model is actually going to work.

Vinay: Yeah, and I don't think that looks are very important any more. On mobile apps I think they're probably more important, but I think design is a bit of a commodity these days. You have things like Bootstrap and you have themes and all that kind of stuff which makes design pretty simple. I think that the actual UX, the experience, like the flow of the app is much more important than whether it's got pretty colors or not.

Paul: Exactly. That's spot on. What other tools do you use when, you've obviously got a small team together for Process Street, what tools do you use to sort of communicate with them on your ideas and your concepts and so get that validated and in to code?

Vinay: For me, I … well, I live with my co-founder, who is my CTO.

Paul: So yes (laughing).

Vinay: We generally just shout.

Paul: That's one way of doing it, isn't it?

Vinay: We kind of shout across the living room. We do a lot of our communication just through Github. And the reason we do that is we try and keep it in Github, because you can actually attach your communication to the code itself. When there's an issue or an error that … or a bug that comes up or a feature that needs to go in, if we communicate that within Github, that can actually be attached to the code itself as like a comment or whatever and that kind of reduces the workflow of having to jump between two different apps for Cameron, for our CTO. He can kind of do everything just in one. That's kind of our main communication tool outside of the normal like phone call, face to face, Skype kind of communications. We'll go over things kind of at a higher level and then when things get locked down, then we'll put it into Github and use that as the kind of main way of tracking everything.

Paul: Okay, good. When you first had the idea, did you do any mockups or anything like that to explain that to your CTO?

Vinay: Yeah. The first thing that I did was … it wasn't so much a tech mockup, it was more of a product pitch deck, because I guess the difference was that Cameron's a co-founder. So this was actually another thing that … another lesson that I learned from Vitoto. It was actually that I definitely wanted my developer to be a co-founder. I didn't want them to be an outsourcer, because I've built software before with outsourcers and that was one of the issues with Vitoto was that like this kind of running out of runway. I wanted to keep it as lean as possible.

I wanted to find someone who wouldn't just like … oh, that's a nice piece of software we can build it. I wanted someone who actually believed in like the vision of the company and believed that it could be successful and was going to be more committed than just someone that you pay to kind of build something. Because 'A', like I knew that from my past experience you're going to get a lot of bugs, you're going to get a lot of problems and you're going to need to fix them and it's always going to take longer and be harder than you expect it to be and all of that costs money if you're paying someone.

You might budget six months, but every single project that I've ever done in software has always been over budget and overtime. Kind of taking that experience, I wanted someone who was on board and believed in the vision and was able to commit more than just … was willing to commit more than just the normal 40 hour work week and more than if the budget runs out it's like the thing isn't over, it's like let's figure out something. You know what I mean?

Vinay: Kind of that … I wanted that flexibility to be able to go longer than needed and to be able to make more mistakes, because I think that they always happen in software.

Paul: Of course and you know that's a very obvious way of doing it. You know working with a really, really good tech partner. Obviously the disadvantage to that is you're sharing your equity right from out the gate.

Vinay: Right.

Paul: But you're right in that you get buy in straight away and because of that your communication loop doesn't have to be strong either.

Vinay: Yeah, because you're working so close to that person, but I mean like Cameron charges $130 an hour, freelancing. For me to pay him for six months or even a year and a half or whatever it's going to take, it would be very expensive. That's kind of a trade-off of equity versus paying someone, right?

Paul: Exactly. Is it just the two of you at the moment or are you looking for someone else as well?

Vinay: Yeah, we're the two co-founders. I mean, I do have to have outsourcers to help with marketing and to help with like the front end, WordPress website and stuff like that, which is kind of all my domain, so Cameron basically just focuses on the actual app, the actual core products. And then everything else is basically me and outsourcers helping me get the rest of the business tasks done. So that's kind of the current setup. But yeah, I mean we are definitely looking to grow. I'm looking for a content marketer at the moment and we're going to be looking for a mobile developer in probably a few months as well.

Paul: Brilliant. So the product itself is a way of people who outsource a lot to create their standard operating procedures. Okay, so you're really simplifying the whole process and by simplifying it you're encouraging people to create more SOPs which of course is something that every company needs to do if they really want to grow and scale. How did you come across that idea - the whole concept? Why did you decide to go into that? Did you any sort of market research? Are there competitors out there in the market right now doing that and how did you decide that there is a niche worth going for or gap in the market?

Vinay: Sure. Another thing that I learned from my first startup. You know my first startup I kind of just built it, because I was like, “Wow, that's a cool idea. People will probably like this,” and I talked to some people about the idea and they were like, “Oh yeah, it's a cool idea,” but there wasn't really any validation. For this idea, the point that I started was from scratching my own itch. I have an online lead generation business and I work with a number of outsourcers myself and I was frustrated with communicating tasks effectively to them.

I was frustrated with being able to quickly create standard operating procedures. I was frustrated with repeated mistakes from my team and I wanted not just a way to be able to create standard operating procedures quickly, but I wanted a way to actually be able to track and see when and how those tasks are being done as well. So I needed a richer experience. And this was basically … I'm like this seems like a pretty simple product. Surely, there is something already out there. And I just couldn't find anything that had the experience that I wanted.

There are a number of document management systems, there are … you can use stuff like Google docs and there are a couple of … well, there's actually a number of SAP software competitors out there as well, but most of them use very old technology and they kind of structure it like a template document management. It's not very attractive. It's very old in terms of the tech and user experience was just nowhere near up to kind of what I come to expect from modern SaaS apps.

I'm looking for something that's like a Trello or like an Asana. That is a really smooth, easy, fast way of doing it and kind of all the products that I came across were clunky and slow and ancient. I'm like, okay, this something that I'm willing to pay for right now. I have my card out trying to buy something and I can't find a solution for it. That was kind of the point that I started from, just trying to fulfill my own need and through that I kind of said, “Okay, this is the opportunity,” and then I built a pitch deck and basically just started showing that around and gathering feedback and kind of went from there.

Paul: Brilliant. I've noticed in using the app it is really slick. You followed sort of the Trello style technologies you mentioned, in that everything sort of in the browser so it's very quick and interactive to use and of course you really focused on simplicity. which I really, really like a lot.

Vinay: Right.

Paul: What are your goals with the product? Where do you want to take it?

Vinay: We want to make it amazing. We think that right now, it's kind of a core product. The experience is getting there from the simplicity of the features, just to explain how it works with the people that might want to use it but basically what you can do is you can come and you can create a process template or a standard operating procedure template, and the way that we structure that is we structure it as a checklist, so you can put each task … say your checklist is doing a weekly newsletter, so the first thing is you've got to write the content, you've got to proof the content, spell-check it, put a gather on any additional things, the resources, you've got to put it into Mailchimp or whatever you've been using, you've got to schedule it and then potentially depending on who's doing it you might get a manager to review it and check off and make sure that it'sgood to go out. It's that kind of process that needs to be done each week to create a weekly newsletter for the company.

That basically it, it's a step by step process. Step one would be with the content, step two would be run your spell-checks, step three would be to load it into mailchimp etcetera, and the way that you can build a template is during the step by step checklist. What we've actually done is taken it a step further and allowed you to add in rich content into each of those checklist task items. If your task is add the content to mailchimp, inside that you can have videos and screenshots which … explaining exactly how you wanted to do it. It could explain what they should name a campaign and exactly how the text should be formatted or exactly how … or … what dimensions do you just need to be, and you can talk through it using a screencast and like demonstrate past whatever.

You can create this kind of very specific way of doing these tasks in a manner so that A, it keeps your quality high and consistent, so when people are doing it, each email that goes out each week is just the same or at least the same kind of structure formatting. B, it's documented in so much detail that if the person doing it ever leaves or is sick or wants to hand it over to somebody else or transfer to somebody else, then somebody can take over that job. It helps with training new employees, it helps with removing downtime, with people being sick or leaving and it helps you systemize and take a step back and remove yourself from being the bottleneck in your business.

Paul: Excellent. Now it's actually good. I think we'll put a link below this podcast as well so people can actually go and take a look at the product and at the moment you're in beta phase, aren't you? You're testing and you're looking for feedback from customers. You want more people to use it so that you can really really identify with it as a good fit, right?

Vinay: Yeah. That's basically how we're taking it. We're following a lean startup methodology for anybody who hasn't read that and is looking to create a software product, definitely highly recommend it as one of the top of your list books to read and basically they talk about just following this kind of lean development cycle where you get the most basic vital product as possible and instead of you trying to make assumptions of what your users want and need you get the product out and you start talking to our users and then you make your decisions based on the feedback that you get from your users. It's like you actually make a decisions based on real data. That's what we're trying to do; we're trying to get as many people on and figure out what the most requested features are … and what these bugs are and we adjust our products based on the feedback from our users.

Paul: Okay, brilliant. Now what is your traffic strategy? Once you get this live and you're ready to sort of really get people on board, how are you going to go out to market and actually get people to sign up?

Vinay: Yeah. It's a good question. From my learning from my last startup, there are two things you need to prove; you need to prove your product market fit hypothesis and then you need to prove your growth hypothesis. Once you've kind of proven both of those two things, you're at a point where your startup is basically to perceived this proven or validated and it becomes pretty easy to say raise money or get more traction. First that would be one, the other one is proving product market fit hypothesis which basically means is the product valuable enough that people actually want to pay for. That's kind of the first step. The second step is proving your growth hypothesis, and the growth hypothesis basically talks about can you get a good enough customer acquisition cost relative to your life time value of your customer.

That's going to be our next challenge and basically to answer that question, I don't know exactly what kind traffic strategy is going to work best but what we're going to do is run a series of tests across different traffic strategies to figure out which one is the best customer acquisition model for us. The things that we currently have been trying is content marketing, so getting a content marketing team, doing various different content. I know you have a product Kudani so just sort of testing out some tools like that and just rolling that back in the content marketing strategy.

Also with content marketing, we're kind of looking at doing some more advanced stuff, so doing re-targeting on content, pushing content views to kind of build the blog subscriber base using paid track sources and so we're targeting through Facebook or in Facebook ads, running Youtube retargetting, we're targeting at stuff like that. Beyond content marketing, look at just generic paid campaigns, so Facebook, Adwords, and then you mentioned this before, running ads on Freelancer, so I think that's a good idea as well.

Paul: Yeah, you need to sit around anyone who's outsourcing, so any tool, product that they … anything like that where people are involved in outsourcing. Another site is like the jobboards for the Philippines for example, all those job boards, they'd be perfect for that.

Vinay: Yeah, as I was saying, it's definitely a great … I guess that we want to start on outsourcing but I think going back to your question before I didn't answer properly, where do we see Process Street going, we definitely see it being a lot bigger than just targeting the outsourcing market. Already now we have a number of users and customers that run that space. We have patent lawyers that just like … they use it for every time they need to run through like a patent check. We have financial advisors in the real estate companies to follow the process. Like every time they need to get over documents for someone to close a deal on a house.

We have IT maintenance or infrastructure companies using it every time they needed to deploy a server, they run the process. Then we want to grab into for example mobile, so for building inspectors, people that need to go around and do inspection, run boarding, check the litter, check the piping, attach it, integrate it in the photos or stuff like that. We definitely see it as being a much larger product than just the outsourcing space but as the product is kind of built as a beta product, we don't have mobile, we don't have some of the more advanced stuff that maybe finance companies might need, so just parallel processors or like process dependencies starting … getting a little bit closer to the BPM space, but outsourcing is definitely a great place for us to start and get initial traction and.

Paul: I think you're absolutely right and I think the great thing with these types of products is being able to specifically target one niche and if you master that niche then you can sort of grow and target another one. I was at an event the other day and the one comment that came out of the event was like if you look at Facebook, what's Facebook's market?, well basically anyone with a face, but when they started, their market was just Harvard and all they did was conquer Harvard, and then once they did that then they expanded it to the other Ivy League universities and then after that they went after everything.

Vinay: Yeah. It's a pretty common story I think because it's like basically as a startup you don't really have resources to target everyone and also it's difficult to kind of get your messaging correct, and honestly that's been a bit of a challenge for us, is trying to figure out exactly which markets to target and kind of drilling down on our niche, and it's something that we still need to work on.

Paul: Cool. That's really good. Now obviously you're a software entrepreneur and you've got other businesses as well. How do you keep focused or how do you sort of manage your personal productivity? Because this is something that I get questioned on a lot because there's so much going on and we also have a bit from ADD. What tools or mind set do you use to sort of really get through your day and ensure you stay on track?

Vinay: Sure. I'm definitely a productivity tool for that. I use everything. I have … I use Asana, I use Trello, I use Workflowy, I use … Evernote, I use Street and yeah, we use Github for the software. I definitely use a lot of tools a lot to keep me on top and depending on what the task is and kind of what's going on, I'll use different tools. I can give you an example, so Asana I use for my lead generation business mostly. I honestly don't actually use it myself that much, but I have my team use it and Asana is great because it logs everything, so it's a way for me to go in and kind of if there's ever an issue or if I need to get data on a particular project or whatever, I can go in and kind of check that, but I find it's a bit slow to maybe use myself. Trello I use for content, so I find it great to kind of visualize posts as they're being created and guest posts and that kind of strategy. Workflowy I just use to organize my brain.. just to dump. I don't know if you … have you ever heard of Workflowy?

Paul: Yeah, yeah. Love its simplicity.

Vinay: Yeah, so I use Workflowy just about … I used to use Evernote for this, so just kind of dumping thoughts there I find that Workflowy has a much nicer structure just for tech ideas, and then I use Evernote for document management, screenshots and just trying to like clipping different sites and websites and everything like that, so just dump everything into one place that I can do searches on. That's what … I'm not a very like organized person, so tools like Evernote and Gmail, where I don't have to actually think about how I'm going to organize something, I can just dump everything I want into it and I can use search to find something quickly, are tools that I really like. Workflowy is the same kind of way. Even though there's structure in Workflowy, I still have only used the search feature because to me I'm more about like dumping stuff in and then recall it quickly without having to figure out where I'm going to organize what I'm doing.

Paul: Brilliant.

Vinay: Yeah, I use a lot of tools but I don't know if I'm probably the best person to talk to about productivity because I'm a bit of a mess on those.

Paul: Aren't we all, right? Cool. What would you sort of recommend for people starting up? What would you recommend as the best books to go out and read?

Vinay: If you're looking to build a software product?

Paul: Yeah.

Vinay: The lean startup up definitely is a great one and then it's going to come down to I guess what your experience is. For me … one great thing I find is … from being a very heavy user of a lot of kind of different tools and apps is that it gives you a great insight into user experience form a product perspective, but … I know there are a number of great design and UX books out there which I haven't really read that much. If that’s something that you don’t have much experience with then I think that UX is the most important thing. It really depends on the level of experience you have. There are great books from 37 signals and I've read all that stuff. They talk about … there's like their main book (about building basecamp) I remember it talks about like how they do it basically and they basically talk about kind of building a product without trying to look for funding.

They build it themselves, they focus on … they talk about how they do base camp in the first part, so they were a team of building the web consultancy and if you know they built Ruby on Rails and they have a base camp and a bunch of other really really really successful such products. They were a team during web consulting and they kind of used their web consulting business to generate revenue and then on the side as a side project they started building base camp and they didn't go out and look for funding, they didn't try and get it done quickly, they just thought like fun for that … fun the way it is, just making it better better better and never kind of about that stress of running out of money or anything like that because they already had a profitable consulting business and they just kept doing that until they got to a point where it was generating enough revenue and had enough users so that it could actually stop their consulting business.

Paul: Absolutely.

Vinay: That's part of the model we’ve taken with Process Street as well, so that then it's a lot lower stress and also like I mentioned before, there's so many unforseens with building software. If you're a first time software entrepreneur, whatever budget you put out, whatever like timeline you set triple both of those things. There are so many things you're never ever going to imagine that would come up that are going to come up and if you go, “Okay, I have 20 grand and three months to make this happen,” I would say it's a pretty risky position to put yourself in.

Paul: Yeah, absolutely. The book by the way is Rework.

Vinay: Rework?

Paul: Yeah, and some of the things that also come out of that that I really love is first of all saying no to feature requests because one thing that base camp is great for is simplicity and ease of use and that's all down to being really strong and resisting customer pressure and really only putting in the features that are really really essential and add value because it's really really easy especially in the early day to build feature after feature after feature thinking that this is what's going to make the product great, but in fact what makes the product great is the user experience.

Vinay: Exactly.

Paul: Okay, and that's the key thing right there.

Vinay: Yeah, there's a lot of mistakes people make around that. See, I think you want to keep it as simple as possible and the thing is you want to … especially when you're just getting it brought out. Don't hold back your release of your product because … and this is kind of a lean startup methodology, don't hold back the release of your product because your think you need todo this feature. Don't worry about it. The first versions of Twitter or Facebook, of every single product that you know that were out, absolutely horrible, don't even look like they look like now, and they would have never gotten to that point if they hadn't have released those products earlier on and gotten the feedback and adjusted their development trajectory based on the feedback that they got.

You want to get the product out as soon as possible, don't hold back extra features. When you do want to build the features, make sure that the features that you're selecting are the features that have been most requested by your most aligned customers. Ideally, customers are paying and if one person asks for one feature at once, don't go, “Okay, we'll do it.” Wait and make sure that a lot of people … that it's a kind of a highly requested feature so that you know that you're going to be satisfying a larger portion of your customer base versus just like one person who needs one thing done. Also, another tip, never ever tell somebody that you're going to have a feature done by a particular time.

Paul: Yep.

Vinay: Even if you know you're going to be building that feature, don't say, “Yeah, we're going to have it done in two weeks,” because you're probably not. Just say, “Yeah, it's out, it's on the roadmap that we're going to be working on in future.” Don't give a time because people are going to come back and be like, “Yo, it's two weeks, where is that feature?” yeah, and stuff for everything takes longer.

Paul: Yeah. The golden of rule there is always under-promise not over-deliver.

Vinay: Exactly. We're setup to scale, so we're on an Amazon EC2, we've got … so there's true servers for the products. There's like the API server which is like the core app server and then there is the front end server and they're both on EC2 using load balancers and then the databases are on RDS. It's all setup on infinite scale basically.

Paul: How much did that cost you?

Vinay: That … because they're all on micros, so not much $100 bucks per month.

Paul: Right.

Vinay: 100 bucks a month for all those three servers and they're only … so then like if they get 80% load, then they spawn new servers. That cost goes up if traffic goes up. Then we're hosting the wordPress site on Pressable which we used to … it used to be Zippykid. Pressable is really cool, you should check them out now and basically they're … it's scalable wordpress hosting, so it's like they manage load balancing, the RDS and a CDN content delivery network all for you, so like all parts of the product are on infinite scale basically. It's super cheap. That whole setup is like 125 bucks a month. That's like super lean. That's one of the huge developments that happened in technology in the last five years, right. For $125 a month, we have an infinitely scalable content like CDN delivered, like worldwide service app that about 10 years ago would have required a team of sys admins to manage and build back in the data center. Now for 125 bucks a month and whatever a week worth of config, we have an infinitely scalable platform.

Paul: That's really cool. Good stuff. Brilliant. Vinay, any sort of final thoughts for any of my tribe who are looking to either start software businesses or are in the process of scaling their SaaS businesses?

Vinay: Definitely that … software is definitely one of the most fun and rewarding things I’ve done because you build like … you're building a product in the concept of delivering real value. It's kind of different to people that might be coming from marketing or stuff like that where it's kind of building a product with a great copy so you can sell it. For us with our products it's been great because we've just been focusing on trying to build a product that will sell itself, so just trying to offer so much more value than what we charge. I definitely think that if it's something that you're interested in software is the fastest growing space in the world easily and I still believe software is at 1% of its potential as a whole industry. I think that innovation in software is going to accelerate and where software is right now it's only 1% of where it's going to be 100 years from now.

Paul: Brilliant.

Vinay: Yeah, definitely I think it's a great space but definitely make sure that you're prepared for the long run. It takes time and be prepared for things taking longer and costing more than you expect. Yeah, so I just want to say that I guess if anyone wants to check out our products it's free for teams of up to three people right now and you can get it at www.process.st.

Paul: That's great Vinay. I really appreciate you coming on the show.

Vinay: No worries. It's the best thing people.

How To Wireframe With Balsamiq

Video Transcript:

Paul: Hi. It’s Paul Clifford and today I want to talk about wireframing with Balsamiq.

Balsamiq is an online and a desktop-based wireframing tool. There are lots of wireframing tools out there. I want to just take you through the process really of just getting a wireframe done really quickly and just give you a feeling and overview of what Balsamiq and a wireframing tool is all about.

Just briefly a wireframe is essentially a sketch, okay? It’s like the visual drawing of what you want your app to look like. Just so you know there’s also a mockup, which is like then a more graphical view. That is normally done by a graphic designer. Then you have a prototype, which is like the final app but with no guts or engine underneath, and a prototype is obviously very clickable. These are often in a traditional design your app will go through these three phases.

When you’re trying to get an MVP or a minimum viable product out the door as quickly as possible generally you’d skip some of this work. What you really want to end up with very, very quickly is a working wireframe, which is somewhere between a wireframe and a prototype, so that you can actually talk to your market about what your product might do and get some feedback and validation before you go into hard coding.

Anyway, without going into that in a great deal let’s talk about what a wireframe process looks like using Balsamiq. Okay, this is just the Balsamiq desktop tool. Essentially you have like a workspace here at the bottom. At the top here you’ve got different elements that you can literally drag on to your workspace very quickly and just type in text what the words you want to be, and when you click away it just inserts it like that, okay?

You’ve got all your basic elements like lists, you’ve got menus, menu bars, you’ve got number steppers and at the top here they’re grouped. If you want to create an iPhone app for example you’ve got a lot of tools there to do that. What’s also nice is apart from drawing what the screen should look like you should also get used to putting these post-it notes around. These post-it notes are kind of diagrams to the developer or designer explaining your thinking or explaining what’s behind a certain feature or drop list or button or whatever. Okay.

Now the other thing about this is you can not only just draw these things, but you can input images as well. If you’ve seen an image say on the web or something that you want to represent or you want your design to represent then there’s no harm in just copying that image and just pasting it in. I just took an image of a chart here, because this is what the kind of thing that I want to be showing on my dashboard for my app.

This is kind of a very first early mockup really to clarify my own thinking about what I wanted my dashboard for an app I’m designing, what I want it to look like, okay? So what I’m going do now is I’m going to go into the online version of Balsamiq, which is called myBalsamiq which looks almost exactly the same but it’s got some new features around versioning and also sharing your design with your developer. Let me just flip over to that to show you what the process looks like.

Okay, I created a clean trial account just to show you this and what I’m doing is I’m just creating the dashboard of what you just saw earlier. I’ve created basically a widget area and the first thing to do is create a container to put my buttons in. Okay. First one, I’m going to drag a label across and just type some text into that and of course the widget title. There we go. Just position that and that’s it. That will do. Let’s grab … I need a field. There we go. Let’s just stick that in there. Okay, so there’s the label, there’s the field and where the content’s going to be typed. That’s where the widget title will go. Let’s start putting some buttons on the screen.

Okay, so this widget what I’m doing is I’m just going to create a widget that’s going to add content to my dashboard and there’s going to be different types of content. What I’m doing is I’m just creating three buttons to show what three different types, the three different widgets are basically. I’m going to put in an analytics one, a general one, a recent activity one and once finished you’ll see what it looks like.

The other thing you can do is with any button you can show within Balsamiq what state it’s in. In other words, whether it’s the selected button or not and it shows up in blue. Let’s put in the text for the next row of buttons. I’m assuming this is going to be when someone clicks on analytics then I want this second row of buttons to appear. Let’s put these in now. For analytics I want to get Google Analytics in, I want to get Facebook analytics; I want to put some Twitter and LinkedIn as well. Okay, these buttons look a bit odd so I’m just going to space them out a bit more. There we go.

Now again, what I think I’ll do is I’ll just make one of those buttons the selected one so in other words Twitter. Once Twitter is highlighted then I want the user then to be able to select the options for Twitter. The user will come in, they’ll type their title, they’ll say right, I want to create an analytics widget and within analytics widget I want to look at Twitter analytics. Now I’m creating the options for the Twitter analytics settings. I’m going to have two drop lists or combo boxes as they’re called and one will be to select an account. In fact, one will be selected channel and one which is basically a customizable account.

Don’t worry too much about the content or the meaning behind all these things. What I really just want you to understand is how quickly it is just to start mocking stuff up and it’s very much drag and drop. I’m not a graphic designer, but I know kind of what I want in my mind. All I’m trying to do now is just put that online so that I can communicate that to the developer, or even if you’ve got a bigger project then you might have a graphic designer who will take over in the next phase.

So then every sort of pop-up or button needs some sort of save and cancel or okay cancel. Let’s just put those in. I’m just going to copy and paste the same buttons and just be quicker. There we go. Cancel. Okay. There we go. That’s like my add widget pop-up and what’s really cool now is obviously I can preselect that, but what I can do is link all these buttons to other screens and I’ll show you that in a second. Let me just save that as we’re going through and watch this.

I’ve highlighted the save button and now I’m going to link it to my dashboard overview screen. Okay and I’m going to do the same thing with the cancel button as well. There we go. Okay. What will happen is when the screen is live you’ll be able to actually click on it and this is one of the things I really like about this tool. Okay, let’s save that down. You can see I’ve got two other mockups in there. This is my main dashboard screen. Okay.

Now within the dashboard, the main dashboard screen I’m going to link that to my pop-up I’ve just created. There’s the add widget. Link it up. I’m just linking it literally to another screen in Balsamiq. Okay, nothing fancy at all. I’m just going to link the settings, so got a little settings sort of cogwheel type thing on every widget, which will also if you click on the settings I want that to pop-up to the add widget screen. Okay. Let’s save that down and then let’s give it a little run through and you’ll see what I mean.

So here we are, click on add widget, you can see how the cursor changes to a hand. I click on that now and up pops the add widget screen, okay? I’ll click on the save so it changes to a hand and it goes back to the dashboard screen. Click on add widget again, there's my pop-up. Click on cancel. Okay, so that’s all well and good. Now let’s see what it looks like in real life. So this is how its comeback now and you know this is obviously a working code. There’s my analytics widget, there’s my Twitter and click on save or cancel then it’s going to take me back to my main dashboard.

Okay, so I think you can see that’s really powerful and with the online version there’s lots of features for collaboration. So basically you can have your developers in here as well. You can discuss or chat over the design as you’re going through. The project asset screen is for adding images and outside elements into your wireframe. The other thing that’s really cool here is you can actually look at the versions. As a design evolves then obviously the versions are going to change. Each change you make is all stored and logged progressively and you can scroll through and see everything that’s changed throughout your whole design.

I think it’s a really cool tool. It’s called myBalsamiq. You can get the desktop version or you can get the online version. I think the online version is the way to go if you want to share things with your developer. Obviously, there’s a monthly recurring fee as it’s a SaaS product. Okay and that’s Balsamiq.

Recommended Resources:
1. Balsamiq - http://balsamiq.com/
2. myBalsamiq - https://www.mybalsamiq.com/

How To Accelerate Your Software Project

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi. It' Paul Clifford from Disruptware and today I want to talk about accelerating your application with ready-made code that's already done for you.

Now at the very basic level you've probably heard me talk about PHP as an example programming language which you can use. Well, together with PHP you can also use PHP frameworks. And those frameworks are things like CodeIgniter, CakePHP and one called Yii and a whole load of others. What these frameworks do is they provide a lot of the legwork for building these applications and they handle things like database management, caching, permissions, internationalization. Often they provide something called CRUD. CRUD stands for 'Create, Read ,Update and Delete', which is basically the four essential features that any sort of object or person within an application needs. PHP and frameworks are great ways to accelerate your application.

Another thing you can look at is on the user interface side using something like Twitter Bootstrap. Twitter Bootstrap again is another framework for implementing user interface. What's really cool is it uses a consistent language and consistent templates to enable you to do that. And so not only does it really look great, but it's also easy to maintain and build upon in the future and instantly you have a very up-to-date modern looking application just by implementing that framework alone.

Lastly there's one other way, which you can accelerate your application and that is by looking outside of those consistent commercial frameworks. That is look at the Open Source World. Look at open source applications or modules or tools that might perform part of what your main application needs to do.

For example, perhaps you want to include an editor in your application, well, there are companies out there who provide Open Source versions of the editor. But what they also do is they can license that to you commercially. For a small price you can actually buy a commercial license to use their code in your application. So you get full ownership of it, but your leap frog a big module of development which you don't have to do yourself.

Other places to look are things like CodeCanyon and CodeCanyon is a big library of ready built modules and applications and frameworks which you can buy and license directly from the developer and build that in to your application as well.

I hope that's given your several ideas and methods that you can use to leap frog and accelerate your development and get it out to your customers as soon as possible. This is Paul Clifford from Disruptware.

Recommended Resources:
1. CakePHP - CakePHP
2. Yii PHP Framework - YiiFramew ork
3. CodeIgniter / EllisLab - CodeIgniter
4. Twitter Bootstrap - Twitter Bootstrap
5. CodeCanyon - CodeCanyon
6. CKEditor - CKEditor

What Is The One Word That Causes Projects To Fail

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi. It's Paul Clifford from Disruptware and I want to tell you about one word that stands between you and a software disaster. That word is communication. Now, essentially, let's look at just four examples throughout the development process where software projects go wrong and it's all down to this one word.

Firstly, in the design, what a lot of people do is to submit a design to a freelancer or oDesk or something like that and they select a developer and off the project goes. They're surprised when they get something back, which is not really what they wanted. So the first thing that went wrong there is that the developer didn't communicate back to you or basically the questions. You must have questions coming back, because no developer is going to understand your design and just go off and do it. The more questions you get back, then the more that validates that the developer really understands your design.

Secondly, when you're actually selecting someone for your implementation, make sure you interview them. It's all too easy just to do everything via your email, but doing interview at least via Skype chat so you can actually establish your rapport. Now, establish a set routines of when you will communicate and ensure that they are understanding what you're saying, because it's all too easy especially in the global economy when you have people in India, China, Russia, wherever for miscommunications to happen and that's where a lot of this goes wrong. So make sure you interview the developer before you select them.

When you're in your project and you have a conversation either a Skype chat, or anything like that, often these chats can go on a long time and what is essential is that you record that either through voice or at least make a bullet-pointed list of what's been agreed. And ideally, you should be using some sort of project tracking or task management system like Trello at the very basic level and put all the bullet-points on what's been agreed in there. So that you both have a really good understanding of what was discussed and what the next steps were.

Number four, ensure that you are hearing from your developer on a daily or weekly basis. Obviously, it depends on the length of the project. If it's many, many months, then weekly basis might be fine, but if it's shorter project or shorter module, then make sure you're talking to them on almost daily basis or a minimum every other day, because as soon as that breaks down, then things start going wrong, and then three weeks later you try and communicate with your developer and you find out he hasn't started it, or he's been sitting there, or he's on some other project, or he's disappeared altogether. You need regular consistent communication with them and that way then you can be assured that he is working hard moving your project forward and you're getting any questions, you're able to deal with any problems really straight away.

The fifth thing, is just to understand why developers sometimes don't communicate back to you, and often it's because, in a way their embarrassed, they have a problem and they don't have the solution and the thing is you know, you could probably work around any problem that comes up. And between you - you can find the solution, but when the developer has it on their own, then they can really struggle and instead of coming back to you, and this is often the cultural thing, instead of coming back to you and saying, "Hey, I got a problem. I can't solve this." Often, they'll just go quiet and you can lose weeks of time that way.

That's why it's important to be on top of it, hear from them every day, check on progress and see your code and your project developing really, really nicely.

I hope you found that useful. That's Paul Clifford from Disruptware.

Recommended Resources:

1. oDesk - https://www.odesk.com/
2. Skype - http://www.skype.com/
3. Trello - https://trello.com/

Growing Your Business Using APIs

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi. It's Paul Clifford from Disruptware and I just want to talk about the four ways of increasing your revenue and growing your business using APIs.

Now an API stands for an 'Application Programming Interface' and essentially all it is - is a way of two different applications communicating with each other. Essentially it's something you should incorporate into your SaaS model if you're building an online app, because it's a really a great way of growing your business. You can do this in four different ways.

4 Ways To Use APIs:

1.      To get new customers.
2.      Charge for usage.
3.      Content syndication.
4.      Increasing the consumption of data or service.

First of all, you can use it simply to get new customers and you do that by sharing your API with another Cloud application or another SaaS app and integrating the two and of course the partner who you've integrated with, they'll communicate to their customers that they're integrated with you. So you're going to get a slice of their customer base and the reverse is true as well.

Secondly, you can just charge for usage of the API. So if someone has some other tool that they want to access the same sort of data that you're giving away in your API then you could just charge them based on usage. So charge them based on clicks or queries or the amount of data transferred. There are lots of different ways of doing that.

The third thing, is content syndication and this is what newspapers do. Newspapers and news organizations, they publish content and they're dependent on users consuming that. They will provide APIs to consumers and to second tier news organizations so that they can get more people reading their content, get more traffic, more clicks and of course more revenue.

The fourth thing, is just generally increasing the consumption of your data or service and it's something that for example Amazon will do to their current customers. They'll ensure that there's lots of different ways of using their API to grow the usage, because of course at the bottom within Amazon they charge based on storage and usage and that's what they want to increase. So providing as many avenues as possible for customers to use their service, increases their overall revenue.

So, I hope you find that useful, that's four ways of using APIs to grow your business and this is Paul Clifford from Disruptware.

Recommended Resources:

1. Amazon Simple Storage API Documentation - http://aws.amazon.com/documentation/s3/

How To Design

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi, it’s Paul Clifford from Disruptware.

In today’s session what we’re going to talk about is how to create a design. It’s the most common question, “How do I get that idea out of my head and into the head of my developer or my technical team?”

The key things to understand here is that the more time you spend in this process then the less cost your overall project will be. I know in a way that makes sense, but literally if you spend more time in the design process, just yourself mapping it out, then you’ll spend less money on your development, your communication, your changes, your bug fixing, your testing, everything like that because you would have thought through a lot of issues that your developers will come back with and a lot of issues and bugs and things would already be taken care of. It’s really worth investing some time in this process.

3 Things You Need to Know:

Persona (user, client, administrator)
Wireframe (picture of what's on screen)
Use case or use story (interaction)

There’s three essential things you need to know. First of all, define what’s called a Persona. A Persona is basically a description of your user. So what type of users are you going to have for your system, are they just going to be administrators, clients...what are their roles and rights? What interaction will they have? Will they have access to everything? Will you limit them? Will you have different license restrictions around certain people? Will you have power users in the system? You just need to define what type of users you have and their called Personas.

The second thing then is you need to Wireframe. A Wireframe is essentially a picture of the screen. You could just draw that out on paper to start with or even a white board - I use this a lot. You just map out and draw on screen what it’s going to look like. Draw your forms, your labels, your buttons, lists, all that sort of stuff. Draw it out on screen and make sure it’s logical. It makes sense.

Once you’ve done that process then transfer it to a wireframing tool. A wireframing tool is a tool that is a bit of a design tool, but has a lot of the widgets all built-in. The thing is if you want a button you can just drag a button in, if you want a list, you just drag a list in and basically enables you to build the screen really, really quickly.

With these tools what you can also do is link screens together. If you build a wire screen of your login screen then you can link login buttons for example to the next screen within your wireframe. So the whole wireframe starts to become alive. When you go through this whole process then you’ll start to really understand how your application can work and you could even then at that stage take it to someone and show them and communicate it really easily. You can even take it to a customer and get their feedback to make sure you’re actually building an application that is actually going to sell.

The third thing you need to know is Use Cases or User Stories as their more commonly used within the leading start-up world. Basically, what all this is describing is the interaction between your users, or your personas, and the screens. So behind every button, behind a list, behind any action that you want a user to take you just need to write a couple of sentences on what result when the person clicks on that what’s the result in terms of the users eyes.

Basically that’s it, your three factors. You’ve got your Personas, your Wireframe and your User Stories and when you put those together and map that out on your wireframing tool then you really start to get a design that makes sense not only to your technical team, but also to you because remember the more time and the more effort you put into this whole process then the less cost and the less risk your whole project will be at the end.

I hope you found that useful. This is Paul Clifford from Disruptware.

Two Recommended Wireframing Tools:

1. Mockingbird - https://gomockingbird.com/
2. Balsamiq - http://balsamiq.com/products/mockups/

How Do You Know If Your Business Model Will Work

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi, it's Paul Clifford from Disruptware and today I want to talk about your business model. How do you know that what you're building or your idea is actually going to sell?

Okay, and it's the crucial thing that you should be looking at right from the start and I'm sure you are, but how do you actually know? What sort of questions can you be asking yourself and your prospects to understand whether anyone's actually going to buy your solution.

Well first of all, the core things you need to know are; does it save time, does it make money or does it replace an existing process. If it saves time then what's the value of that time? Because if the value of that time is not really big, then it's still not enough for them to actually buy it. So think about are you selling to a lawyer or are you selling to a school, okay? So think about the value of the time, whether it's enough for them to actually put a hand in their pocket and buy your solution.

If it's solving a real problem, how much of a pain is that problem to them? How much does it really stand in their way of their doing their everyday job and how can your solution actually solve that pain? Then look at some more general factors, is it a trending market? Is it growing? Are there a lot of people in the market and a lot of customers? Are there enough customers out there who are willing to buy your product? How large is it? Does it scale across different boundaries, different countries? Is it global or is it just in one region?

Unlike a traditional business, a software SaaS business you don't have to worry about the supply so much. So traditionally when you're asking yourself these questions one of the questions you should also ask is do you have enough capacity to deliver? Well in this case that doesn't really matter so much because being an on-liner, you can scale to thousands of thousands of customers and by the time you actually want to or need to increase your server capacity, well that's a good problem to have.

Look at your business and try and identify the key factors, is it solving the customers problem. This is something that 'The Lean Startup' which is a great book by Eric Ries talks about. And he talks about how quickly can you get your product out to market. And even before it becomes a finer product, can you take like a prototype or something you know just... even a manual process to a customer and try and identify whether it's enough for them to actually commit money to.

Get his book. It goes into a whole load of different paradigms and methodologies, but it's essential reading for anyone building a SaaS model and essentially it's all about getting what's called your minimum viable product out and tested in front of a customer as soon as possible so that you can validate from them whether the thing is going to sell.

I hope you find that useful, this is Paul Clifford from Disruptware.

Recommended Resource:

1. The Lean Startup - http://www.amazon.com/

How To Reinvent A Better Wheel

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi, it’s Paul Clifford from Disruptware and I want to talk about reinventing the wheel, or reinventing a better wheel.

The fact is a lot of people might have an idea and they want to go out and create an app, but they’re put off by the fact that someone else might have done it. So in other words, they haven’t got the ground breaking idea that no one else has ever had. The reality is that not a lot of people and a lot of businesses ever come to market with something completely groundbreaking, completely new that actually sells.

The key things around this is what a lot players and a lot of the most successful companies have done is that what they’ve done is they’ve taken an existing idea, an existing model and simply made it better. Or what they’ve done is taken it to a different market, or had a different approach, or a different delivery mechanism. These are the things that you should be looking at when you’re trying to work out what my new business should be.

Stay within your knowledge area, so something that you know something about in terms of the market and model other businesses. Look at other people who are doing similar things and all you got to do then is work out how can I make this better, how can I take this to a new market, can I take this global, can I take this from the enterprise space to the small to medium business space, can I take it to consumers? All those different things are options and angles which you can take on an existing idea. Never go into a market where there are no competitors, where there is no one there, because chances are that there’s no one buying in that market.

Think about all that. Reinvent a better wheel. You won’t be the only person to have done that. If you look at some of the biggest companies out there like Google, like Apple, they’ve all done it. Google wasn’t the first search engine. They just made the existing web search that Yahoo built they just made it much, much better. Look at Apple. Apple didn’t invent the MP3 player, the iPod. The MP3 players were out and about, but Apple went in there and revolutionized that space.

Think about all those things. Don’t be the first to market unless you know there’s a market there, and there’s competitors there. When you’re doing all that and factoring it in think about what your exit might be. If you’re going into a market where there’s already a big enterprise player perhaps you can build an app for a small to medium business with an exit in mind to sell it to players in the enterprise space. These are the kind of things you should be thinking of, or should be thinking about. Don’t be afraid to reinvent a better wheel.

This is Paul Clifford from Disruptware.

Which Language

Video Transcript:

Paul: Hi, it's Paul Clifford and welcome back to today's session, which is all about what language to use. What language should you actually use to build your online SaaS app? There's loads and loads of phrases and languages that you would have heard of and in fact when I last did a count there's like 309 different languages in technology which you could use.

So how do you know? Now, if you go to any developer, they will have their own opinion. If you look on the web, there will be tons of different opinions and it can be a mine field, so let me just look at the key things that you should be looking at.

Now, first of all, the factors to consider...

1.      People Cost
2.      Speed of Implementation
3.      Ease of Maintenance

Number one, the people cost. How much is it going to cost you to build your application? How much are the people? And how much do you have to pay them per hour or per project if you get a fixed price? What is the speed of implementation, so how quickly can you actually get your build into operation? How quickly can it get up there and get customers using it? Of course ease of maintenance, once you built it and you got it out there, what about bug fixes, new features, customer requests? Everything that comes in, how quickly can you put those into action? So, it's ease of maintenance.

Now those are the three, but there is of course performance. How quickly the language functions in itself and that sometimes is worth considering with online apps. All the languages, the key languages I'm going to discuss today are pretty quick. Unless you're building like a rocket ship or the next shuttle or something like that, then don't worry about that too much.

Types of Languages...

1.      Open Source
2.      Compiled
3.      Scripted
4.      Object Oriented

The other thing to consider is what types of languages are they? First of all, are they open source? In other words, can your developers get using these straight away or do you have to buy licenses for them to actually code in these languages.

Secondly, are they compiled or are they scripted? A compiled language, once it's written, then needs to be turned into something that should run physically on the machine, and once it's compiled, it's very, very quick. When it's scripted and it runs in a scripted form, then it can run slower. But because it's scripted, it can be quicker and easier to make changes especially when you're working on the fly.

Lastly, is it object-orientated? In object-orientated, what's important about that is that it helps the ease of maintenance, so if it's well-structured and well-organized, then it's going to be easy to maintain moving forward.

Once you've understood those key things, then what are the choices? Well, I've just picked out the top six if you like. The top six that people will discuss if you talk to them in a conference or something like that or when you talk to a developer. I want to give you the tools and the languages and the technology understanding to know what you're talking about so you can have an informed and considered conversation.

Languages for consideration...

1.      Ruby
2.      Python
3.      PHP
4.      Java
5.      C++
6.      C

Now, the main ones considered are Ruby, Python, PHP, Java, C++, and C. Now generally, as a general rule of thumb, C and C++ right at the bottom here are more used for real time sort of applications. So like I said, building the shuttle, building something that needs to run really, really, really quickly. If I score all of these languages in terms of performance, speed of implementation, getting it out to your customers, ease to maintain, ease of maintenance slope, cost to bug fix, et cetera, and availability of skill.

Then if I factored all those and I look at those, then first of all if I look at performance, so from the slowest to the fastest, Ruby is probably one of the slowest - Ruby and Python in between them, then comes PHP, then Java, C++ and C. As I said before, those two at the bottom, C++ and C are the fastest and that's why they're used when building missiles and controlling aircraft and things.

If you look at the speed of implementation, in other words, how quickly can a developer build something and get it out there? Putting aside the knowledge of course, then Ruby, Python are the fastest to build things, and then comes PHP, and then Java, and C++ and C which take longer to actually build applications with. Then, if you look at the ease of maintenance, again, because Ruby is quite quick in terms of implementation and it's well-structured in object-orientation, then Ruby sits at the top along with Python, and then PHP is probably the easiest to maintain, to get started, and then of course you got Java, C++ and C, which get harder.

This is probably the most important thing. If you consider all of those languages, which one has the most programmers and this is where it's really important to get, to make your decision based on your first factor here which is people cost, because basically, new technologies and fewer people mean more cost because the new people with the new technologies they cost more. That's the thing. If you've got something that's been out there for a long time that are stable and there's a big community of developers, then it's going to cost you less to actually put into action.

If you look at availability of skill, the most available is PHP because it's so common especially for web. It was designed for the web and if you do any searching on any outsourcing site, you'll immediately see the most volume of developers in the community with those skills, and then it goes sort of PHP, then C, and then Java, C++, but Ruby and Python, not many of those around. They're quite new languages. I mean Python replaces PHP in many ways. It's a great, great language and developers would love it and the same with Ruby, but the people are in demand. There aren't many around, so when you look at all the factors, really PHP is a great choice to go for.

This is Paul Clifford. I hope you enjoyed that. Sign up below and get more hints and tips into your mailbox.

What Is SaaS And Why Is It A Great Business Model

Podcast: Play in new window | Download

Video Transcript:

Paul: Hi, it’s Paul Clifford from Disruptware, and I want to talk about why the SaaS model is growing in popularity at the moment, and why it’s such a great business to be in.

First of all, from the customer perspective, remember that any customer buying into your service recognizes it’s a very low risk. Basically they’ll use it for a month and if they don’t like it they can leave, which means that customer acquisition is a little bit easier then it is to try and get software onto a customer’s desktop.

Secondly, remember that there is no installation headaches, so there is no IT to worry about. All they’ve got to do is just log in and they are up and running. Thirdly, they can access it anywhere, so from any country or whatever as long as they have a web browser then they’re taken care of. Because it’s a recurring revenue model then the long term value that customer’s worth quite a lot. You can make the entry price reasonably low to get them in - to get them hooked in.

Remember software is a service, which SaaS is basically a rental model. You are renting use of your software to them, where as traditionally it used to be a perpetual model where they would have to install the software but they would own the license. Where in this case you’re renting it to them and you’re taking care of all the IT for them.

Now from a vendor perspective, or from your perspective, why is the SaaS model great? Well, first of all it’s one application you have to maintain and support, so it’s got quite a low overhead. Once it’s developed and built then most of your cost is really on the marketing and getting the customers in, but in terms of the operation it’s a lot easier to support and maintain than a traditional software business.

You’re also selling to the end user, the people that are actually using it, and you’re solving their problem directly. You don’t have to get IT involved, or deal with any of the installation headaches, or compatibility with their desktops, or with Windows, or Macs, and all that other stuff. You don’t have to worry about that as long as they can access it and access the web then they’re up and running.

Remember the SaaS model is a recurring model and that the subscription model is built in, so all you’ve got to do is focus on growth and get as many customers in as possible using your application as much as possible too.

Lastly, it’s all about the valuation, and should you choose to go down a sale route, an exit route then you might be focused purely on how much can I make my company worth at the end. Valuations are directly related to growth. If you look at all the IPOs, trade sales, anything like that and look at the valuations they’ve achieved it’s a direct correlation between the valuation and the growth rate of the company not the profit. It doesn’t matter how profitable your thing is. What really matters is how quickly you can get customers on board and build your revenue as fast as possible.

Okay, so I hope you found that useful. This is Paul Clifford from Disruptware.