Building Profitable Software Step 3. Choosing a timeline for ROI.
In this third post of a 5-part series, we’re teaching our strategy to plan for your return on investment (ROI). If you are excited to learn more right away, you can see the complete version in our whitepaper at reenhanced.com.
Unless you’ve gone the kickstarter route and have the good fortune of being fully funded, your app isn’t going to be a money-maker on day one. With massive opportunities remaining untapped, you can still make quite a good return over your build costs.
What’s the smart way to plan a timeline for your build?
Setting goals and targets, of course! If you are like me, you’ll want a return on your investment as quickly as possible. However, a shortened timeline to ROI may limit results and cause you to miss larger market opportunities. Choosing the right ROI target strategy depends on how your software business generates revenue.
Are you targeting the app stores?
Don’t. If your software is being sold in the app stores or via traditional download, you’ll only have a single chance to bill your customer. This limits the revenue you can generate.
If this is the model you’re pursuing, then use the following strategy:
Minimize development costs.
Maximize your budget in the direction of marketing and referral promotion inside your app.
Develop only the smallest set of features possible.
Expect high churn because of limited development resources.
Focus instead on marketing your app to attract the most customers. Consider outsourcing development offshores and using a company like reenhanced (shameless plug) as a check to ensure product quality.
Bottom line: When it comes to building a mobile app, you should be prepared to spend at least as much on marketing and promotion as you are on development costs, even if that comes at the expense of development costs itself. Mobile apps win through adoption, not superior engineering.
How valuable is your product?
Usually projects which provide a competitive advantage or help with business productivity, as well as software-as-a-service apps, generate greater revenue per customer since they can be billed more than once. When a customer subscribes to your product, rather than paying for marketing and “social growth,” they’re paying for and expect an increasing quality of product. When selling subscriptions to your product, plan for a heavy investment into software engineering and adhere to best practices so that you can fulfill your customer’s expectations.
Software-as-a-service apps can extend your time to ROI. Using a product like Framework (http://buildbettersoftware.com) to help set the foundation and build a great team is a sensible strategy. Focus on building a strong team, release the product early and often, and spend more on development than marketing. Your return on investment in this approach will be collected over a much longer time period, but your customers will be worth far more to you.
How many years to ROI?
You will need to determine your own timeline based on the size of your budget. For transactional mobile apps, target the shortest possible ROI you can, spend as little as possible on development, and reserve your budget for marketing.
For service apps, focus on building a great team and think about ROI on the scale of multiple years. Spend up-front on quality and engineering practices to give yourself the best chance for long term growth.
Both approaches are risky. We prefer the second approach where quality and stable growth are utilized as strengths, but a quick win on a transactional app can produce a nice one-time gain.
The next post in this 5-part series will cover estimating your total cost of ownership. If you’re impatient and want to learn more as soon as possible, you can visit reenhanced.com to get the whitepaper, where everything is covered in detail.
Building Profitable Software Step 2. Identify what could go wrong before and/or after launch.
In this second post of a 5-part series, we’ll teach you our strategy for building profitable software systems. We share the complete version in our whitepaper at reenhanced.com.
By the end of today’s post, you’ll become familiar with 4 types of risk that could negatively impact your ability to build your app in a way that allows you to profit.
It’s important to consider these risks even if you’re feel certain that they don’t apply to you.
In the first article in this series, you learned how to estimate the size of the opportunity for your software project. In a simplified view, this amount is the most you could ever hope to spend to develop your app. In today’s article, you’ll learn how to discount the value of the opportunity by the various risk factors that could delay or deny your ability to produce.
We’ve identified 4 risk areas that adversely affect software project outcomes:
The ability of your team to successfully execute
Your competition forces you to change direction
User needs change or disappear completely based on new information learned (also known as a “pivot”)
The problem you’re trying to solve is more complicated than it first appears.
Risk 1: Can the team execute successfully?
Even though your team is packed with talented people, your software development strategy and expectations from your management team will make a significant difference in your ability to produce a successful outcome.
What project management strategy does your software development team use?
How your idea is transformed from ideas to useful software is almost important as the developers themselves. To maximize your chances of delivering successfully, you’ll get your best results if you pick a project management strategy that aligns with the needs of complex software projects, even if your project appears straightforward at first.
Putting some thought into project management before you get started can make a big difference in the chance of successful execution.
After years of experience, we develop projects using iterative or agile techniques. This allows us to target a risk rate of 10% on our projects, but you’ll want to reference your risks from the chart found here.
Consider these development methods, and the frequency with which teams can expect to deliver a product that is “challenged” in some way even though it is not categorized as a failure.
What is the risk that your software project will be considered challenged?
Risk 2: Your competition
You don’t have to be a sports fan to realize that we live in a competitive world. While your development team may pride itself in its ability to get things done quickly, there may be competitors you don’t know about who are building a product with a better market fit. If that happens, you’ll be forced to react, spending more time and money to adapt to the market. Choose a risk factor you feel adequately represents the risk you face from competition: ___________%
Risk 3: The World Changes around you
Change is constant. In order to anticipate the need to change direction, you’ll want to limit the amount you’re willing to put into the project before you can gain enough information to know whether you’re going in the right direction. Almost any change adds to the time needed to complete a project. And during that time, it is possible that the user’s need could simply disappear completely. Frequent and clear communication with your intended audience will help you to notice when those changes might be needed.
How confident are you that you won’t need to change direction or “pivot” before the project is completed? (Subtract this percentage from 100 to arrive at your “risk of pivoting” factor.)
The risk you’ll change direction before you finish _____%
Risk 4: How hard could it be? Probably harder than you think.
On the surface, your app may appear to be pretty cut and dry. What if however, your needs are not clearly communicated in the first place? Suppose that for whatever reason, once you really get into it, you discover the project is more complex than you first anticipated. This is the risk of the unknown, and should be factored in to your development plan.
Estimate the unknown risk that may complicate your project: _____%
Now, take a quick look back at your answers above and add up the risks you identified.
What is the Total risk percentage?
This total represents the chance that your project will fail to meet your expectations within the strategy you’re developing. Record that number in the space indicated below.
What is the opportunity value (from Step 1) (A) $____________
Total Risk Percentage? (above) (B)_______%
Your adjusted opportunity value: (A) * ( 1 - (B) ) * 100 = $____________
This value represents the size of your opportunity discounted to account for risks, which you can use to determine a “safe” budget for your software project.
Are these percentage numbers all just a guess?
Sure, but by anticipating them before you begin any project, you will have a better idea about the potential outcome so you can increase your profit.
The next post in this 5-part series will cover choosing a target for ROI. If you’re impatient, you can visit reenhanced.com to get the whitepaper, where everything is covered in detail. (Please note: there’s currently an hour delay between signing up and receiving the whitepaper.)
Building profitable software: Step 1. How big is your opportunity?
This is the first in a 5-part series of posts that will teach you our strategy for building software systems at a profit. If you enjoy this, you can find a complete version in our whitepaper at reenhanced.com.
So you have a great idea that you’re certain will make money in the app store or online. But before your head fills with dreams of the yachts and private islands that you’ll buy with your $19 billion, there are a few things to remember.
1. The big “exits” you hear of are anomalies, as in, they statistically almost never happen. Venture capitalists with money to burn will play for the big wins. As for you and I? It’s much smarter to play for the “little” win (which is still big enough for you to live all of your dreams).
2. While you can’t know for sure what will happen, you can take steps to minimize your chances of failure. Those steps start with rational and sober thinking about what your app can be worth.
And that is where we’ll start with this first in the series of 5 posts. By the end of today’s post, you’ll know the steps necessary to determine an estimate for the maximum expected annual value of your app.
As you work through the following questions, if any of them do not apply to your idea, feel free to skip the question. This process is effective for ideas that are both new products and for tools that solve existing business problems.
How to Build Software for a Profit
Step 1: Determining maximum annual value
Answer each of the following questions to the best of your ability. Estimate if needed and if you’re building this for your own business, you may be your own customer.
- If you don’t build this app, how much are your customers going to lose each year because the problem continues to exist?
Opportunity costs total: $____________________
- Assuming you do build it, how many customers do you reasonably expect in the first year?
- About how much do you expect to charge each customer?
- Can you estimate an average cost that each new customer will bring? How much?
New business total: New Customers(#1) * (Revenue per customer(#2) - Per customer costs (#3)) = $___________
- How much additional business will your customer be able to handle once your app is built?
- Can your customer eliminate the need for positions or decrease the size of your payroll costs with this app? By how much?
- How many hours will your customers save on a weekly basis with the use of your app?
- Approximately how many hours do your customer’s employees work per year?
- What are the estimated combined payroll costs for your customer’s employees that will benefit from this?
Productivity total: New Business(#1) + Decreased Payroll Costs(#2) + ( Payroll costs(#5) / Hours worked per year (#4) ) * Weekly hours saved(#3) * 50 weeks worked per year ) = $__________
- How much did your customers spend last year on issues that the app will eliminate?
- How much is your customer spending each year to prevent issues that the app will address?
Error Reduction total: Spent on issues(#1) + Spent on prevention(#2) = $______________
Maximum Annual Value:
Opportunity costs + New business + Productivity Gains + Error Reduction = $____________
Now that you’ve determined the annual maximum value you should have a better understanding of the size of the opportunity for your app. This number represents the high side of a realistic estimate of what the app could be worth, but in reality, you’ll likely see gains that are below this value.
If the size of the opportunity is big enough, then you have great justification for moving forward, but before you take that first step, you’ll need to offset this value for risks and determine a timeline for a return on your investment into building the app. In the next post, we’ll cover the steps needed to take to offset this annual maximum value for the various risks that you’ll face when developing a software product.
How big is big enough?
The answer to this question varies greatly but the size of the opportunity also determines the size of the effort and money you can invest to solve the problem. Small opportunities demand small fixes. Larger opportunities can bring more complete solutions.
Isn’t this all just a guess?
Yes, but having a reasonable estimate of expectations will allow you to make smarter choices about how the problem is solved.
In the next in this 5-part series will cover how to offset the maximum value for risks. If you’re impatient, you can visit reenhanced.com to get the whitepaper, where everything is covered in detail. (Please note, there’s currently an hour delay between signing up and receiving the whitepaper.)
A Developer’s Guide To Upgrading To OS X Mavericks
I’ll admit I liked the sound of free with the latest release of OS X Mavericks. What I didn’t like was thinking about the headache from my last upgrade of the OS. Hopefully this will numb the pain. I use homebrew to manage my system packages, so if you don’t, you might as well stop reading this and light your computer on fire for having to deal with all the conflicting installs you’ve done.
Open up App Store and search for XCode… then wait an hour while it installs
Install command-line tools for X-Code
Just for fun, the command line tools for XCode have been removed from the Download section of the UI… so you have to run:
Upgrade GCC, Because Apple’s Sucks
brew install apple-gcc42
Several libraries and gems we use depend on Java. Luckily Apple makes this nice and easy to install *sarcasm*. After scouring the web, I found a nice packaged installer: http://support.apple.com/kb/DL1572?viewlocale=en_US.
I just imagine that there is a Tsunami of updates for pretty much all packages. First I updated homebrew itself:
cd /usr/local/Cellar git reset --hard git pull cd ~
Now that homebrew is the latest and greatest, I updated my brews
I also checked to make sure homebrew wasn’t missing anything, and turns out I had to install some packages it listed:
You’ll also want to check on the health of your brews, and fix anything it suggests:
Re-Install X11 and QT
In order to get our automated test suite working, we need QT working, and for that we need X11. Installing the latest release worked for me. Just visit: http://xquartz.macosforge.org/landing/ and download and install the latest release. At the time of this writing, 2.7.4 worked for me. Once that is installed, I upgraded QT:
brew upgrade qt
EDIT: Having issues upgrading QT? After attempting to upgrade on another machine I ran into errors compiling the source. This is a known issue with the latest Mavericks. For the latest fix and updates to this, reference: https://github.com/mxcl/homebrew/pull/23793
brew uninstall qt brew install -v https://raw.github.com/cliffrowley/homebrew/patched_qt/Library/Formula/qt.rb --HEAD
…wait an hour…
I upgraded my RVM to the latest release just in case they fixed things for Mavericks:
rvm get head
After upgrading to Mavericks, my previously installed Postgres was having some serious issues. I had to re-install it in order to get it working with my rails apps. First thing I had to do was remove the existing postgres:
brew uninstall postgresql postgresql92
Before you re-install, make sure you uninstall all your existing pg gems so that it can use the new sources in the next step:
gem uninstall pg
Now install postgres (I’m using 9.2 as it’s what is needed for a project I’m on).
brew install postgresql92
I had to manually link the startup scripts:
ln -sfv /usr/local/opt/postgresql92/*.plist ~/Library/LaunchAgents
Now install the pg gem again
gem install pg
After all that, there was just one gem that needed an update (probably due to the QT updates). If you run into issues with any of your gems, just try updating them or uninstalling/reinstalling. For me it was just:
gem update capybara-webkit
We use tmux and tmuxinator as our editor/console combo. I’ve had to upgrade tmux since the writing of this post.
brew upgrade tmux gem update tmuxinator
After ALL of that I was good to go with minimal issues. Hope this helped.
Business Growth Advice from a Computer Hacker
I have a secret to tell you. My name is Nick and I’m a computer hacker.
But don’t worry, I use my powers only for good.
One day when I was in high school it started to snow. By mid-morning, several inches had accumulated, but the school still hadn’t announced an early dismissal.
Whispers started and everyone wondered eagerly…
Are they going to call it?
When are they going to make the announcement?
What time will they let us out?
On this day, like most days, I could be found in the computer lab. But this morning, the anticipation of getting out early was too much. I grew impatient. They have to let us out with the snow on the ground, don’t they? Don’t they?!
Time ticked by slowly. 9 o’clock … 9:05 … 9:10. And with all of the maturity and impatience of a teenager (who knew too much for his own good!), I made the call. If the school wasn’t going to make the announcement, I will! Maybe some encouragement would help them do what all of the other schools were already doing. How could this possibly go wrong?!
See, I’d throughly explored the school’s website in my own time. And through my curiosity, I discovered a way I could modify the district calendar without needing to authenticate. I had the power to change the calendar shown on the school’s website, so I would change it to announce an early dismissal. And that’s exactly what I did.
Within what felt like 8.3 seconds of making the change and showing the lab technician, the entire school knew.
"We’re getting out early today, it’s on the website!"
"We’re going home early! I need to call my mom!"
"Early dismissal.. yay!!"
And we waited.
The lesson I learned on that day was the start of a bigger concept that would echo back to me again and again in different ways across the years. I learned that if you really want to accomplish something, be it an early dismissal or growing a business, you can’t do it by hacking the system.
A business and a computer program are similar in more ways than you might think. They’re both structured ways of accomplishing a task.
I can hack a computer program to make it behave outside the rules in very specific circumstances. But despite repeated attempts, I’ve learned you can’t hack a business the same way. It is possible, but hacking a business is done in a different way.
To hack a business, you do it by hacking “people” and not the business itself.
See, a business is made from the people (and relationships) that run it. If you really want to hack your way to greater profits, then you need to understand human psychology. You need to understand human behavior and motivations. And you need to take what you learn and use it to approach all of your interactions with a new strategic outlook.
Are your interactions with your customers strategic?
What about your website or your pricing?
Can you identify the strategies I’m using right now on you as you read this? (Yes, I’m “hacking” you right now. Can you spot it?)
How much more could you do if you understood how to use the power of human psychology to your benefit?
It was mid-afternoon by the time I was called to the office, and I hadn’t a clue why. I knew the computer systems better than the district techs themselves, so I was sure I was safe. I thought they just wanted me to look into what had happened to see if I could provide any advice on how the early dismissal may have found its way onto the calendar.
Gary, the new district tech they hired that year, was there and him and I had already grown to be friends. But I saw the papers in his hand and I instantly knew the mistake I’d made. I was using the “private” network that allowed unrestricted access to the network… while logged in to my own account. How could I be so careless!
He began to speak and I already knew what was coming. I was so nervous, my legs went numb. Oh…. crap. I cut Gary off and the words exploded out of my mouth, “It was me! I hacked the website!”
And the school’s vice principal had to hide the grin from his face. He was proud of what I’d done. It was clever. It was “awesome”, but there’s no way he could let me know. I will never forget the look in his eye, simultaneously “Atta boy!” and “You’re in trouble!”
I received my first and only suspension that day, and I’m still proud of it to this day: “Nicholas altered the district website and announced an early dismissal”. I can think of no better reason to get a mark on my permanent record.
We never did get out early that day.
P.S. I would like to apologize to everyone who wrecked their car that day.
How to be a responsible businessman: Bill clearly.
The way you bill for your service can have a big impact on how your customers think of you. Let me give you an example.
I don’t talk to my lawyer nearly as much as I should. Do you know why?
It’s because I know that every time I talk to him and even start to mention a new idea, I know the clock is going to start running and I’m going to get a bill.
Even if I’m wrong about this, he’s losing out on potential business from me because my relationship with him isn’t clear.
It’s your job to make sure your customers aren’t afraid to talk to you.
As a customer, it can be difficult to know what makes the difference between billable work and non-billable work, so you should make this as clear as possible. As soon as you start talking to a new customer, outline your billing method.
But don’t expect your customer to remember or understand until later.
You should provide a PDF or page on your website that’s like a cheatsheet for when your customer will expect a bill.
Send this PDF to your customer every time you “get back in touch” (if you’ve made the mistake of letting the relationship grow cold) so they don’t have any surprises about talking to you.
This is important because the trust you build with your customer is far more important than the money you make today. With greater trust, you’ll gain exposure to greater opportunities. And with greater opportunities, your earning potential is practically unlimited.
The world is abound with opportunity. If you want it, take it.
Quality is not enough.
A few months ago, I discovered that I’ve been running my business mostly by accident. Are you making the same mistakes as I did?
I would rely on word-of-mouth to get new business and occasionally run some poorly thought out ads. I thought “If we do good work, people will come to us”. That’s only partly true. Sadly, quality is not the only ingredient necessary for success.
The quality of the work we do is important, but you know what putting quality above all else leads to? Shiny products in an empty void. Constant stress and none of why I got into business in the first place. To be free.
The world doesn’t owe me a damn thing. Even if we do great work.
Want to know what I figured out?
Businesses are run by guys like you and me. We buy something when it is worth more than it costs. If you help me know how much something is worth, I’m willing to pay more for it. Screw competition. Screw everything else. Make it easy for me to know why buying from you is a good idea. Put me first.
I want to work with the guy who understands how much is product is worth to me, even if he costs more. I am busy as hell and I don’t want to spend forever and a day making sure I optimize things I don’t understand. I need to focus on my things and try to enjoy my life.
Look, I don’t know how you do what you do. All I really care about is what it does for me. In the end, if what you provide doesn’t make me more money than it costs, I won’t buy it. I don’t give a damn about your costs, your causes, or anything else that doesn’t make a difference for me. I have my own things to worry about.
If you want to increase your sales, it starts by knowing your worth. Can you measure how much your product or service is worth to someone like me?
If not, why the hell not?
I want to see you kick ass. You can do it.
I’ve got faith in you,
P.S. If you like this and would like to read more like this, subscribe to my newsletter: Business Tech Secrets
A flexible git workflow for teams.
We use a simple development model for our projects that’s lightweight enough to stay out of the way and flexible enough to handle real world usage.
Git is distributed source control
Git is the version control system of our choice. Each developer has a copy of the complete history of the project on his machine which reduces the likelihood of loss and its other features support the workflow we’ve designed.
Github provides great tools for code reviews through something they call “pull requests”. Github has the largest code collaboration network in the world and that means their tools have been refined through real usage. We’ve tried alternatives, but github is second to none.
One true master
With a few exceptions, our projects have a single branch of code from which the entire team will work. We don’t bother with maintaining different branches for different purposes because in practice (even in apps with > 20k monthly active users) you just don’t need different branches.
Instead, the whole team will remain focused on keeping the master branch stable for the rest of the team. With only one branch to maintain, it’s easy to treat it with the respect it deserves.
All of our work is built with automated testing, so that means all of the tests in the master branch must pass at all times.
Small Feature branches
Every feature, no matter how tiny, is developed in a branch off of master dedicated to that feature. This allows the developer to focus on developing the feature in isolation without concern to what’s happening with the rest of the project.
There are few rules or restrictions on how each developer works inside his own feature branch. He can commit changes as often, or as infrequently as he likes. As long as the feature has been defined to be small enough, it does not matter.
Each feature branch is named after the feature being developed and starts with the initials of the developer or developers who “own” the branch. As an example, if I need to update the homepage, my branch would be called `nh-update-homepage`.
We’re a small team, but we believe strongly in the value of code reviews. All of our feature branches are reviewed by at least one other member of the team before code is approved to be merged to master.
We use github pull requests to review the changes between the master branch and the feature branch. This way, only the changes made by the developer will be reviewed and changes can be made to prepare the code for delivery.
Github’s pull requests allow us to leave comments for each other, share knowledge of the work being done and have a great conversation on the code that will be available for us to review in the future. (Yes, we’ve gone back to our work later to determine why decisions are made. Documenting those in a pull request allows us to understand the decisions again quickly.)
After a branch is reviewed, the developer(s) who approve the request leave a comment saying ‘LGTM’ (Stands for Looks Good To Me) to confirm the code has been reviewed and allow future discussion.
Squash Merge with link to pull request
We don’t keep old feature branches and we don’t care how each feature branch was developed. A month from now, we’ll care only about the features that have been added, so we discard the details of how each feature branch was made.
We do this by creating a new commit on the master branch that represents all of the commits in a feature branch through a technique known as “Squash Merging”. This allows us to have every commit from a feature branched rolled up into a single new commit.
Inside the commit comment for the squashed merge commit we’ll include some text that Github recognizes to link/close the associated pull request. (Example: “Closes #38”) This allows us to review the discussion on each feature if we need to review in the future.
As another bonus, the squash merge means that the history of the project remains clean. Each commit in the master branch represents an entire feature after review, so if we do a “git blame” to see when a line of code was changed, we’re able to see the full context of the change, not see that it was changed because of a typo fix.
After the merge to master, the feature branch is removed and will never be needed again.
What about features that are too big for a branch?
Sometimes a feature is too big to be part of a small branch, but cannot be released to users until all of the associated tasks are complete. To handle this, we use rollout to include the feature being developed into the master branch but leave the new functionality disabled until complete.
This allows other developers to work with the new functionality without displaying it to users. Sometimes we’ll have both old and new code in the project at the same time which means we will go back and remove the old code after the new feature is enabled. This adds a small amount of overhead, but eliminates the headache of managing multiple long running branches just to support the addition of new features. It also maintains a clear view of the actual state of the project for all developers.
How do we follow this process?
While we can do every one of the steps above by hand. We’ve developed a tool called Git Reflow that automates much of this process to make sure we follow every step every time.
Here’s how it works:
git reflow start nh-branch-name to start a feature branch.
git reflow review to review a feature branch.
git reflow deliver when finished to deliver a feature branch to master.
Keep your bullshit filter on high. Technology isn’t everything.
If you pay attention to what you hear on the news and see on the internet, it can feel like “game over”. Nerds like me have won and if you want to “make it”, it seems you have to be one of them or befriend one.
I might be a nerd, but I can tell you that the media has it wrong. The world is much much bigger than Facebook and iPhones. There’s real work that needs to be done and Facebook has little to no impact on real business. (How about you “like” a hard day of work? What, no takers?)
A large number of companies are trying to capitalize on all of the attention that the tech industry is getting. They’ll tell you things like:
- "You need to have a Facebook page"
- "Your business needs to be active on Twitter and YouTube"
- "If you get more likes on Facebook, your business will make more money"
I’ll be honest with you. Some of these companies are trying to capitalize on the fear, uncertainty, and doubt you have around this. Heck, many of them even believe it themselves, so in their mind, they’re actually making a difference. But seriously, what does a Facebook “like” have to do with the revenue you need to run your business?
If it looks like bullshit and smells like bullshit… well, you know the rest.
It comes down to this. If someone makes you an offer and they can’t provide a direct connection between the goal (more customers, more profit) and the solution they provide, then don’t do it, no matter how convincing it might sound.
The last thing you need to do with your business is make an “investment” in technology that you don’t understand.
Because, you know what works in your business?
There’s nothing that will replace the connections you’ve made with your customers and your vendors. No tool, online service, or gimmick will ever replace the human aspect of what makes your business yours.
If someone comes to you to try and sell you something and can’t make a direct connection to the results, or can’t offer proof of the real results their work has done in the past, then give it a pass. Your time and money is too important to chase meaningless metrics.
Keep your bullshit filter high.
Until next time,
P.S. After all of this, yes, I admit, there is some benefit you can get through proper execution on Facebook or YouTube or Twitter. Just be smart about it and trust your gut.
Are you looking to reduce the amount of bullshit in your life? Are you sick of technology guys who feed you lines, but don’t deliver results? Let’s talk about how I can help.
If you don’t update your Rails 2.3 app, you are in danger. Here’s what will happen.
You may have been contacted recently about upgrading your Ruby on Rails application. It is very important that you do not ignore these emails.
With the release of version 4.0 of Ruby on Rails, your application, running on a version less than 3.0 will no longer receive any security updates.
If you take no action, the following things are going to happen to you. It is not a question of if, but only a matter of when. Here’s what you can expect to happen if you ignore the emails you received.
Your data will be compromised.
Everything that has ever been entered into your application, either by you or your customers will become compromised. Meaning, someone who you don’t know and who may have dishonorable intent will have complete access to your data. What they choose to do with it could have serious impact on your business.
Your application could be modified without your permission.
If gaining access to your data isn’t bad enough, the type of access that will, at some point, be gained to your application will allow someone who you don’t know to make changes to the way your application runs.
If you think about your application as a machine that performs business tasks for you, this means that someone will be able to get inside and change the way your business works, while it is running, and you would have no idea until for example, your credit card payments go to some one else’s bank account.
Your insurance will not cover the damages.
Your insurance, and the insurance of the technical team that built your application (You did work with an insured team, didn’t you?) will not cover the damages when someone gains access.
Sure, you can file a claim, but your insurance company will quickly discover that the damages you’ve received are due to a lack of maintenance, which in most policies is explicitly not covered. This is a preventable risk and it is entirely your responsibility to make sure it is addressed.
You will find out how much your application is worth to you.
If you rely on your application for any business purpose, you will find out the hard way how much it is worth to your business. You will have no protection against the losses and your business insurance will not cover the damages.
Your losses will provide, in very direct terms, a measurement of how important your application is to your business. It’s probably worth a lot more than you think.
What can you about this:
Patrick McKenzie has done a great job covering the options available to you in his blog post titled “If Your Business Uses Rails 2.3 You Need To Move To A Supported Option ASAP”.
In summary, you have a few options:
- Do nothing and face the consequences listed above.
- Turn off your application and pay nothing.
- Rewrite your application to use a supported version of Ruby on Rails (Recommended, but expensive.)
- Use a commercially supported version of Rails 2.3 and setup a maintenance plan with a software development team. (Less expensive. May be the right choice if you no longer plan to change your app.)
Remember, if you choose to do nothing, you will face consequences.