As Bob Dylan once said, “Times, they are a-changin”. I think we can all agree none more so than right now.
Digital banking has never been so vital as right now. According to McKinsey, the “pandemic has accelerated the shift to digital banking by two years”. The focus, of course, has been on meeting the immediate needs of customers through more digital services. With many branches still closed and others limiting the number of customers allowed at one time, digital banking is the only option for many.
Many banks already offer common transactions through online or mobile offerings: balances, transfers, bill pay. Yet there are many services still not offered digitally. This pandemic has forced digital bank services to take on more volume than anticipated. Some banks were not ready. Some were.
In an interview with Bloomberg, David Tyrie, head of digital banking at Bank of America, stated, “When corona hit, it turbocharged already-accelerating growth. We expected that we were going to get a whole bunch of new customers. We really didn’t expect the magnitude.” Bank of America recently released some interesting numbers related to its virtual assistant, Erica.
Providing an excellent digital customer experience and offering digital services ahead of your competition can increase your customer base and shift more transactions to digital. It also results in cost savings, as digital transactions are less costly than manual ones. These trying times have highlighted the importance of continually innovating your existing digital customer experience. Woodridge Software can help you develop best-in-class digital banking experiences and get to market faster, whether it be new implementations or development of existing ones.
Customer behavior has shifted, and the impacts will be long-lasting. A recent survey by fintech company Novantas revealed only 40% of respondents expect to return to branches post-coronavirus. It is never time to stop expanding your digital banking offerings. Don’t let a pandemic be the reason to innovate. Let us help you with your development needs in:
Woodridge Software is proud to have already helped over 150+ financial institutions through these troubling times. As one banker told us, in regards to our work with his bank on the PPP program, this has been “the most important work in his time”. The “new normal” is still being defined but we’re ready to help you now and into the future.
Due to the unique business challenges that software developers face, such as rapidly changing project scope and tight budgets, unique management strategies must be employed to stay afloat and deliver a quality product. The way that developers approach the software development lifecycle can generally be broken into Waterfall and Agile development.
Waterfall was the first major product lifecycle approach created specifically for software, developed in 1970 by Winston W. Royce. Waterfall is the most relatable to leaders in other industries, as it is more rooted in traditional business practices than Agile. Waterfall is not dissimilar to the process of building a home, each piece is taken sequentially and builds upon the last. Just as contractors start building a home by laying the foundation, then erecting the framing, then adding plumbing, waterfall development follows a direct path to a final product starting with design, then moving through implementation, then verification before launch.
Agile development is a more modern view of the software development lifecycle outlined in 2001 by The Agile Manifesto. Rather than viewing development as a series of tasks that must be completed in series to create a final product, agile development focuses on developing a working product as fast as possible, then iteratively improving and expanding it until it satisfies the end user.
Image from https://lternet.edu/?taxonomy=document-types&term=databitsissues/624
Traditional businesses follow waterfall practices by necessity. To continue the metaphor, if, after a house is built, the homeowners decide they don’t like the floorplan or the location, the house would need to be rebuilt completely, with roughly the same resource cost as building a completely new house. Because of this, contractors focus on building the house exactly right the first time. Software doesn’t need to be developed this way because any aspect of a program can be altered by an engineer with relative ease, it makes sense to build a rough version of the project, gauge its efficacy, then make changes as necessary. Software is unpredictable enough that the first version of a product is rarely optimal, which is often troubling to waterfall developers who focus all their resources on building the software right the first time.
Several sub-strategies have been developed to assist the implementation and efficiency of Agile development, the most popular of which being Lean, Kanban and Scrum.
Lean development can be seen as an extension of Agile practices, focusing on cutting waste by avoiding producing unnecessary features, minimizing how often developers switch tasks and promoting effective, face-to-face, communication. Lean development also encourages waiting until the last moment to make decisions, so as to minimize backtracking if the factors contributing to that decision should change.
Kanban translates roughly to “billboard” in Japanese and was initially developed by Toyota engineers to increase project efficiency. Kanban involves a traditionally physical board with three main sections, “To Do”, “In Progress”, and “Finished”. These categories may be further broken down, for example, “To Do” is often broken into high and low priority. Tasks are then written on cards and placed on the board, and developers move these task cards across the board as they completethem. Kanban is most effective when a large group is working on a single project, as it is effective at breaking a large project into smaller pieces and tracking the progress of those tasks in a very simple and visible way.
Image from https://www.verbindungszentrum.com/scrum-en/
Scrum provides a more definite framework for the iterative process outlined in Agile development. Scrum developers work in sprints of 2-4 weeks during which they plan, build, test, and implement a new version of a specific piece of software. After the sprint, the team then meets, generally with their client, to review the software and plan the changes to be implemented during the next sprint. Short daily meetings are generally also held, to discuss progress and any major challenges or roadblocks that may have appeared. Scrum is generally most effective for small teams seeking fast, efficient, and effective development.
As outlined in our process, at Woodridge we have found Agile development, when paired with Scrum and Lean principles, to be the most effective strategy, as it allows for rapid prototyping and increased customer satisfaction, as their input is valued and implemented throughout the entire process.
Because we are centered around developing software for third-party businesses, using Agile development principles allows us to easily adjust to their needs as no feature is ever “finished” or set in stone. Biweekly sprint meetings and weekly check-ins give us an opportunity to receive feedback and meaningful insight from our clients on a consistent basis. In a traditional Waterfall environment, we wouldn’t be able to provide a working prototype until the project was nearly finished, but with Agile and Scrum techniques, our developers provide a new, improved, prototype every two weeks.
The modularity of agile development also allows us to turn on a dime if project goals shift by allowing us to apply existing code to a new end, rather than completely scratching a project and restarting like is sometimes necessary with waterfall development.
“Should I invest time learning a new software tool? Or, should I just build my own?” These are questions I encounter regularly as a software developer, but these questions are also relevant to any individual or company trying to make their business more efficient. Software tools are programs that developers use to create, debug, maintain, or support other software applications. These tools are intended to make your workflow quicker and smoother, but sometimes they just eat up your valuable time. If your tool falls into that latter category, you may need to find a new solution or build your own.”
First, you need to know your tools and your development options. If you’re having a problem with a common development process, there might be a solution that already exists. Software tools should help make your internal processes smoother. As you evaluate tools, make sure you stay up to date with all the functionality that’s available.
Obviously, documentation and tutorials can be helpful to make sure you understand the basic functionality of each option. What’s less obvious is understanding the intention behind various features. For example, you can use a hammer to slam a screw into a piece of wood, but with more effort than necessary (and with some unintended side-effects). The same concept applies to software tools that are being used in ways that they were never intended for, which can lead to issues down the road, if not immediately.
When evaluating the efficacy of your tool, you need to think about the areas where your current tool doesn’t accomplish what you need it to, and areas where it causes more pain. Once you’ve identified these pain points, you may have to work around or against the tool’s features. If your process doesn’t match your workflow, then make note of the differences. Documenting your pain points provides insight on whether to choose a new tool or to develop a custom one.
Woodridge uses a variety of frameworks and technologies including Vue.js and Laravel, which were chosen because they lacked the pain points of previous frameworks and technologies. For example, the PHP framework used on some of our older projects made interacting with the database a hassle – the defaults were non-intuitive which ultimately led us to work against the framework. Laravel’s Eloquent ORM made handling data much smoother and its object-oriented solutions made it easier to accomplish simple tasks.
Once you know your tool and have identified your pain points, you may decide that your current software tool doesn’t fit your needs. If you find a tool that resolves your pain points, those which you absolutely need to resolve, then it’s worth exploring a pre-built solution. However, if you look at your tool’s features and foresee several custom modifications, then a pre-built solution may not be the right tool for you. In these cases, you should consider building your own software tool.
The right software tool can make your life easier, but the wrong tool can have the opposite effect. Choose wisely and constantly evaluate your options.
Chad Eatman is a software developer 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.
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”
or
“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.
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.
As Woodridge Software has gotten busier, we have of course added staff, but we’ve also raised our rates. I think this is a natural response to having more potential work than we can perform. As we’ve done this, I’ve discovered something that was counterintuitive, at least for me: often, it is easier to sell a project at a higher rate than a lower one.
The reason for this is that for many prospects, price conveys quality. Prospects figure, “They charge more, so they must be better.” I would say that this is loosely correct: if you find a cheap developer, there is probably a reason he or she is cheap, and you get what you pay for. On the other hand, if clients keep coming back to a developer or firm that charges more, those clients must have some reason for doing so.
Unfortunately, the correlation is only loose, and is ruined by sub-par firms that have figured this out. These firms charge more because they know some prospects will assume they, therefore, do good work, but the firm regularly does a poor job. As a prospect, it can be very hard to deduce which firm is which.
So, to prospects, I would offer two pieces of advice. First, don’t be afraid of a higher rate. It probably means the firm’s quality is higher, and a higher hourly rate can produce a lower total project cost if the developers are sharp and experienced. Higher-quality development means the product better meets the needs of users, is built right with attention to detail, and stands the test of time.
Second, don’t trust the price alone when assessing quality. Instead, look at the bios of the team. Ask to see examples of previous work, and importantly, talk to former and existing client references that the firm provides. Ask the team whatever technical, or at least application-related, questions you can, and see if they speak and answer intelligently. This gives you the greatest chance of deciding whether price does correlate with quality, or if the firm is an outlier – hopefully in your favor!
I read a recent Wall Street Journal blog that declared:
“The pendulum is swinging away from packaged software and rented software as a service. Instead, companies from Tesla Motors Inc. to Facebook Inc. are writing their own software in key areas that give them a competitive advantage.”
The blog stated that the efforts go beyond building a mobile app, to critical back-office applications that involve some internal business process. In my opinion, a custom software application should be a last resort. I am often advising clients who ask if we can build this or that, “Yes, we can, but have you looked for a packaged solution that does most of what you want?”
Typically, an off-the-shelf solution will be cheaper to buy and own than hiring us to build a custom software solution. That being said, if a client or prospect has searched for something that does what they want and comes up empty, custom software can be a good choice. You get exactly what you desire, with none of the compromises that you often have to live with when buying packaged software.
And if the app creates a competitive advantage, building a custom system could revolutionize your business. We’ve seen that several times with our clients. So, I don’t know if the “pendulum is swinging,” but I like the trend!