Custom Software: Cheaper Doesn’t Mean Less Expensive

I’ve been working in custom software product development for nearly two decades, and I still see people making a common, fundamental mistake when it comes to investing in custom software. The mistake is taking a cost management mindset instead of a throughput optimization mindset, especially in the first few phases of product development.

No matter if you are hiring an internal team or external partner, I don't recommend shopping for the lowest cost. Instead, work with teams optimized for throughput while also making sure you are paying relatively on-market for that type of engagement.

Optimize for throughput and shortening time to revenue.

The physicist and Theory of Constraints guru Eli Goldratt wrote extensively about the cost/throughput tradeoff in his book Critical Chain. He noted that most business leaders receive training and practice in the cost mindset.

The cost management mindset makes sense from a limited perspective. The lower the upfront cost, the higher the return. However, cost management resulting in delayed delivery negatively impacts the return on investment. From a financial perspective, it’s like comparing the Net Present Value of two investment streams where one investment has a higher initial cost but gets to revenue sooner. A lower-cost option with a longer investment and return timeline may not compare as favorably especially if there are other risks like poor quality that could continue to reduce or delay sales.

Invest in non-recurring design and engineering now and manage non-strategic costs later

When you zoom out and examine the entire value stream of outflows and inflows over time for a custom software product, you will notice that the initial investment in software development during the early phase constitutes a one-time cost in non-recurring engineering. In alignment with Mike’s Truth #1 of Software Projects, once in the market, the product will still need continued investment in new features, maintenance, etc. Companies make continued investments after revenue starts coming in, product/market risk decreases, and technical risk has been significantly reduced.

Of course, there are other costs, from marketing and sales to support. In the later phases of building and managing a software product, you can optimize costs for non-strategic expenses while still optimizing for throughput on strategic expenses that directly grow or protect near-term profits.

Optimize for throughput in the early phase of developing a software product. This is a smart move because you get to product-market fit faster and make revenue sooner. The early phase investment in non-recurring engineering establishes the foundation for the entire profit engine you are working to build.

Atomic focuses our core software product development approach on throughput to deliver the highest value to our customers. Our approach includes:

• Human-Centered Design + Agile Development and Continuous Delivery
• Being a Regional Partner
• Working In-Person
• Delivery Leads and Dedicated Teams
• Quality

Human-Centered Design + Agile Development and Continuous Delivery

Integrating Human-Centered Design (HCD) with agile development and practicing continuous delivery is all about constantly getting a functioning product in front of customers as quickly as possible.

This means we don't accumulate a significant amount of unvalidated work-in-process.

Integrating HCD reduces product-market fit risk and enables immediate design responsiveness in case changes are needed based on customer feedback during early development or product launch. Given Mike’s Truth #2 of Software Projects, you’ll know more tomorrow, and changes will be inevitable.

This approach creates business agility too. The business can throttle investment at any time and still have a functioning product that is of some value.

The integrated design and development approach recognizes the value of continuous improvement and responsiveness vs. the approach of creating a large amount of work-in-process with a design phase before moving to the development phase that could be cost-optimized with less skilled developers.

Being a Regional Partner

Working collaboratively and in person with business stakeholders during kickoff and other foundational points during a custom software project fosters innovation, ensures alignment, and brings a better product to market faster.

With our four physical offices in the Midwest and Southeast, we can more closely collaborate with our customers in person. This works well for both local customers and customers that are only a short flight away.

Being close and working in person eliminates the friction and frustration of working asynchronously or with very limited time zone overlap for synchronous collaboration.

Working In-Person

In early-stage software product development, cross-disciplinary, creative, and collaborative work is essential. Talented practitioners working together in a shared physical space create better solutions more quickly,

• Teams generate better ideas and solutions that balance desirability, viability, and feasibility more quickly.
• Teams avoid or address bad ideas and mistakes earlier.
• Awareness, learning, and alignment at the tooling, process, and product levels happen faster and more effectively.
• Every day, teams reinforce trust and cohesion.
• Teams have more fun, fostering creativity and momentum.

I believe these points are facts based on human nature. This is partially why Atomic committed to keeping our offices and coming back to in-person work after workplace shutdowns driven by the covid-19 pandemic had ended.

In 2020, Mike and I clearly saw how working in person would give Atomic a major competitive advantage over other software product development consultancies that transitioned to fully remote companies during the pandemic.

We have been back in person since mid-2021 and are working in a structured hybrid fashion that is driving higher throughput and individual thriving. The value we can deliver is much greater than any remote consultancy could hope to do.

As a U.S. customer, I would rather hire an in-person consultancy in a remote location and live with those risks and tradeoffs than hire a remote U.S. consultancy at U.S. rates.

With respect to remote work advocates, I do believe that remote work is a very reasonable approach for routine, transactional, or pure individual contributor work. It’s just that early-stage software product development is none of those things.

Delivery Leads and Dedicated Teams

Goldratt’s Critical Chain argues the most common reason for project delays is a lack of focus from the project leader. I agree with Goldratt given my professional experience.

When the project leader is distracted:

• Requirements don’t flow as well.
• Roadblocks don’t get cleared as quickly.
• Important dependencies get missed.
• Detailed work sequencing gets glossed over.
• Risks aren’t well identified or managed.

Software engineering work is usually the bottleneck of new software development projects.

We created the delivery lead job to support a customer’s product leader with consistent, focused capacity on managing the cross-disciplined team for high throughput by executing well on the points above.

The delivery lead manages the flow of work through requirements, design, and then software engineering. We complete the requirements and design work just before the software engineering work, ensuring high throughput through the bottleneck, rather than having developers idle or working on non-priority tasks.

A dedicated team is also highly valuable because they remain undistracted by other projects or operational tasks.

For enterprises going through digital transformation or desiring to create new digital products, investing in a dedicated team led by a focused delivery lead is more effective than trying to use a team that has other operational responsibilities.

Quality

Mike’s #3 Truth of Software Projects explains that quality costs more and takes a little more time in the short term, but investing in quality allows for low cost, greater throughput, and responsiveness in the long term. Investing in quality is a wise decision if you are serious about building a valuable, long-term software asset.

The cost-management-driven mindset can lure people into buying low-quality work that gets worse like a slow boil. As time plays out and complexity increases, the low-quality solution will take longer to update and updates will cause problems. Low-quality software often fails in day-to-day operations too. The team gets less new work done due to endless break-fix cycles. For some products at scale, a bug could have financial consequences far beyond the annual salary cost of a top-notch US-based software developer (I’ve seen this happen with a team that wasn’t doing test automation on pricing logic).

Atomic has continually optimized for quality. At first, our focus was on technical quality and we expanded our view of quality to other dimensions like design and product development.

Examples of our quality practices include:

• Hiring people who have appropriate academic and/or professional training and experience.
• Fostering a culture of continuous learning and being the best at your craft.
• Investing time and money in the professional development of our people.
• Product development and design practices that help ensure we are building a desirable product.
• Working closely together at the system, application, and feature levels.
• Working as full stack developers and not allowing silos of ownership in code.
• Test-driven development and test automation.
• Deployment automation.
• Exploratory testing by highly skilled quality analysts.

Considering the Tradeoffs and Risks of Going Cheap

If others make a cost management argument for early-stage non-recurring engineering, I recommend building a more comprehensive tradeoff analysis that considers the risks inherent to lower-cost options. Low-cost provider risks may include:

• Much later to market and revenue.
• Extended timeline driving higher cost and opportunity cost from your leadership team's time.
• Lower customer conversion and/or retention once the product gets to market.
• Quality issues that are so bad, a rewrite is necessary.
• Data loss, financial loss, etc. that comes from bugs or security issues.
• Continued time loss and opportunity cost due to the inevitable debate about throwing good money after bad on a different low-cost provider or finding and selecting a high-throughput provider.

If you are considering investing in custom software development, I encourage you to consider and model the investment from a throughput optimization perspective, especially in the first six to 12 months of development.