Sometimes you shouldn’t spend resources on a custom software application. And sometimes, you should realize that you aren’t ready to create a software product.
Atomic Object gets hundreds of inquiries every year from people interested in engaging us to build a custom software application or product. Our ultimate goal is help our clients succeed in their business. That means we occasionally recommend deferring custom software, reducing the scope of custom software, or not building custom software at all.
Have You Done Enough Research and Planning?
Startups
We often find that entrepreneurs identify a problem and then shift focus to designing the solution. The product idea begins to get all of the attention. Soon we may get a call to ballpark the product’s cost.
Before focusing on cost or fundraising, it’s better to validate the problem you are looking to solve and the market opportunity related to solving that problem.
Let’s say you wanted to create a product that allows designers to test logo alternatives with their clients’ customers. Before building the application, how might you employ Customer Development practices to validate that designers really have a hard time finalizing logo concepts and that your product will be useful to them?
In addition to ensuring a strong understanding of the problem and establishing positive indicators of product/market fit before building the product, we believe startups should also have the following ingredients to positively influence success:
- Dedicated, full-time CEO
- Adequate funding
- Strong, well-defined customer development and marketing plan
- Researched business model (not a business plan) and financial drivers
- Competitive analysis
We’ve previously described the above attributes in a little more detail in our post about what we expect startups to know.
Existing Businesses
Hopefully, existing businesses have the luxury of funding new product development out of cash flow. Ideally, there’s already marketing and sales channels to exploit too.
Despite existing success, the attributes for startups outlined above apply equally for existing businesses looking to develop a new product or software application. Thinking entrepreneurially inside an existing organization is likely to increase your chances of success. At a minimum, you’ll have a better informed product roadmap and likely spend less cash.
Is Your Business Process New? Can You Scale Incrementally?
Sometimes you should let a new business process mature for a period of time before locking down functionality in a custom application.
At Atomic, 10% of our company’s equity is earmarked for broad employee ownership. Employees invest in our Employee Share Purchase Plan (ESPP) over time. Despite having the ability to create a custom application to track employee membership and transactions, we’ve created a process and spreadsheets to launch the plan with. Our ESPP business process has been running successfully for over one year with the spreadsheet system we created.
The benefit of the spreadsheet approach is that we could be more responsive and flexible to any issues that came up. As more employees participate in the plan, and after we’re confident our process is stable, we may migrate to an application that can provide better automation and reporting.
Are Lightweight Middleware and Automation Sufficient?
Instead of building a fully custom software application, you may be able to use off-the-shelf software combined with custom middleware and automation features.
For instance, let’s say you wanted to create a staffing and scheduling solution for 30 employees. You think it would be great to have an application where a manager could use a web application to select employees and place them in their schedules. Ideally, employees would be able to get notifications and view their schedules for the coming two weeks. Perhaps the web application should be mobile friendly for employees to view their schedule.
Instead of building custom software, you could achieve the same objectives by purchasing Google Apps for business. All employees could have Gmail for email with your custom domain. Employee schedules could me managed in a Google docs spreadsheet that employees have view access to.
If you wanted to get even more fancy, you could create lightweight scripts that push schedule information into your employees’ Google calendars, with email reminders, by using the Google docs and calendar APIs. Google calendar is already optimized for mobile viewing.
The above scenario is just an anecdote, but it illustrates how you can use existing tools and creative thinking to avoid costly investment in less flexible, fully-custom solutions.
If you do create middleware or automate processes, be sure you have technical support readily available. Ideally your technical support is in-house. When evaluating the cost and benefits of support, be sure to consider the costs of system downtime.
Could an Off-the-Shelf Software Work?
Off-the-shelf software is usually aimed at internal solutions. Sometimes, after considering build vs. buy options, it is just smarter to use standalone off-the-shelf software than build custom solutions.
Obviously, you should use off-the-shelf software for things like customer relationship management and accounting packages. Even if these off-the-shelf solutions don’t exactly fit your needs, they are going to be significantly less expensive than a custom solution.
What’s often less known is that there are decent custom workflow and business process automation off-the-shelf software packages available for create custom workflows. These off-the-shelf solutions generally allow business analysts to create powerful workflows and middleware through a graphical user interface instead of having developers create custom solutions in code.
Summing it All Up
When you think you need custom software developed, it’s a good idea to do a build vs. buy analysis. If you can’t buy, can you get away with building something less for now or even in the long term? When you know you need to build custom software, have you done the business planning and market research necessary to validate your assumptions?