Return to site

12 Steps to Building An Online Franchise Feature: DIY or Franchise?

We’ve had a few potential franchisees ask us why they should buy into an online franchise instead of just building something like OrderUp on their own. They think building something like OrderUp wouldn’t cost much more than, say, a simple marketing website. As the VP of Engineering, I can say it’s a lot more complicated than that. Beyond the costs to build the first version of OrderUp, we’ve got a whole team of developers, designers, and consultants who work to improve OrderUp on an ongoing basis.

Luckily, the few prospective franchisees who’ve actually contacted a web development firm to find out how to build something like OrderUp have learned the truth quickly. As Jon Canter, one of our Indianapolis franchisees, told us, “I talked to a guy I know who’s really good with web design, and I asked him how much it would cost to do a site like [OrderUp]. He said hundreds of thousands of dollars as a minimum, this kind of set us back.” And those costs don’t even count our centralized call center, national branding, training, support—the list goes on.

 

 

I thought I’d address Jon’s question of what it takes to build—and maintain—the technology behind OrderUp by walking through how we add just one feature. We recently built a reporting feature which sends restaurant owners updates on their sales. Before, we were licensing reporting software from an outside company, so we were building this feature from scratch. As you read the steps below, keep in mind that this reporting feature is just ONE of many features.

  1. Consider stakeholders and what they want. Before building any feature, we consider, and often survey or interview, the people the feature is going to serve. There are three key stakeholders for the reporting feature:
            a. Restaurant owners. They need reports to be reliable, accurate, and easy to understand
            b. Headquarters. Cost and ease of maintenance are key factors for us
            c. Call center employees. They’re the ones fielding phone calls and emails if the reports aren’t working or are hard to understand. If our reports don’t work, their lives get hard.

  2. Identify the use cases. Next, we figure out all the different ways the feature will be used. For the reporting feature, we decided to simplify the options from 12 reports to six. Each of our restaurants gets at least two reports, either every day or every week (they can choose). We start from there to build out each use case.

  3. Identify external dependencies and choose vendors. Identifying external dependencies—anything we’re not going to build ourselves—is essential for planning and minimizing costs and risks. For reports, these dependencies are email and fax, to deliver the reports to restaurant owners. In this stage of the process, we evaluate whether it makes sense to do something ourselves our outsource it. For example, we used to host our own email, but it became more efficient to work with an outside provider, so we switched. Once we’ve identified an external dependency, there are generally a lot of choices for vendors. We vet providers to make sure they’re reliable and choose the best one.

  4. Model data and determine how the feature will interact with the database. With data modeling, we have to figure out whether—and where—we’re going to store any data. For reports, this data includes which restaurants are subscribing to which reports, regular restaurant hours, and holiday and temporary hours. Additionally, we have to model the data that’s going into reports.

  5. Make the reports. For this stage, we have to design the reports and the user interface, write HTML, write Ruby (server language), and set the reports up to make database queries.

  6. Build the integrations with external dependencies. We’ve already figured out what our external dependencies are, now we have to build them using their APIs (Application Programming Interfaces).

  7. Get feedback from stakeholders. We’ve already considered what our stakeholders want, but now we circle back to see what they think of our work.

  8. Make changes, or move forward. If we get actionable feedback, we’ll make changes to the feature. If everyone’s happy with the feature, we move forward.

  9. Put it all together, and make sure everything works. We do one final quality check here to make sure everything is connected and working correctly.

  10. Move the code into production. We put the code onto our server so the new feature is live.

  11. Maintain and monitor the feature for bugs and usage. We pay special attention to the app for the first few days of the release, and then if everything goes smoothly, we just keep an eye on the feature. We use New Relic, a monitoring tool, to track performance. We’re looking to see if there are any errors, if people are using the feature correctly, how much traffic there is, and how long requests take. Even if you have no errors, but requests take a long time, it’s not a good feature and we’ve got to keep working on it.

  12. Start over if/when use cases change. While we’ve built the infrastructure for the reports so that we can easily make certain changes, like adding a report, sometimes our stakeholders’ needs change. We’re constantly maintaining features and considering whether it’s time for an upgrade. We find most features need to be updated in a year or two.

That’s twelve very time-consuming steps for a feature that’s a tiny part of OrderUp. We take care of this part so that our franchisees can get out there and do what they do best—sales and marketing. It’s a win-win.

We’ve had a few potential franchisees ask us why they should buy into an online franchise instead of just building something like OrderUp on their own. They think building something like OrderUp wouldn’t cost much more than, say, a simple marketing website. As the VP of Engineering, I can say it’s a lot more complicated than that. Beyond the costs to build the first version of OrderUp, we’ve got a whole team of developers, designers, and consultants who work to improve OrderUp on an ongoing basis.

Luckily, the few prospective franchisees who’ve actually contacted a web development firm to find out how to build something like OrderUp have learned the truth quickly. As Jon Canter, one of our Indianapolis franchisees, told us, “I talked to a guy I know who’s really good with web design, and I asked him how much it would cost to do a site like [OrderUp]. He said hundreds of thousands of dollars as a minimum, this kind of set us back.” And those costs don’t even count our centralized call center, national branding, training, support—the list goes on.

I thought I’d address Jon’s question of what it takes to build—and maintain—the technology behind OrderUp by walking through how we add just one feature. We recently built a reporting feature which sends restaurant owners updates on their sales. Before, we were licensing reporting software from an outside company, so we were building this feature from scratch. As you read the steps below, keep in mind that this reporting feature is just ONE of many features.

  1. Consider stakeholders and what they want. Before building any feature, we consider, and often survey or interview, the people the feature is going to serve. There are three key stakeholders for the reporting feature:
            a. Restaurant owners. They need reports to be reliable, accurate, and easy to understand
            b. Headquarters. Cost and ease of maintenance are key factors for us
            c. Call center employees. They’re the ones fielding phone calls and emails if the reports aren’t working or are hard to understand. If our reports don’t work, their lives get hard.

  2. Identify the use cases. Next, we figure out all the different ways the feature will be used. For the reporting feature, we decided to simplify the options from 12 reports to six. Each of our restaurants gets at least two reports, either every day or every week (they can choose). We start from there to build out each use case.

  3. Identify external dependencies and choose vendors. Identifying external dependencies—anything we’re not going to build ourselves—is essential for planning and minimizing costs and risks. For reports, these dependencies are email and fax, to deliver the reports to restaurant owners. In this stage of the process, we evaluate whether it makes sense to do something ourselves our outsource it. For example, we used to host our own email, but it became more efficient to work with an outside provider, so we switched. Once we’ve identified an external dependency, there are generally a lot of choices for vendors. We vet providers to make sure they’re reliable and choose the best one.

  4. Model data and determine how the feature will interact with the database. With data modeling, we have to figure out whether—and where—we’re going to store any data. For reports, this data includes which restaurants are subscribing to which reports, regular restaurant hours, and holiday and temporary hours. Additionally, we have to model the data that’s going into reports.

  5. Make the reports. For this stage, we have to design the reports and the user interface, write HTML, write Ruby (server language), and set the reports up to make database queries.

  6. Build the integrations with external dependencies. We’ve already figured out what our external dependencies are, now we have to build them using their APIs (Application Programming Interfaces).

  7. Get feedback from stakeholders. We’ve already considered what our stakeholders want, but now we circle back to see what they think of our work.

  8. Make changes, or move forward. If we get actionable feedback, we’ll make changes to the feature. If everyone’s happy with the feature, we move forward.

  9. Put it all together, and make sure everything works. We do one final quality check here to make sure everything is connected and working correctly.

  10. Move the code into production. We put the code onto our server so the new feature is live.

  11. Maintain and monitor the feature for bugs and usage. We pay special attention to the app for the first few days of the release, and then if everything goes smoothly, we just keep an eye on the feature. We use New Relic, a monitoring tool, to track performance. We’re looking to see if there are any errors, if people are using the feature correctly, how much traffic there is, and how long requests take. Even if you have no errors, but requests take a long time, it’s not a good feature and we’ve got to keep working on it.

  12. Start over if/when use cases change. While we’ve built the infrastructure for the reports so that we can easily make certain changes, like adding a report, sometimes our stakeholders’ needs change. We’re constantly maintaining features and considering whether it’s time for an upgrade. We find most features need to be updated in a year or two.

That’s twelve very time-consuming steps for a feature that’s a tiny part of OrderUp. We take care of this part so that our franchisees can get out there and do what they do best—sales and marketing. It’s a win-win.