Software is eating the world.
So wrote noted tech innovator and venture capitalist Marc Andreesen in August 2011. It’s been over six years since then. Was Andreesen right?
Ask your local taxi company or hotel chain. Since Andreesen penned his famous article in The Wall Street Journal, Uber, Lyft and Airbnb have risen to disrupt entire industries with software. Etsy became a $3 billion software company by providing a marketplace for handmade, bespoke goods. That’s currently twice the value of JCPenney.
If you aren’t in the software business, you probably will be soon. That’s where Atomic Object comes in. In this post, I want to demystify the process around building custom software by give you a window into what we do every day. My goal is for you to walk away with a deeper understanding of what it takes to build a software product.
This post will focus on three areas:
At Atomic, we’re passionate about sales because we think we do a really good job of finding clients who need our help and who are a good fit for our organization.
Unlike other organizations, we don’t have any dedicated salespeople. Instead, the managing partners at each of our offices form our sales team. We’re all software design and development professionals with more than a decade of practical experience in the industry. We aren’t incentivized by commissions. We just want to find projects where we can provide real, measurable value.
Our sales process begins with the inquiries we receive, which for us, is about 300 per year. From there, we schedule a triage call with one of our managing partners to find out if the potential client has a project where we believe we can find success.
Next, we set up a meeting where our managing partners–not salespeople–talk about the project. These are experts who have built dozens of software products themselves. During these meetings, we’re seeking a good grasp of the industry vertical, the scope of the project, and the experience of the potential client. We also look to add expert consultative value, all free of charge.
From there, we begin to build a ballpark estimate. Our goal is to be “in the ballpark” of a budget where the project can find success.
Budgeting a custom software project is a very tricky thing. We are always estimating at our point of maximum ignorance. We will never know less about your project than we do when we build that initial budget model. So instead of trying to come up with an exact number in exchange for an exact scope of work, we work together to agree on a budget that will fund the project to success.
We work on projects that have a fixed budget and a controlled scope. In any project, there are three levers you can pull to get more things done. We could pull the quality lever. We could write less automated tests, review less code, and fly by the seat of our pants a little bit more, but we refuse to do this because it compromises the software over the long term.
We could pull the money lever. We could ignore budgets and just keep building until your capital dries up, but this doesn’t make sense for anyone. Our clients shouldn’t spend money they aren’t sure will return value for their investment. Over 60 percent of our revenue comes through repeat business, and we don’t want angry clients!
The last option is the scope lever. This is the one we think is most effective to keep projects on budget. We help our clients plan phased releases of functioning software so that they can progressively test the ROI of a product for their company without going over their initial budget range.
Atomic creates between 80 and 100 of these ballpark estimates each year. We approach this process as a collaborative exercise with you. We even give you the budget model in an Excel spreadsheet. You could take that budget model and go to another company if you wanted. We give this service away for free.
This process helps us find the projects and clients where we can provide a good fit. As an organization, we have capacity for about 30 new projects a year, including 10 to 15 new clients.
In each of our projects, we begin with a design engagement that ensures we’re building the right software. How awful would it be to spend hundreds of thousands of dollars, only to find you’d built the wrong thing?
But who decides what the right thing is? You–along with the market. Therefore, we work with you to find the intersection between your business needs and user goals.
During this phase of a project, we run kickoff workshops with you, your customers, and potential users of the product we’re building. We hypothesize about possible user goals, research prospective users, and test theories. We dive deep into your vertical so that we can make smart, relevant decisions on your behalf. Throughout this process, we invest just enough time to let users and clients guide the form of the features in the software we are building.
Once we have a good idea of what we’re building, we’re ready to start making software! At Atomic, our software development process is the product of a combined 550 years of cumulative software experience. We take pride in always seeking to improve our process for our clients and our teams.
We have our own flavor of Agile process, with its own tools, roles, and meetings.
The first tool we use is the sprint, a two-week, repeating timeframe in which the team plans detailed work and presents accomplishments to you.
During the sprint, we work on user stories. A user story is a feature that adds value to the software product. Each story includes an estimate of points which the development team assigns to represent the perceived cost to complete the story.
All of these stories go together to form a product backlog. The stories are collaboratively prioritized by our team leads and you. We organize that prioritized list around milestones relevant to your business.
After a few weeks of work, the points completed create a team velocity. This velocity lets us forecast how long it will take us to complete the project. We transparently share this forecast with you, surfacing risk and possible mitigation scenarios to you. Rather than hiding risk, we believe in talking about it early and often so you can stay informed as you make decisions concerning your project.
Every project at Atomic has a team lead known as a Delivery Lead. This person is our client’s consistent point of contact.
Delivery Leads are tasked with three big responsibilities:
The Delivery Lead is the head of a product team. Teams vary in size depending on the budget, scope, and timeline that make sense for you and your business.
The last and most important role is you: the key stakeholder. You possess a special ability we don’t have: You can make business decisions on behalf of the project to ensure we stay on target. You are a key part of the team, but don’t worry–we know you have other responsibilities, and we don’t expect you to be available 100% of the time.
We always strive to keep our meetings relevant, just long enough to provide value, and only attended by the people who need to be there.
The shortest and most regular meeting is our daily standup. The focus is on understanding who is doing what, asking for help if needed, and taking any problems that surface to another venue. It’s a daily way of maintaining forward velocity and awareness.
Next, we have bi-weekly sprint reviews. In these meetings, we have the Delivery Lead and the product team, joined by you, our key stakeholder. The focus here is on showing you completed work to gather high-level feedback and validate that we have completed the work as expected.
We provide project updates in PDF form, in tandem with review meetings. These PDFs are a helpful resource for keeping everyone in your organization up-to-date without requiring everyone to attend every review.
After review, we release the work in small, incremental steps toward a finalized, working piece of software.
During our two-week sprints, we engage in backlog grooming with you. Our focus is on getting the backlog estimated, clarifying our user stories so they are ready for development to begin, and gaining alignment between you and the team about any future work to be done.
To bring this back to our starting point, if you aren’t in the software business now, you probably will be soon. As you look at your business and how you will thrive in the 21st Century, you need to think carefully about how to engage with technology.
It’s easy to understand why tech entrepreneurs want to hire and run their own software development teams. When you only compare the hourly rate of a consultancy to the hourly rate of a few employees, working with a consultancy looks to be a lot more expensive. What this comparison misses is the hidden cost of recruiting, hiring, and managing employees.
Building a happy, productive team of software designers and developers from scratch is not an easy undertaking. If you factor in the chance that you might fail in that challenge and consider the risk of that failure to your business, finding a reliable, long-term partner starts to look pretty attractive.
Of course, companies that rely on software for their business can’t contract out all of their software development. We advise clients who are making an entrance into tech to make an early hire, and embed that person in our team as we prepare the first release of the software. We’ll even help our clients vet candidates.
This hybrid approach allows you to hire a less experienced developer, have them trained in our process and practices, and feel a sense of ownership of the code base. This developer will remain highly responsive to your needs after the team finishes the heavy lifting of the first release.
If you’d like to talk about what hiring your own staff would take, get in touch. We’re happy to share what we’ve learned in the last 16 years.
If you’re looking for a smart, passionate team of highly qualified experts to partner with, don’t hesitate to reach out. We’re excited to talk about your software needs.
We’ll send our latest tips, learnings, and case studies from the Atomic braintrust on a monthly basis.
