Webinar: Solving Business Challenges with Custom Web Development

Pete: Okay. Thanks, everybody, for joining us. We had some technical issues there. For some reason, I don't know why. The "Start broadcast" button is pretty important. We need to have it to be able to do anything. I had to boot a couple of people. I see a couple came back. My apologies in advance.

Let's get right into it. Hopefully, everybody can see a screen, and we're going to go through a quick presentation. Our topic today is solving business challenges with custom web development. What is custom web development? We're going to be talking about that. We're going to be going through an entire agenda of items. First, we're going to get into what that agenda is. We're going to through some introductions, talk about what's custom web development, talk about benefits. We're going to talk about the process of actually building customized software.

We're going to go through planning, building a spec, choosing a technology, budgets, timelines, development, testing, deployment. We have a lot of stuff cover in a short period of time.

I have someone here, who I'm going to introduce in a second. We're going to go through some case studies, and then get into a conclusion. This is me. This is Peter Czech. I'm the CEO of the New Possibilities Group, founded the group in 2001, co-founder with the gentleman sitting to my left. What we do: We specialize in highly customized design and development of web apps and content management systems, which is pretty much how we came up with the topic at hand.

Sitting to my left is Kris LaGreca. Go 'head. Tell everybody about yourself.

Kris: Oh, this is Kris, VP of accounts for New Possibilities Group and also co-founder. I usually come into play with discovery sessions, which we're going to talk about, and helping the customer translate business rules and requirements into actual system processes.

Pete: Cool, thank you, Kris. A little bit about us and our experience, here's just a list of clients that we've worked with. We've been in business since 2001, when we co-founded the company. Kris came up with the name. It's a very optimistic name, so good job, Kris. Since then, we've been working with a variety of different organizations, small business, enterprise-level business, building custom web applications, websites, and obviously custom content management systems.

Getting right into the topic: What is custom web development? Basically, in a nutshell, it's the use of technologies to build customized software for solving problems, in our scenario specifically, on the web.

What isn't custom web development? Hacking off-the-shelf software to get close to your goals. This not an elegant solution. I've traveled around the world, been to India, China. I wish I took a picture of this myself. This is basically what every telephone call around the India, China area looks like. This is basically what hacking off-the-shelf software results in. It's kind of a mess. Maintenance-heavy and frankly, not that attractive, not the way things should be.

Just to explain a little bit more about custom versus off the shelf, basically today, the internet is inundated with off-the-shelf platforms. On the CMS, content management side, we have WordPress, Drupal, Joomla. If you were on the last webinar, we talked specifically about these particular platforms. From an e-commerce perspective, we have Magento. We have OSCommerce. We have Prestashop. I've kind of focused on open source stuff here. We'll talk about that in a bit.

Then there's tons of niched software packages out there for forums, news, magazine sites, community, specialized e-commerce, software as a service. There's tons of platforms that are out there. These are all things that are off-the-shelf. This is not what custom web development is all about.

Just as an example, to look at one particular area, content management systems. This is just the hottest content management system list of this year. These are all the different platforms that are out there. These are everything off-the-shelf. You can see, I think, there's 30 different players right now, but there's, in reality, hundreds, some going back many, many years.

The reality of the whole web development situation is that these off-the-shelf solutions, they're never made for you in particular. These are generalized tools. They're meant to apply to many different scenarios. They're not specific to you. One thing that we like to say is that when all you have is a hammer, everything looks like a nail. There's a lot of clichéd images I'm going to have today, just so you know in advance.

That's a reality of the situation. Anything that you take off the shelf, anyone who says they can customize it specifically and perfectly for you, it's not really truthful. They can't get it all the way where you want it to be. One important thing to think about is your impact zone. You can get any of those platforms 90% of where you want to go, but that last 10%, that functionality they can't take you to, that's your impact zone. That's the area where you’re going to differentiate yourself from all of your competitors.

Again, we use the example here of content management systems. We build an awful lot of them. They're very good at taking you to that 90% mark, but again, where's the value? What do you do differently? What's your differentiating factor? What's going to make you different than all your competitors? It's going to be in that zone of influence, which is the impact zone.

What is the better alternative, in terms of web development and platforms? First off, instead of using all those platforms that are out there for CMS or e-commerce or anything else, you have, building on top of a coding framework, a framework that takes care of things that you don't need to worry about, like session handling and form handling, features such as that. Things that a coding framework brings to the table, but don't build on top of a platform which automatically you have to do things the way that they do it.

Number two, figure out how to integrate your complex business requirements with day-to-day tools that you build for yourself. If you do it the right way, you're going to look at your processes and build tools to do what you need it to do. You're not going to change your workflow around the tools. That is one of the things we see all the time. People take a WordPress, or a Drupal, or a Magento, they build on top of it, but then they have to change their workflows because the system is different. That's not what you should be doing. You should be trying to find a way to take your system, today, your internal business logic, your workflows, how you actually manage things like inventory, or reservations, or whatever it might be for your particular application, and building a system around that. With that, comes freedom, power, flexibility, and eventually, cost savings.

Also, the better alternative, determine what your system's going to look like by actually going through a process of discovery, a process where you build out a spec based on how you would absolutely want your application to work. This is something that's super important, and as opposed to taking a platform off the shelf, putting it together and then building as you go. Always work through an architecture, and Kris will talk about this in a little bit. This is what he specializes in.

A great analogy is modular versus custom homes. I actually saw someone in my neighborhood do this. Kris, I don't know if you saw that, but they were bringing in parts of a home, and building this home up on a hill. They would crane it in. It was actually pretty cool to watch, but that home is not 100% for anyone. You pick from a pre-determined list of modules. If you want to have a special room, a special feature, it's not something you can do, whereas the person on the right, here, is building a house from the ground up with an architectural blueprint, building with the materials that they're specifying, building it from the ground, up. In this scenario, who gets 90% of what they want and who gets 100%?

What are the overall benefits of custom web solutions? Number one, it's made specifically for you. Again, you're going to make very few sacrifices. Number two, there's longevity here. If you build a platform the right way, it'll last for a very long time. Off-the-shelf software has a bunch of updates that you need to perform on a regular basis, a bunch of upgrades. You can't predict it. You don't know when it's going to happen. There's a cost associated, and you never know for sure if the upgrade from a massive version X to version Y means you're going to have to build over. With a custom solution, you're not going to have to worry about that.

Also, scalability, not just in terms of traffic and volume, and things like that, but scalability with your business as well. Is your business going to get larger? It's going to handle more and more items that you're going to sell, or reservations that you're going to handle. With a custom system, you can be much more in tune with when you’re able to scale, when necessary. Don't forget the value. There's no value, if you're ever going to sell your business, to having it build on WordPress and hacked together. There's zero value. In fact, you'd become a liability, but in a lot of ways and a lot of cases, with acquisitions that are happening on a regular basis, and we see this with customers, the system that we build actually becomes a valuable asset. This is something that you have to consider.

Finally—everyone always disregards this, I don't know why—but security. By having a custom platform, there's many more steps that we can take to secure it above and beyond industry standard. With off-the-shelf software, by the time you get all the hacks into place, it's very, very, difficult to be absolutely ensured that you're secure. This is why we always say, when you're doing complex e-commerce, do not go and put it onto a hacked-together piece of software. Taking something like WooCommerce on top of WordPress, you're just introducing so many layers of vulnerability. You definitely have to be careful, and consider.

By the way, during this, anyone has any questions—Kris, you included—feel free to interrupt with any questions. What I'm going to do at the end is open it up to Q&A, again.

What are some real-world examples? We're going to do a demo in a little bit and show you a few, but here's just a top-level of some of the things that we've seen in the past. One is a long-term car rental company. They need an e-commerce site, a front end, and they also need a reservation management system, all tied together in one platform. Kris is going to walk you through that.

Another is a worldwide yoga training company. He's going to walk you through this, as well. They have class management, e-commerce, content management, all into one platform that they can build on. We built a foundation for them, so there's going to be two examples. Another that we have, which I'm not sure we'll have time to get to, we have a lot to cover. We have a furniture client who has a complex integration to an antiquated old inventory system. They're not in a position to move off the inventory system, but they need a way to integrate to it, plus have content management and inventory management all in one place. That's an example of something that we've seen.

Another situation, and you'll see each one of these is complex in that, if you took something off the shelf, you'd be taking it just a little beyond out of the envelope that it's been designed for ... A private college system, they needed a content management system to use by various personnel in 15 different physical locations, in a secure fashion, with a special workflow for approvals. There's pretty much no CMS off-the-shelf that will do that.

Finally, a healthcare provider, who has maybe ten different domains being run in one singular CMS with a pretty complicated lead generation mechanism.  These are real world examples.  The best way to determine if a custom solution is right for you is to think about, if you have something off the shelf, will you be extending it beyond the comfort zone? Each one of these is a "Yes," to that question. That question might be something you may not be able to answer yourself. We're going to talk about discovery and all that good stuff, and how you can get the help with experts to be able to tell you.

Never ever, ever… This is super important. Never do these types of projects with something off the shelf ever. Highly secure CMS platforms. It's very difficult to be able to secure content management systems. If you need something, if you're a professional security company, if you're in the financial services, if you need a secure CMS, I do not recommend anything off the shelf. Kris is nodding, so I think I'm saying the right thing.

SaaS software. The product here—the business is the software, so I don't know why anybody would ever take something off the shelf and think that they could sell it for licensing. It's not feasible. It's not recommended. That 10% impact zone with SaaS software is pretty much your whole business. Never build something off-the-shelf for the purposes of licensing it.

Complex custom e-commerce, products with a lot of options, with a lot of configuration and customization. Also, security reasons. If you have that type of scenario, you might want to consider going custom. The platforms out there like Magento, who's the industry leader, who—it's owned by Amazon. It's owned by…

Kris: Ebay.

Pete: Yeah, Ebay owns it, very good for thousands of SKUs in a normal e-commerce store, but let's say, you have ten items of a high cost with a lot of customization. There's no reason why you'd want to use a Magento for it.

We're going to talk about the custom process, and how we actually go through this. I'm going to take a breath. I'm going to let Kris just do the top level. Go through the list.

Kris: Yeah, so when it comes time to approach a project, don't put the cart before the horse. In that instance, where you find a solution, you think that's going to work and then you hack it together. Before you know it, you've got a hacked-together solution, and you didn't really satisfy business requirements. Always start at the beginning, which is: What is our business requirements? What's our roles? Where are the constraints? What third party's telling us that we have to implement certain features and functions? Get that all down. That's all part of planning.

It's like, in using the house analogy, the architecture phase, where you've got blueprints of the house. That's the specifications, so in the house analogy, you're just saying you got three bathrooms, five bedrooms. They're located like this. You want to use this type of carpentry in your kitchen. Well, the same thing applies to software, where you want to make sure you don't just talk about the major workflows, but also the minor workflows, the alternates. What happens if someone isn't successful at checkout? Can you offer them an alternate workflow? All of those things, that onion needs to be peeled. You have to get to the core of the business rules, the logic and the rules. That's all part of the planning and specifications process.

From there, now again, a good shop is not going to dictate a particular solution just because they're experts on it, but the solution that's best for you in those requirements. Again, putting the cart before the horse, let's understand what the rules and requirements are, and find the best solution as far as technology. Do you need MySQL? Or if you're going to be doing a lot of database queries and searches, maybe a no-SQL database would be better. Again, the technology should match the requirements for that project.

Once you've got that all blueprinted and architected and outlined, then any shop can come up with a budget and timeline as far as what to expect, as far as costs and how much time is needed for development. Once the project kicks off, you are in the development phase, which includes design, additional architecture, and the actual building of the system in the background. Testing's always taking place throughout the process, but again, testing is separate in that, at the end of the project, all those workflows that were described in the specifications become the test bed and the test scripts for the final project. That's how you know a project is successful, is if it meets those requirements and rules that were outlined at the beginning.

From there, deployment schedule: depending on, again, what kind of project is, if it's cutting over from an existing site or a brand new site. All those things are taken into consideration. Your marketing budget and plan; all that unfolds in that you get the best chance for success.

Pete: Cool, thanks. That's a good overview, but I am going to dig into each one in a little bit more detail. In terms of planning and strategizing, this is step number one, obviously the most important thing. Important to remember, you can do this, to a certain extent, yourself. You have to analyze: What are your current limitations? If you already have a system, you're doing a re-development, what are some limitations? If you don't have a system, think about what could a possible scenario be where you could get stuck in a corner?

Think about things like that. Think about the three things that you could be doing to save you time and effort in administrating your business. A big part of these projects are always going to be building a back end that's going to be flexible and be able to do those different tasks to save you time and effort. Think about lost opportunities, both on the front end from a sales perspective, lost opportunities on the back end, from a perspective of administrative management. Think, if time and money was no object, what initiatives would you pursue? Because these are the things that, when you do discovery and build a spec which is the next step, these are things we would be asking you to already have. This is sort of your homework. This is something that you can do because you know your business and your goals and objectives better than anybody else.

Going into step two—building a specification—I can't emphasize this enough, this is the most important part of the project. You would not build a house without a blueprint. A pilot does not take off without a flight plan. Without having this, you are destined for disaster. Do not go through this step by yourself. Find someone qualified, someone with a technical background who can help do this. This document needs to be more tech-focused, so you definitely want somebody with a little bit of experience to help you.

What do you plan for? You plan for—we call them the system actors, the people that use the system on the back end and the front end. Think about how those people are going to behave, the tasks they're going to perform, the tasks being the use cases. What exactly is it that they're going to be doing? Think about the risks and opportunities. What are the risks of the system? Maybe there's a security risk that you have to worry about, or maybe there's a risk in terms of how one part of the business extends to another, but think also about the opportunities.

Also, think about where you're going to go in the future. What's version two? What's it look like in six months, two years, five years? Because you're going to be making an investing and building a foundation. If you're not thinking about the future, you could waste the entire first project.

An important thing: When you do this spec, it's going to allow you to compare vendors. You can compare guys like us against other guys, and you're going to have an apples-to-apples comparison because you're going to have a technical document. That's why this is so important. You can compare budget. You can compare timeframes. You can compare approaches and technologies, but you can't do it unless you actually have this document in place.

Kris: To add on to that, in the last slide, he mentioned that you can start this process. You do have an idea. In using the analogy again of the house, you have an idea of what the house, in general, you want it to look like, and how many rooms and bedrooms, but by no means are you an architect in where you can definitely plot out all the features. That's where you need the expert to help you in this part of the process, to actually help sketch all that out.

Pete: This is a really important point I'm bringing up here, whether you work with us or another agency or whatever, always pay for this separate of the project. A lot of agencies are doing what we call a discovery. Other people call it different things. Pay for this as a small project to do at the beginning to: A) get that spec that you get to keep, to get that architecture in place, but also to get a sense of what it is to work with an agency. It always amazes me when people come to us with a failed project and they've signed a significant contract with an agency that didn't do a discovery. It's like, "Well, how did you know what you were going to get?" You're pretty much setting yourself up for failure. Most places now are willing to do this. We definitely recommend getting it out of the way.

After that, once you have your spec and your discovery, that's when you start to talk about technology. It's a very important factor to consider. It affects the cost. It affects your future. This is something that you can't just think about it secondarily. You have to really think about how the technology you're going to choose is going to affect you. That might be hard for you to be able to evaluate. One thing I would say, don't always trust the pure tech guy. The thing about software, in general, is that it's moving at a very fast pace. A lot of technologies come and go. The pure tech guys are early adapters. They will be very quick to jump on a framework or a platform that might just be a year old or 18 months old. The thing is, what they're not going to tell you that in another year, they're going to jump to another platform and you're going to be stuck.

You need to find someone who has a good business sense, someone that's been more of a role where business logic kind of combines with technology. For example, what we use—this sort of goes to the next point. We work with open-source software, software that we build with—I've been using it since 1999. Obviously, it's been getting better and it's been iterative, but it's the same core concept from 1999. It's the same type of software. In that time, I probably could think of 50 different frameworks that have come and gone. Sometimes, I see people that built something a year ago that automatically already have to look at rebuilding just cause they picked something that was hot at the time. Back to my second point, find yourself someone who bridges the gap, again, between business and technology, and they will lead you in the right direction.

In terms of open versus closed source, you have to do a little bit of research about this. In terms of open source, what we use is an open-source platform which is called LAMP, which is Linux, Apache, MySQL, PHP. Kris alluded to that. Open source is basically maintained by a community, which is okay with core software such as that. Closed source would be the alternatives put out there by companies like Microsoft.

Kris: .NET.

Pete: .NET, for example, or SQL server. A big difference in this, it's kind of like a Mac versus PC, a Canon versus Nikon type of debate. Technically, enterprise-level organizations work with Microsoft a little bit more, simply because they like having the guarantee of a company being on the other side. If you'd look, more and more places are embracing open source, especially a lot of the start-ups that you probably work with or are a customer of already.

New versus tested platforms, I kind of already talked about this already with the pure tech guy. One of the ones that we get a lot of requests for is Ruby—Ruby on Rails Platform. This is something that the pure tech guys love. I love the language. I think it's great, but in terms of actual real-world case studies of people building ongoing concerns using that software, it's not something that I would recommend. I consider that to be more of a new type of platform. That's something to consider, and of course, like I said, future, future, future. You have to consider where you're going to be. People that went under Rails—and I forget the version, I don't know if they're up to three or four—but I remember that either from two to three, or from three to four, it was such a massive upgrade that I met a guy who started an agency just to rebuild everything because everybody had to build everything again. If you're not considering that in the beginning, you're going to pay for it later.

Kris: Also, adding to that, again, finding the agency with the business sense, because while Ruby on Rails may be technically an okay solution for a particular problem, the cost of a Ruby developer is sometimes 50 to 100% more. There are budget issues that can come into play, even aside from the technology, that you need to consider and take into effect. A good agency is going to help you through that process in understanding the long-term costs, as well as the short-term.

Pete: Definitely, definitely agree, especially when you look at the enterprise software versus some of the open-source stuff. I mean, the people that are using enterprise, you heard it, it's enterprise, so why smaller businesses ever choose to go with the Microsoft stuff, I don't really get. The talent pool is smaller and they expect to be paid 100% more, something to consider.

That's a good segue into budget. When you're thinking about budget for your project, just remember, proper discovery will mitigate your budget risk. Most agencies will be able to guarantee you a price if you have a spec that they either built or they agree with. Again, it all goes back to that first step: discovery, discovery, discovery. Always plan for overrides, just in case, to an area of 5 to 10%. Again, we've had great success over here, maybe 99%, in terms of keeping within budget for people that have done discovery.

I want to talk a little bit about popular terms for payment and milestones, something to consider as a customer. You have to think about, what are the milestones throughout the project where you're going to see significant progress? That's really how you want to structure your payment with an agency. Think about an end-of-a-design cycle, end-of-a-development cycle, maybe presentation of an Alpha. This is something where you definitely have control through the process of beginning a project. It's just something to think about.

This is really important: ownership scenarios. There's two ways to do this. There's a new way that's getting a little bit more interesting, but the first one is your typical pay-for-hire. You do a project. Make sure, if that's what you're doing, that you, as the customer, own it at the end of the day. A lot of agencies are going to go and not even kind of mention it, but, "Hey, this is built on something and we retain the license to it." You really have to protect yourself and make sure you're an owner.

The second scenario happening a lot more today is actually leasing of software. We're seeing it more and more. I believe that, not the majority, but a good part of the projects in 2017 and going forward, are going to move to a lease model. Leasing, to me and the way that we look at it, is that it's a combination of an initial project, plus continuous improvement. You will continuously have help from an agency, as opposed to just doing a project and be set out on your own. It's an interesting type of financing. There are ways to handle ownership. You can still have the ownership in that type of arrangement, but don't be surprised if you see more and more of that out there as you go about coming up with a plan for your project and how you're going to pay for it.

One thing, too, always try to have a plan for the deployment and where you're going to host your project before it is over. You don't want that to be at the end of the day, and you're like, "Oh, I didn't even plan for this. I don't know if this host I picked supports it." Make sure you're ahead of the game on that, because that's something that we see, kind of, catch people at the end.

On to development. Oh, this one popped up all at once. I didn't do my cool little animation there. Like Kris said, when he did the intro to the whole process, discovery is your blueprint. Always refer back to that throughout development. If there's a conflict about what you're building, if you're not sure of this or sure of that, look back to what you had and what you planned. Don't pivot, unless it's absolutely necessary. Because your pivot, it's kind of like the butterfly effect. A pivot at the beginning of the project can affect everything all the way through. Try to stick with your discovery. Try not to pivot.

Technical debt. A great analogy for technical debt is the picture I showed you guys before, of all the different wires hooked up. That's pretty much exactly what technical debt is. It's just adding, adding, adding to something, and it's getting more and more out of hand. Again, referring to discovery, not pivoting, that's how you're going to avoid building this technical debt. Eventually, that debt will be an issue. Throughout the development, be testing. Any developer that knows what they're doing should be able to show you progress on a regular basis. You should have a dev link from pretty much day one, so always stay on top of it, and pay attention. Pay attention to what they're doing at every single update that they have with every milestone. Don't lose track of what's happening.

Finally in the process, testing. Not finally—there's one step after this, but testing and QAing. Again, again, again. Again, rely on discovery. That's going to help you know if the goals have been accomplished or not. Test early and often, as I said. Throughout the whole process, continuously test every single function that's delivered to you. Having multiple set of eyes, have someone else that can help you that knows about the project, whether it's another consultant or somebody else on your team. Make sure someone else is there, because it's very easy for you to get caught up in the process of pivoting and building technical debt and moving off the focus, that sometimes, someone else is going to be, "Hey, snap out of it."

Finally, you're going to own this, so you have to live with it. Consider that the whole time. Every decision you make, remember: future and where you want your business to go.

The final step, there's always deployment. Always aim for 100% seamless so that one day, you could flip a switch, if you have an existing app, that the old one can just take over. If you are transitioning, try having a second environment running. Have the new system running at the same time, in tandem with the old one. That'll let you sort of work through any of the kinks before it's actually a completely live environment. That'll help you get to that seamless transition.

Develop a deployment script, so that you're planned, and you know, "These are the list of things we need to do to make everything seamless," and make everything work as you hope. Schedule around company initiatives. If you're a company that has a seasonal business, don't plan to do a deployment right before. I'm amazed at how many people come to us and say this, "The busiest season is February, so we want to push January 31st." That's crazy. That doesn't make any sense. Get through the busy season. Get your project live after that. I think that that's a much smarter way to actually deploy something. Learn a little bit, and then fix any challenges or iterate the site a little bit, before your next busy season happens.

Then we're going to dig into some case studies. I'm going to turn the chair over to Kris in a second. Just to go through the bullet points of this, and then I'm going to turn it over to Kris. Each one of these examples relies on their website to bridge the gap between the internet and their business. Each one utilizes the internet for the majority of sales, and each one of these was previously on something off-the-shelf. With that, Kris.

Kris: All right folks, so the first one I want to show you is Autofrance. That is a reservation system for long-term Peugeot car rentals in Europe. They came to us—this is, what, 2013?

Pete: No, more.

Kris: It's older than that. That sounds like just a short while ago, but in reality, that's a hundred years in computer time. Now, we talked earlier about having to keep constantly up-to-date, and security issues with stuff that's off the shelf. This core system, it has been relatively unchanged. They've added features throughout the years, but it's the same base framework that we built for them in 2012. Even the design hasn't changed. The only security issue that came up, I think, over the span, has been a server-related security hole that we needed to patch as an emergency, but nothing to the actual framework.

If you consider the cost just in savings of not having to do constant updates over this period of time, we've saved them thousands and thousands of dollars. What we've built for them is a custom solution for reserving vehicles. Now, there's a ton of complexity here, but it's hidden behind the scenes, so that the customer has a really fun and quick experience in reserving a vehicle.

Pete: Let me just interrupt and give a quick plug for what these guys do. Basically, their business is, if you're renting long-term vehicles in Europe, you can pick it up—and this is a free plug. I hope you guys, if you have a long-term rental, you can pick up at multiple locations, brand new Peugeot cars. These cars, literally, are right from the factory. You can rent them for anywhere from, two weeks, I believe. Was two weeks the minimum?

Kris: Mm-hmm.

Pete: Up to many months at a time. Pick it up at a variety of different places, drop off at different locations. I believe there's only one or two companies in the United States that are resellers for this program. If you're wondering how they do it, well, the government of France actually, I believe, subsidizes Peugeot a little bit, which I think is pretty interesting. With that, Kris, go 'head.

Kris: They have issues on both sides where they want to create a really seamless, fun experience for the customer, with having to support all these rules and complexity, which I'm going to show you shortly, but also on the Peugeot side. Peugeot comes in and then says they have to have all these kinds of specials and support all kinds of pricing rules. Nothing off-the-shelf would allow them to do that. This custom solution allows them to satisfy all those business requirements, so simple fill things from the front end. For example, we have the mega-menu here. We're showing two different locations. All this is data-driven. They just manage the data in the back end, and it builds these menus automatically, same thing for vehicle models and where they build this nice little preview for vehicles, just by the hover over.

Again, they don't need to manage a menu tool that you'd have to have in CMS solution off-the-shelf. Rather, we just pull that data from existing records and setups so it makes their life a lot easier.

Just to walk you through a possible reservation, right, so let's say I want to reserve a vehicle for January 1st. I'm going to reserve for the 31st. I'm going to choose—there's lots of locations I can pick up and drop off my vehicle.

Pete: We really should've went to Italy. It'll be a little bit warmer.

Kris: I can, again, view all sorts of different vehicles, let's say, to 2008. I'm going to get a quote. At this point, I can see details about the… Again, there's a whole bunch of rules, which I'm going to show you, that go into the pricing model here. Let's say I want to order this now. Again, their conversion point, here, is to get people to register. There's a lot of steps to his reservation, which we made easy by having the steps show up one at a time, from their flight information to their credit card information. We got to this checkout really quickly and are able to walk through that final step, but in the back end, is where the real magic happens.

You saw that I reserved a particular vehicle from two different locations at a certain timeframe. Behind the scenes, there's all sorts of logic dealing with exchange rates, locations, different pricing based on not only the location, but different times of the year. They can set up different pricing that adds or subtracts to the overall cost of the reservation, then the vehicles themselves. Just to show you a little preview to this, this is… If I'm going to edit that 2008 vehicle, again, this isn't something off-the-shelf where you have to kind of figure out how to use a field to make it work for what you want it to do. All of these fields were dictated by the client's needs.

Again, they add in the information, here, add images. We've got a nice little tab interface, can be rearranged just by dragging and dropping, so a very easy interface to use. You can see here, there's a whole bunch of sub-models. That can be turned on and off. They can even be turned on only for admin use. For example, if they're going to take a reservation over the phone for a very exclusive model, that can be available for the admin to do over the phone, and not on the front end. Again, being able to support all sorts of rules. Again, dive deeper into any of these data features, here. For example, being able to change rates, not only for the first 21 days of rental, but what is the per-date price after 40 days and after 90 days? Again, all this complexity, they manage easily in the backend, and is relatively hidden from the user on the front end to create a really good experience.

Pete: I can just break in again. I remember when they came to us, they were using a combination of Excel, Access, and then a hacked-together website with something off-the-shelf. We were able to save them tremendous time by creating this platform. Not only can customers come and make these reservations, but then they can do it, like Kris said, as an admin as well, so their whole business is actually controlled via this interface. There's nothing of value they have to consider in terms of time savings.

Kris: The other thing to consider with custom solution, or any kind of software solution, is you have the front end which you expect the public to go visit and then gauge your business, but in these two examples, there is a real-world telephone call experience, customer service experience, that needs to be able to be supported. What we have here is the ability for the customer service to go in and manage reservations, make changes on the fly, update the credit card, attach documents, make additional payments. Something that you rarely see on off-the-shelf solutions, is to be able make fractional payments towards a larger purchase.

Pete: What was the integration for payment?

Kris: Well, it started with Authorize.net. Now, they're using Braintree. Again, being able to support changes as they grow and their business changes without having to reinvent the wheel. In this case, I can go into this user, and I can see details about this user, if I need to update it, their passport information. Also, document, so this also has a PDF generator. Once a reservation's finalized, Peugeot has a really complex requirement for their documentation. We were able to take their PDF form and break into an actual, fillable electronic form. Again, whatever requirement they've had, both on the customer side and from Peugeot's side, we'd be able to help guide them through that.

Pete: In the interest of time, maybe we'll move onto the next example, so we're really cruising here.

Kris: Yeah, so YogaFit. YogaFit is a worldwide yoga training and certification tool. This, again, another old one from like 2013. They were using a SaaS e-commerce platform. I think was a .NET e-commerce platform, which the company hacked together to do reservations. Now, it worked, but it wasn't able to take them that last, in this case, more like 40% of the way. Again, we built them something from the ground up that really took into account their entire business model. Again, from the front end, it's really easy user experience to find a training and to register. Again, they're conversion point is to get people to register.

I can go learn about this training and see details and pricing, and go right to "Register." Then I have a really nice, clean checkout experience, which again, I'm not logged in, but I can very easily log in if I have an existing user. Notice that I don't have a "Create an account" interface because it's something you see very frequently in off-the-shelf platforms. They'll have a "Create an account" checkbox and you'll have to put in your name and password. In this instance, we want this conversion to happen as seamless as possible. The UX and the UI have to be absolutely spotless. In this case, if they're not a customer, we'll simply create an account for them behind the scenes when they check out and send them a password, eliminating steps in things that can get in the way of that conversion.

Again, it was a relatively easy experience from the front end, but again, where they magic happens is in the admin. Again, they have an entire customer service staff that will take reservations over the phone, and have to manage reservations.

What you see here is an ability to filter and find an existing order from this list. I can add a new registrant. Again, the customer calls over the phone, they have to go and find that customer. Maybe they don't catch the full last name. They only catch a couple letters, but they can enter that in. They'll get a list of customers, and choose which one they want to fill for that order. Again, the customer says, "Well, I'm looking for a training that is this month." Also then, the customer service enters that information in, and they can walk them through over the phone, "Okay, well how about this level two training?" And you simply add it to the order.

Finally, if there are any discounts or coupon codes being applied, what customer service is actually taking that order, and they can either see their order as a draft or process that order. It's got to be quick. It's got to be easy, because the customer service employees are coming and going. You don't want to put them in front of a complex system and have them not be able to fulfill an order. With a custom CMS solution, we just follow those workflows that are needed to get the job done and don't have to worry about extra fields and data and things that aren't important to that workflow.

Another interesting, which a lot of off-the-shelf solutions don't take into consideration, is reporting. Yeah, there's your business workflows and getting that conversion, but there's also people in charge of the business that want to know the health of the business, and how it's doing. You don't see this in off-the-shelf solutions. What we do, is the ownership comes back and says, "Well, I want to know about 'X, Y, and Z.' I want metrics and reporting on 'this and that.'" What we've created is a special page just for the owners to look at a snapshot of the overall health of the business. Here, I've got the events taking place this month, and a little graph showing the capacity as far as how we're doing in getting registration. Instantly, they know how well each event is doing, who's registered.

Then, we've actually created graphs to show the health of their business based on different metrics. In this case, we used a jQuery script off-the-shelf. This is something that we integrate. We'll always find ways to integrate something if it's already built, instead of having to reinvent the wheel, but this is a great example of using jQuery graphing tool, and then able to even compare from year to year, how the business is doing. Again, the ownership wants to see nice, pretty, graphs, and we can absolutely satisfy that need.

One more thing I want to show you-

Pete: One more.

Kris: I'm really excited about it. I love this stuff. ... That is, managing end users and segmentation. They like to use MailChimp for mass emailings, but a lot of times, you need to segment. That's what differentiates one company from another, is ability to really fine-tune their marketing. What YogaFit does, is they say, "Well, we want to find the users within 100 mile radius of a certain zip code who may have taken or not taken a training, who have placed an order and not placed an order," whatever the needs are, they want to be able to segment a certain group of users, and send them out a mailing. MailChimp is a great tool, and we're not going to reinvent MailChimp, but the problem with MailChimp and other email tools, is that they do have segmentation abilities and workflows, but it's only as good as the data that lives in MailChimp.

You can maybe segment from state or zip code, but you can't segment that existing list in MailChimp by what they've ordered or other complex rules. Whether they've used a coupon code on checkout, for example. What we did is, instead of trying to get that data and somehow make it work into MailChimp and then have to manage it in two places, the data lives here, on their website. This is becoming their CRM. The data's here. The actual great solution here is that we've given them advanced search features and ability to drill down. Again, the date that their user was created, a timeframe from when they placed an order, or they actually attended a training, if they're part of a special group, and then again, if they've taken a training or not taken a training.

I can do an advanced search within our custom CMS solution, and then I can actually send this list to MailChimp. It's called a segment in MailChimp. What will happen is that they'll have a pre-created segment, that all they need to do is then attach to a campaign. Instead of trying to build and refine the list in MailChimp, they do it here in the CMS because this is where the data is. This is a great example of when to leverage partners, and other solutions, and APIs. Again, it all comes from the business needs, and being able to satisfy that.

Pete: Cool.

Kris: Yeah.

Pete: I'm going to take the seat back. Thank you, Kris, very cool stuff. I mean, I would like to see somebody be able to do that with something off-the-shelf, exactly the way that we were able to do it for these two customers.

Real quick, let me just bring this back to our presentation here. We're almost out of time. First off, if anybody has any questions, send it along. I got a couple gathered up, so we're going to do that in just a second. Going back to the case studies here, real quick, if you're interested in a live demo of anything, call me. That's me on vacation. I used this the last time I needed another picture for my… That was me in Greece taking a call from somebody, because I'm always on the phone, so definitely don't hesitate to call.

While I wait for any questions to come in, we're going to do another webcast. It's going to be “Planning for 2017; Website Redesign Tips & Tricks.” We're going to do it December 21st. It's going to be at 2PM, again. This is going to be a little bit more design-centric. We're going to talk about design trends. We're going to talk a little bit about content management systems. We're going to be doing that on the 21st of December, at two o' clock. That should be a lot of fun. Maybe we'll pull in one of artists for that one.

Additional resources, if you have the time take a look at our blog. We have videos. We have a great video up about discovery, so definitely do that. We have a lot of ebooks that you could download. We talk specifically about things such as this. We have a great one about our CMS solutions, which we put out last month. Feel free to go and download that.

In terms of how to find us, NPGroup.net. We're located about 15 miles out of New York City. If you know New Jersey, go out the Lincoln Tunnel, ride straight, and you get to us. With that, two questions that we're going to answer really quick and then let everybody go.

Number one, "Why not do the discovery ourselves?" From Liz. Kris?

Kris: Yeah, so that's a great question, Liz. The issue, again, using the house-building analogy, you have an idea of what you want the house to look like. Maybe you have a particular faucet and particular features and the general size of the house, but you're not an architect, and you wouldn't want to assume to be one, right, where you measure things wrong, and then all of a sudden, the house is a disaster. You leverage the experts. In that case, you hire an architect to help you build the blueprints. That's the same thing you want to do here. You should approach the architect. In this case, you should approach an agency with your general ideas and your business rules. Then they're going to help you continue that process, and drill down, and again, things that you wouldn't even consider, but that the agency has experience with dealing with exceptions and alternate rules and workflows. Those are the things that they're going to help you uncover.

Pete: Cool, and we have one more. This is going to be a tough one to answer actually, but it's possible. "How can you plan for the future, in terms of technology, when it changes so quickly?" I mean, you know what, you really have to look at the past a little bit, I think, to predict the future. Like I said, take a look at some of the frameworks that have come and gone over time, but look at some of the things that have been stable. Again, we build with LAMP. The reason we do that: PHP has been around since the late '90s. Linux has been around, based on Unix for a very long time. These are stable platforms: Apache, MySQL. If you have to go an enterprise route, the Microsoft stuff, it's fine. It's just more cost-prohibitive. You have license fees, but that's also a very good solution, so take your cues on the future by looking at the past a little bit, and you'll make smart decisions.

I also had a little hello from my three month old nephew, who was watching this, so we definitely appreciate that. Hey Sammy, how's it going? With that, we're going to let you go. Again, I hope to see everybody register. I'm going to have a registration for the next webcast shortly. I believe that's a Wednesday, the 21st, I think so. Shortest day of the year, so you might as well spend an hour of it with us. Until then, thanks a lot.

Kris: Thank you everybody.

Pete: Thank you guys for joining me. We'll talk to y'all soon. Take care.