For more information on the award, check out the feature article in the Denver Business Journal.
Taking the dive into creating custom software for your business is not a small decision. Whether it’s creating a new app or adding features to an existing one, you could be looking at $10K, $100K or even $1M dollars in costs. There’s no reason to ever make that decision unless you will get at least that much in return.
Justifying your return is usually some simple math – what are my costs for developing, implementing, and supporting the new app vs. what will I either SAVE or MAKE from owning it?
You can get fancy with calculating the ROI over time, create spreadsheets with pro-forma sales and expenses, and while those are worthwhile analyses and we do them all the time, at the end of the day, it should be obvious that the software will deliver a return.
Sometimes the return is pure cost savings (e.g. it takes 4 employees to manage this process vs. $50,000 dollars of software that can be run by one person working part-time) and other times, it’s purely new revenue (e.g. my customers will pay me $50,000 dollars more over the next year if I build this $10,000 dollar feature).
What I’ve found over the past twenty years of building software is that the return you’ll realize is often a combination of both cost savings AND increased revenue. For example:
The math really isn’t complicated, and obviously, when you have both cost savings AND increased revenue, it makes it easier to justify the investment.
At Woodridge, We Hire The Best Developers In The Business
Our team of full stack developers builds strong ROI production apps every day. However, unlike some other development shops, we have a very business-focused view of building software. Combined, we have helped launch over 100 companies during the past 20 years. We have seen them soar to huge successes and we’ve seen them stumble and fail. Because of this experience, dozens of times per year, we say “No” to new and current customers: “No, there is not an ROI for that feature”
“No, your customers are better off using your existing accounting software, not having us rebuild that feature.”
We know we’re successful when our customers are successful and sometimes saying “No” is the right thing to do. We also know it helps our customers trust us, so that when we say, “Yes, let’s do this,” you can trust that Woodridge’s development and business experience is with you.
Kaj Gronholm is the CEO at Woodridge Software, a custom software development firm located near Denver, Colorado. Woodridge specializes in Web, Android, and iOS development and works with a variety of clients ranging from startups to Fortune 500 companies.
iOS 11 was recently released and that means two things: One, your iPhone just got some very cool new features and two, your apps might break.
At Woodridge, we build web and mobile applications and many of our projects actually include both. Web apps run in browsers which, for the most part, are backward compatible. This means a web app written in 1999 likely will run fine on your 2017 Firefox browser (probably just as well as it did on your Netscape browser).
Mobile apps, however, rely on the operating system of the mobile device. Android and Apple (iOS) are updating their mobile operating systems at a frantic pace. This is great for the user, as better features mean a better user experience. But, if you own an app, it also means that each update has the potential to break your app. Substantial updates, like iOS 11, are more likely to do so.
Fortunately, if Woodridge has been performing regular updates on your app, the changes needed to work with iOS 11 are minimal or nothing at all. However, if it has been 6 months or more since the last update to your software, it might take 3 to 4 days of work to update everything.
We’re here to help. So let’s enjoy these new features, but be ready to keep your apps running smooth. You may want to integrate some of these new features into your app to enhance the experience of your users. With iOS 11, the Files App will be a big one, as will Instant Markup. Let us know if you’d like to chat about how these and other updates that could improve your app.
Kaj Gronholm is the CEO at Woodridge Software, a custom software development firm located near Denver, Colorado. Woodridge specializes in Web, Android, and iOS development and works with a variety of clients ranging from startups to Fortune 500 companies.
It seems like every day we hear about another security breach in the news. From Target to Ashley Madison, it seems like everyone is a target nowadays (no pun intended). So how do we protect ourselves? The first steps are awareness and education, but specifically for software developers, you must learn to think like an attacker, and in order to think like an attacker, you must learn how security breaches occur.
There are many aspects that go into a typical security breach. Security attacks take time, patience, and lots of information; sometimes they don’t involve any “hacks” at all. Many security breaches simply occur because of a lack of training and gullible people. For example, maybe someone left a sticky note on their desk with their username and password. All it takes is a curious passerby to borrow the credentials and there you go, no hack needed! Most security breaches, however, are typically a combination of social engineering and a variety of malicious code.
From a software developer’s point of view, the objective of creating a new product is typically to make it conform to the designs. However, designs typically contain little security thought and are mostly focused on the overall goal of the project. After all, user-interface specifications are not the place to tell you about how to prevent buffer overflow attacks, cross-site scripting, and the like. This typical “make it look like the designs” approach is not sufficient to secure a system. There are many aspects of development that should be put in place but are often not due to lack of knowledge on how to properly secure a system. This is why being able to think like an attacker is an important goal for all developers.
So how does one start thinking like an attacker? A good place to start is reading up on penetration testing. Penetration testing is an important process that is often left out of the software development lifecycle, but when properly included, it can help close a lot of doors in a system which will help keep the bad guys out. Penetration testing is an act of friendly fire (that’s actually welcomed). The job of penetration testers is to attack a system similar to how a real attacker would, with the goal of finding vulnerabilities that can ultimately be patched.
A typical approach to penetration testing is as follows: reconnaissance, vulnerability assessment, exploitation, maintaining access, and covering tracks. The first step is reconnaissance, also known as information gathering. This can include simple things such as acquiring some search engine results, looking at social media accounts, and of course some technical tasks such as network scanning and service identification. Next is vulnerability assessment, there are many tools that can be used to perform vulnerability scans. Once the vulnerabilities have been discovered then exploitations can be implemented to get inside the system. From there, it’s important that access can be regained again so data can be gathered (passwords, codebases, etc). Finally, once the goal has been completed, it’s important to clean up any evidence that any exploitations every occurred.
The key aspects of penetration testing are exploitations. Understanding exploitations, how they are discovered, and how they are prevented is a very crucial aspect of the software development process. If developers understand how various attacks can occur, then it will become second nature to them to preventing them while they develop their product. This will ultimately yield a more secure product overall.
We live in a digital age. Data is the new gold, and to properly protect our data and other technological assets the developers in charge of creating and maintaining these assets must be fully aware of what they are up against. The tools that attackers use are powerful, their techniques are clever, and if the assets are worth enough, they will stop at nothing in achieving their goal.
You’ve built an app and now you want to monetize it. It seems like a simple concept – companies sell apps all the time. However, actually collecting payment from your customers into your bank account means making some compromises because there’s no perfect, simple method to do this that fits every use case.
In this blog, I’m not trying to address how to price your app. What you actually charge will have some impact on the app payment method; however, sometimes the way you sell it will also influence what you charge. This blog also isn’t focused on how to set up e-commerce sites that sell products. The focus of this blog is addressing the nitty-gritty of different methods for collecting payments themselves.
Too often the decision on how to collect payment is left for after the app is developed. However, as we shall see, waiting until the end will change the options you have. The goal for this post is not to give all the detail on every option, but just to discuss the high-level pluses and minuses of each choice. Hopefully, this blog will give you a foundation of knowledge so you and your development team can make the best decision.
In this blog, I’ll cover six methods to get money from your customer’s bank accounts into yours and I’ll address how they work for both Web and Mobile Apps. I’ll start with the mobile options, then discuss options that work for both mobile and web, and finally just web options.
One of the simplest methods to collect payment for your mobile app is to charge to download it from the app stores. You put your mobile app in the store and choose a price ($1.99 to $4.99 is the most common, but it can be anything you want). 30 to 60 days after the end of each month, Apple or Google will send you a check. However, you might be surprised to find out the check is for 70% of what was sold, the other 30% stays with Apple or Google.
Why would anyone give up 30%? Well, for one, it is the simplest way to collect payment for your app. Apple handles all payment processing and returns. You have a low-security risk since you never process a credit card transaction. Another reason may be that it’s the only option you have. If your app doesn’t have user accounts or other features that require a back-end server, there may be no way for a user to send you payment.
Selling direct in the app store is also a good option if the price of your app is very low, say under $10. In this case, your goal is volume. It’s much easier for someone to just download an app and click approve payment. At a price point of $1.99, most users are not going to want to go to your website and create an account and enter a credit card. Apple has recently changed its terms if your app is subscription based. Now you’ll pay 30% on the first download, but when the customer renews the second year they will only take 15%. How nice of them.
There are definitely good reasons to sell your app using a per download fee in the App stores and many apps make their owners very good money in the stores; however if your app will create user accounts, and requires a backend server, you may find that there is more money to be made using “in-app purchases” or registration on your website.
This is a corollary to the method above. It’s also known as a Freemium model, though the term freemium can be used to describe other payment methods too. In this plan, your app is free to download, but if the customer wants all the features, you charge for them in-app. Like the option above, it’s a simple method and very effective.
However, just like collecting payment to download the app, Google and Apple keep 30% of these purchases. If you are selling content that is “delivered” via the app itself then you can’t avoid this 30% fee. The concept of “delivered” via the app is a critical one. Some apps, for example, Uber, do not pay the 30% fee, even though Uber will charge you in the app itself. The key here is that the content or service is delivered out of the app. In this case, the phone can’t pick you up and drive you around (at least not yet!), so Uber does not pay the fee. For an alternative example think of Audible. Their books can be delivered in the app. For this reason, Audible won’t let you buy an audiobook in-app, you need to buy audiobooks on their website. The Audible app just lets you download what you have already bought.
Apple and Google are quite strict about enforcing this rule. It’s sometimes hard to figure this out if your content/service is delivered in-app or out-of-app, but we can help you figure this out.
The “in-app purchase” model is great if your app has a low price, think $0.99 to $4.99 features that you can buy. Also if you have some free content that is valuable without the purchase. However, if you don’t have these low priced features, or have a strong web presence, it’s likely best to avoid the 30% fee, and use another option.
Now we are getting to the fun options, at least from a technical standpoint. In this case, we have a mobile app that is free to download in the app store and there are no premium options that you pay for directly to the app store. However, you can buy things inside the app, such as premium content and the app has a web server backend, that will hold all the customer information and credit card data. It’s definitely more complicated than just collecting payment directly in the App store, but you can avoid the 30% fee.
As mentioned above, Apple can be a bit finicky on approving apps that collect payment outside of the app. They, of course, want their 30%, but there are plenty of apps that allow for payments on the website. For example, an e-learning app that students use to take photos for a portion of a class, but use a web app to complete their course. In this case, you can give your app away for free and then have the students pay for the course online. Another example would be having a mobile app that is used by someone who is out in the field, say doing construction, but the field users are managed via a web app. The field users download the app for free, and you charge the web users online. The field user app isn’t useful without a web account to create the logins.
If you’re designing your app to avoid paying Apple’s fees, then having web-based payments is a great way to do it. However, care must be taken to ensure the user experience is smooth. Take a look at an app like Audible, your account and credit card are entered into the web app, then when you download the mobile app, you just need to sign in. The development team still needs to implement things like “Forgot Password” capabilities on the mobile app, so there is some overlap for user account work. These types of app features aren’t always necessary if you’re just taking payments in the App stores.
Technically the general flow is that a user logs in on the mobile app; the mobile app will connect to the web server backend to verify the account via an API; then, over the API, credentials, and content are sent back to the app. This is all done securely over SSL. Care needs to be taken to make sure user accounts, EULAs (End User License Agreements), and forgot password features all work seamlessly with the web server’s API.
Another bonus is that if you’re collecting payments in your web app, you can more fully control features and content on your mobile app. Often the best plan as discussed above is to give your app away for free, and then handle the payment on the web app. Now we have full control over all features in the mobile app via an API and can turn them off or on based on the plan we sell in the web app.
None of these technical details are challenging, but they do take time. The question is whether it’s better to invest this time and skip the 30% fee, or if you are better off just letting the App store collect payments. We can help you decide. Of course, if you’re collecting any payment, you still will be charging a credit card and paying about 3%. Which brings us to the next method. . .
Whether your app is mobile and web or just web, a great option is to collect payments inside of your web app. About half of our customers choose this option and for good reason. It offers the most flexibility and the lowest on-going costs. Since it’s your own custom payment solution in the app, you have the flexibility to choose and change your versions of payment. Setting up thresholds for “freemium” content, having free trials, adding in tiers of subscriptions, having one time payments and then lower monthly subscription fees, turning on and off options are all available to you.
There are some upfront and ongoing security costs. Your site needs to be secure, as well as PCI compliant. User accounts and payment methods are prime targets for hackers, so once you go down this road you need to plan to invest in the maintenance and upkeep of your site. All that said, you have complete control when using a web app for payment collection. Your users will create accounts on your website and then enter credit card information. You choose if there is a one-time fee or a subscription.
It’s important to know how the payments are processed, as there are a few choices. It’s simplest to think of credit cards being run through two steps. The first is the payment gateway, which is basically the tools to get the credit card information. Think of the payment gateway as the credit card machine on your website. It’s where users enter their credit card info and it authorizes the card. To actually get the funds from the credit card to your bank account requires the second part, a merchant account. The merchant account is a bank account that processes the credit card and collects payment and sends it to your bank account. You need both a payment gateway and a merchant account to complete a credit card transaction.
To further simplify this process there are companies that combine the two steps. Companies like Square, Stripe, and even Paypal, will do this for your site. For the ease of combining the payment gateway and merchant account into one, they will charge 3% plus a transaction fee.
3% does not seem like much, but if you are collecting $100,000 per month, that’s $3,000 per month or $36,000 per year. If it’s $1,000,000 per month then it will cost you $360,000 per year. By having a separate merchant account and payment gateway, you can get the fees down to 1.5% or close to half of the price for the bundled service. Therefore, larger companies almost always have separate merchant accounts and payment gateways.
It really isn’t much harder technically to have separate payment gateways and merchant accounts, so if you’re willing to spend the few hours getting them set up at the beginning, you can increase your profits by 1.5% which could be huge over time. Companies like Authorize.net allow developers to set up the payment gateway and merchant account separately and to do so without storing credit cards on your site.
Hopefully, as payment methods continue to get more and more diverse, we can get away from the high-priced options and get closer to 1% fees for processing payments, but we’re not there yet. However, regardless of the payment gateway/merchant account we set up, the option of collecting payments on your web app is the most flexible choice.
CMS systems like WordPress are great for your “brochure” site. Many, if not most, of the apps we develop at Woodridge use some form of public-facing marketing site, which is often built using WordPress. The Web app that Woodridge will build will typically not be WordPress, as our apps tend to have far more features and are more robust than a platform like WordPress can support. So a very common case is that there are two websites – a WordPress or other CMS website for marketing and the Web App for the technology. This is not inherently a problem and it generally makes the most sense. Since WordPress is relatively easy for a non-technical user to manage, it’s great for marketing. However, your web app generally needs features that WordPress won’t support, so it’s separate. For most of our apps, the end user doesn’t even know that he is going back and forth between the two apps.
So why not use WordPress to collect the payment? WordPress has some very slick e-commerce capabilities that make it easy to collect payment, such as the WooCommerce plugin. With little to no technical knowledge, you can set this up. However, if your app is subscription-based (as most are these days), you now will need to tie in your WordPress database users with your mobile and web app database users, and this is not always seamless. WordPress does have some single-sign-on (SSO) capabilities to make this easier and plugins like WooCommerce do an adequate job of supporting subscriptions, but integrating things like free trial periods and multiple payment options or supporting changes to the main account email start to get tricky when using WordPress to collect payment.
Using WordPress, or a WordPress plugin like WooCommerce, is a valid option and it can be set up quickly. It’s best used if you don’t have a complicated pricing model and are not expecting it to change much. You will still need to set up a payment gateway and a merchant account as mentioned above, but that’s very straightforward. If you already have a CMS for your marketing site and your payment collection plans are simple, then it might be the way to go for your app. However, it’s a choice that comes with the limitations of the CMS, so it’s a decision that needs to be made carefully.
The old school method of simply setting up your customers with an account to your web or mobile app and then sending them an invoice is still completely valid. In fact, we often recommend this to customers who have only a few (1000 or less) customers and whose apps sell for larger amounts ($5,000 or more per year).
If you’re collecting $50,000 from 100 customers, there is no reason to give up 2-3% to the credit card processing companies or gateway+merchant processors like Stripe and Paypal. Simply send the customers an invoice. This is particularly true if your customers are blue-chip types with whom you have a good relationship. You’ll notice there is no payment option on the Woodridge website or those of most custom software development companies.
Another situation where this is a great option is when you’re just starting out. Your pricing model is not proven. Will your subscription idea work or will your customers prefer a one-time license? Maybe you need to charge your customer’s customers, not the customer directly. You can save development costs by starting out with a straightforward traditional invoicing plan. However, you do want your development team to be aware of the different pricing models you’re considering, so when/if you do go with taking payments via the app, your app is built to support it.
If you made it this far, you can see that there are trade-offs with each of the methods for getting money from your customers’ bank accounts into yours. Decisions on how to collect these payments are important and can make or break your app’s success.
It’s important to work with a partner who is able to support multiple payment methods. I’ve seen development shops have their “favorite” payment method and then force all apps they build into it. You need a partner that’s flexible and will do what’s right for your app. Things change. Often, you may think one option is the best when you first plan your app, only to find another option is the one your customers prefer. The right development partner will be flexible and build an app that can change with you and your customers. Regardless of the payment method chosen, it’s key that the user experience is smooth. Forgot Password needs to work, subscription notifications need to be timely and send users to the correct spot to renew. A perfect payment method will feel natural to your user base and encourage them to buy your app and that’s the real goal – creating an app that is successful and profitable.
Tech transfer programs are undergoing rapid change across the country. As the internet and associated applications continue to evolve and create value, technology transfer departments are beginning to branch out from their normal licensing and patenting deals. They’re now seeing software applications, both web, and mobile, as real invention centers, and, even better, they’re seeing revenues grow as these applications are selling across the country.
Many inventions coming from Universities are now ideas and concepts that can best be delivered by a web or mobile application, or the invention requires a web or mobile application to create real value. Often, some internal staff (e.g. a graduate student) has built a prototype, but to bring the application to market, a production version is needed. The ideas are there in every University and now is the time for Tech Transfer groups to harness them and create value.
A major challenge that tech transfer departments face is that finding a Custom Software developer that understands how to communicate with your professors and other inventors can be difficult. The requirements can be complex, or the idea may not be fully thought through yet. Often, the concept is just an idea or group of ideas, and it’s not clear how this new invention will differentiate or be patentable. Sometimes the inventors believe there is great revenue potential, but to get there, the application will need to be made competitive. In order to gain acceptance in the marketplace, applications must be modern and easy to use. All of the above still has to take into consideration the limited budgets available to tech transfer departments. There are not enough funds to build every project, so a vetting of the real business potential of the application is needed.
Unless a software company has worked with these varied needs before and is familiar with the challenges and politics that can arise in the University setting, most projects will fail. Or even worse, go over budget and then fail. A custom software development company needs to be a true partner and understand these challenges.
A success story can be found in the BIMAS-2 project that Woodridge built for Edumetrisis. This invention of three leading psychologists is transforming how K-12 schools do behavioral screening for their students. Read the case study to see how Woodridge worked with the BIMAS-2 team to successfully transition an invention from a university setting to market.
Our aim at Woodridge is to help combine the cornerstones of academic research and great custom software to help bring amazing technologies to market. We can work with your University’s researchers to develop software that will support the products and companies that they’re creating. We want to make it as easy as possible for you to turn your institution’s academic research into great technology products that help benefit everyone.
Whether you’ve had your custom software for five years or one year, there are always things that could be changed or improved. Maybe your user interface needs a facelift or maybe you just want your app to be compatible with your shiny new Apple watch. Either way, now may be the time for a software refresh. Here are some of the most common reasons to give your software a much-needed upgrade.
While it may seem like your software is working fine, there may be some gaping holes underneath the hood that hackers will find. Security is not only about having your software written correctly the first time, but also performing regular updates and maintenance patches. Often, with custom software, the mantra is “if it’s not broken don’t fix it”. But, with security issues, you may not know it’s broken until your data is compromised. Sometimes a simple reboot of the main server is all it takes to keep things secure – a five-minute checkup. However, the best plan is for at least a weekly check-in on the logs, and a monthly or quarterly security patch update.
You chose to build custom software to give you a competitive advantage and because off the shelf software didn’t meet your needs. So custom software was chosen and it’s served you well, but time can take its toll and a refresh could be required. Your company isn’t doing business exactly the way it was when the software was developed and maybe a facelift is needed. A full rewrite is usually NOT the best option. You may be surprised that adding a few new features and freshening up the look might be quite cost-effective. You also don’t need to budget everything at once. Working with a team like Woodridge, allows you to budget monthly changes and fixes as required to help you maintain your competitive edge.
The introduction of wearables like the Apple Watch and Fitbit could mean a world of new possibilities for your already existing app. Wearables act as a pathway to send and receive information to and from your app. You could push out notifications to your users or allow them to send information such as location or voice messages back to your app. Along with hardware advances, new software is being released every day. This means new APIs and new integrations that could make your already great software that much better.
Was your software built for a smaller number of users than you have today? Is your business growing quickly? Then maybe your software needs a boost. Simple things like increasing server size can make a large difference in performance (often for just a few dollars more each month in hosting costs). However, maybe your business is really exploding, then you might need something more for your software. First, congratulations – your business is doing great! Now, let’s make the changes to your software to make sure it can keep up with your growth. If you’re receiving complaints from your users about a lack of functions or slow load times, chances are your custom software isn’t meeting your increased user demand. We can help you upgrade your custom software to work with the current number of users and allow room for growth in the future.
Custom software is helping you to win in the marketplace, giving you the edge you need. Maybe a competitor is nipping at your heels, and you need to recapture your market share. Just like your best people and IT infrastructure, you need to make an investment in your software needs to keep you on top. It’s always better to follow the ounce of prevention is a pound of cure model and keep on top of your software. Small regular updates can mean avoiding complete refreshes every five or so years. However, if it’s been longer than five years, a complete refresh might be the best option. Even if you do need a complete refresh, it can be done in phases. For example, a new front-end can be built on the old back-end which can be updated as a second phase. There are lots of options when deciding to upgrade and choosing a partner that will walk you through them without bias is always the best place to start.