The 10-year approach to building software
Check out this column in Forbes:
Many of us have a great idea for an app or software solution. I have a few friends who have shared with me their ideas for technology that would make their businesses run better, but they don’t know if getting the idea off the ground is realistic.
I can relate. This is the position I found myself in more than a decade ago at Bernard Health, the benefits brokerage I started with my brother in 2006. We made similar observations about software tools that would optimize our workflows and make things easier both internally and for our clients. This idea became BerniePortal, a leading HR software platform for employers with 10 to 500 employees that is now a bigger part of our business than the brokerage it grew out of.
Building a software product to serve the needs of your business and businesses like yours is doable, and you don’t have to raise a ton of capital from Silicon Valley to do it. However, it certainly won’t happen overnight -- or at least it didn’t for us.
In fact, though BerniePortal is the biggest part of our business today, it took us over a decade to get here.
We were inspired by software developer Joel Spolsky, who wrote an essay called “Good software takes ten years -- get used to it” in 2001. The gist of the essay is that good software code takes a decade to develop as you work through the first few iterations. According to Joel’s essay, when building a software product, you want to be careful not to overhype or get big too fast and underwhelm your customer base.
“Make a ten-year plan,” Spolsky wrote. “Don’t get too hung up on your version 1 and don’t think for a minute that you have any hope of reaching large markets with your first version.”
I don’t know Spolsky personally, but his insight had a big influence on our team.
So what did those 10 years look like for us? Here’s how we thought about building and selling software, and how others with great ideas might think about going down a similar path.
Designing The Idea
The first step toward turning an idea into a functional software product is getting the idea on paper.
I started by talking to local development companies, and one offered to design the project for a much lower fee ($2,500) than our full project budget of $15,000. They would design the project, then bid on building it. If they came in at a higher rate than others in the market, I could take the designs elsewhere for other bids.
Spoiler alert: While they produced a beautiful set of designs, when it came time to bid on building it, they were about 100 times higher than my budget. We didn’t end up using this firm to build the software, but the designs they created were critical to getting the project off the ground.
Think about it like hiring a contractor or architect. If you want to renovate a house, it’s a lot better to hire an architect to help plan and draw blueprints than to just start knocking down walls. Similarly, it’s easier to workshop your concept design first, and it’s much easier to make changes on paper than in code.
A good designer will build annotated images of your product to show the product interface and describe what each button or feature is supposed to do. You could try to accomplish this first step on your own, but an experienced designer will have good ideas that should ultimately lead to a better product.
Building The Product
When the local software company’s initial bid came in so much higher than my budget, I posted the project on an online software development site and received bids from all over the world. We ended up selecting a firm based in India, which built the first version of our product.
In retrospect, working with this Indian company was ideal because, at the time, I was still working full time as a benefits broker. The time difference allowed me to work with our development team during “off hours” in the United States without hurting my existing business.
Many entrepreneurs think they need to find a local developer to work with face to face, but we did not find that to be the case.
However, whether your development team is across the world or across the office, don’t underestimate the need for good communication when it comes to building product functionality. Be precise, because anything left unsaid is an invitation to constantly rework the product.
That said, stick with your development team and understand that development timelines are long. Even big companies experience delays, but keeping in line with the 10-year approach, we found that patience produces better long-term results than development turnover.
Incubate, Then Distribute
For years, we only used our HR software platform internally. It worked well when we controlled all aspects of the experience, and this allowed us to work through the product’s early growing pains. We made improvements little by little for eight years before distributing it via other brokerages.
During this time, competitors like Zenefits and Maxwell Health raised lots of money -- almost $600 million and close to $55 million, respectively -- but Spolsky had predicted things like that would happen during the 10 years, and we stayed the course.
Think about widening product distribution in stages. Consider internal use as the first stage, then have your closest customers -- those in your personal business network -- use the product. Finally, distribute it more broadly.
Ultimately, distribution timing for us was based on a combination of steady improvements as well as the capital raised by our competition, which brought market attention to the need we were trying to fill.
There may be many ways to go about designing, developing and launching a software product -- Joel Spolsky’s ten-year approach worked well for us.
Check out this column in Forbes: Over the past few years, there has been a proliferation...
Check out this column in Inc. Entrepreneurs know that competition is part of the...