Evaluating Foundational Risk

Software foundation

Catapult is in the business of valuing companies, projects and assets. Of great interest are the risks associated with the stability & integrity of a revenue stream. In the context of early-stage software we care about process and quality, as without either we will discount for customer satisfaction and scale risks for example.

Below is an example of an advisory conversation we have had with start-ups looking to raise capital. A company that has taken a majority of the topics into consideration will see less of an impact on our view of 'specific company risk'.

Consider the Fundamentals. So, you have a concept for a software application, a small team that includes an engineer, and you've made use of existing tools and open source to create a working prototype. Before going too far along, think about taking the time to professionalize your project, to support it with fundamentals that will provide stability on scale.

Product Fundamentals. This is the fun, externally facing part. You are going to want to create a Product Vision statement. Make it short. Who is going to buy your product? Who are the users? Whose needs is the application going to satisfy? What are the attributes of your application that satisfy those needs? How does your product compare against existing applications? Does your product have unique selling points? How are you going to deliver the product? What is the price? What is your target timeframe and budget to get to a beta launch?

Consider a few tools, deliverables, artifacts to help create the vision for your product. Elevator pitches to different users. A business model that highlights potential tradeoffs your company may have to make. Create a blog entry, or a press release. What do you want people to hear about your application? Create a prototype. If you are in alpha or have a beta running, then get feedback from your users. Give names, identities to your different users. Describe how your product will influence their lives. What about a product roadmap, and release plan? Create a parking lot.

Process. This is the hard, internally facing part. Look to define the different ways your internal processes support quality. Think simple, light policies that describe such attributes as reliability, efficiency, maintainability, testability, flexibility, etc. Quantitatively measure one or two. Create standards; can you defend the status of your application against them? From the perspectives of production and customer satisfaction, what is the performance of your development process? Can you defend what (and why) you sacrifice when project variables (scope, schedule, resources, quality) change? It’s a closed system – if one gets bigger, the other gets smaller. How do you intend to define process variation? How do you manage defects? Verification and validation? Have you started the process of automating testing? Do you have the cost of Quality built into your financials; it’s ~50% of your development budget. When you deploy, keep in mind that the tactical portion is 3-10x more expensive in both time and cost than the design phase.

ABOUT. Dustan is founder and principal of Catapult Intelligence, an independent valuation and advisory firm providing professional service organizations and small businesses with business, product and asset valuations in corporate strategy, transaction and tax contexts.

Featured Posts
Recent Posts