ฺBuild, Buy or Borrow? The Do's and Don'ts of 1st time software builds for scaling organisations
A client of ours, let’s call her Hope, was at her wits end. She and her business partner had scaled their business very quickly and needed help. They realised that their administrative overheads were stopping them from scaling further, their staff were left doing repetitive tasks and their business started to struggle. So, Hope had an epiphany:
“It struck me that what we needed was a self-service client portal. Somewhere our customers could upload their data and have it safe, secure, and available; and cut down on the mindless data validation back-and-forth with our consultants.”
Hope looked for a third-party outsourcing company to help her build the software she knew would free up valuable time. On our first call, she brutally laid out the issues as she saw them.
“Ramji, I’ve spent 4 years trying to get this portal product over the line and useful. We’re on version 2.1 now, and I’m on my third software vendor. I can’t count the number of hours I’ve spent, the tens of thousands of dollars, and the opportunity cost of our time. Not to mention, for some reason, I don’t feel like a client, but feel like I’m their full-time project manager!”
She recalled that her first outsource partner built portal1.0 using one stack of technology, but when she was unable to get what she needed to be done with them - the development team from her second software company insisted on building it from scratch again using a different stack.
“Now this third vendor told me to rebuild it again. I don’t understand why they keep asking me to start from scratch again, I literally just did that 12 months ago!”
What Hope experienced is the same thing thousands of entrepreneurs experience in their first ‘software delivery’ experience.
As a business owner, you understand the risks you navigate to grow and thrive your company. But then you come to building your own software and enter the semi-theological environment of software development. An entirely new language is needed just to be able to understand what’s happening. On top of running your business, that’s struggling to scale - you’re expected to learn catechisms just to be able to communicate and spend hours staring at ticket screens.
Fortunately, you receive a call from an online SaaS provider who has the perfect solution for you? Perhaps, this is the way out of the maze? For just $10/user/month no less!
Ramji Venkateswaran, https://www.abetterconsultancy.co/
In fairness, for many people it is the right answer, and it should be! To explain why, I want to introduce two key concepts.
Differentiating Value & Prioritising Constraints
- Focus on your differentiating value. What activities differentiate your business and make it stand out from all the others. If something is differentiating, you should probably throw everything you have into doing it – building it yourself with your own team if needed. For anything else, get someone else to do it, even if you can do it better. This isn’t a new idea, it’s a digital evolution of the economic principle of Comparative Advantage, first published by David way back in 1817.
- Prioritise optimization at the point of constraints. If you have a process, system or software product that is constraining you from gaining more revenue or ballooning your costs. Apply time and effort to optimise that constraining factor more than anything else. Whatever makes sense, outsource, build or buy, focus on finding solutions to that problem – focus applied elsewhere is mostly wasted effort, time and money.
You will often get bad advice with good intentions.
A plethora of freelancers and agencies will tempt you into believing you too can have your own hardened, scalable high performance custom system for your business, friends and colleagues will tell you that you need a mobile app, or a portal, or that you need to do rebuild with microservices.
None of this hopeful advice is entirely false, but it’s certainly not entirely true either. As someone who’s been building, architecting, and delivering high-performance reliable technology systems for 25 years, and advising on what and how to achieve optimal outcomes in this area for many years; I’ll state it as plainly as I can: building high performance, secure, scalable, resilient, and effective systems is difficult, expensive, and time-consuming. It’s also probably not worth it for 50% of the people who undertake the challenge of doing so. To build software incrementally, so it scales with your business, but initially isn’t an over-engineered monstrosity, is harder. Agile does not mean facile.
I don’t say this to berate or belittle - rather to celebrate and illuminate those who go ahead and do it anyway. Despite all the setbacks, complexity, and challenges, Hope dragged her version 2.0 over the finish line - only to discover that it still didn’t get her what she wanted.
I’ll summarise a few bits of key advice:
- Build, Buy or Borrow - it doesn’t matter, each has its nuance and challenges. It doesn’t matter what technology stack you use, or whether you build, buy or borrow - or whether you’re waterfall, agile or non-denominational! The reality is that it is hard to effectively get value from your technology spend without a clearly aligned and prioritised Business Strategy, a clear Product Vision that sits within that Strategy, and a clear Technology Vision and Roadmap to deliver that Vision.
- Words have meaning - and human beings communicate best when we remove ambiguity and use the same words to mean the same things. Your Business Strategy, Product Vision and Technology Vision need to be able to be read by everyone involved in your project and their meaning must be self-evident without the need for ‘mental translations’. Use your business strategy and Product Vision to define and adopt a common taxonomy, Information Architecture and Data Model that is coherent with your business operations, plans, and communications.
- Think, then act. User Research, Product & UX Design and Technical Analysis & preparation pays off. It might seem like an expensive up-front cost, but don’t start building your house without spending time understanding why you want a new house, what it would be like, and thinking through the consequences of your new abode! LEAN Agile is a mindset adopted for delivering software projects, it is not a recipe for delivering a piece of business functionality.
- The complexity goes somewhere. Whilst there are genuinely transformational technologies that have been adopted over the course of human history, ultimately any complex human activity that is turned into a process, which is turned into a program or series of programs trades off an increase in systemic complexity as a cost, in favour of an improvement in performance, throughput or reach as a benefit. There is no magic, there are no miracles. The complexity goes somewhere. Just because you can’t see it, doesn’t mean you won’t have a critical ‘OH NO’ moment, once you realise that your spiderweb of integrated but loosely coupled SaaS products unintentionally now have some critical revenue functions and you’ve outsourced not just your operational costs, but your operational risk.
