Consulting as analogy while
bootstrapping your B2B SaaS
13 June 2020
Properly framing how to think and talk about a business model while bootstrapping your Software-as-a-Service (SaaS) company builds upon “consulting” as an analogy.
With three straight-forward stages, build revenue while increasing the scope of automation. After that, there would be no further need for the analogy.
This approach has been used by successful business-to-business (B2B) entrepreneurs in various locales, but it may not be for everyone. This is likely inappropriate for consumer-facing (B2C) offerings or where margins are very low.
Being funded by revenue means you take as little seed funding as possible and ideally none at all.
It also means that you eliminate the need for angel investors and venture capitalists such that should you choose to grow by using that path, you will be in a much stronger position when negotiating terms.
Alternative paths such as most fabled Silicon Valley genius-founder successes often involve factors omitted from common telling of those stories. People with close knowledge of key participants in various darling companies revealed direct ties between family of the founder and family of someone on board of directors at the venture capital firm, who made an introduction to a specific angel investor for a predetermined path from incubation through accelleration.
It makes for a great story– shaping what’s said and what’s left unsaid.
If you had such access, it’s unlikely that you’d be reading this article.
For everyone else, bypass any pretense that the Silicon Valley myths would work equally well for you, even if you apply this from within the San Francisco Bay Area. The same applies to other tech hubs like New York City, Seattle, Toronto, Vancouver, etc.
This should extend far beyond North America, but always check with local regulations for your particular circumstance.
With further elaboration below, consider three stages, where each progressively adds value for an external entity, client or customer:
1. Use only fundamental automation (e.g., spreadsheet with computed values) to produce a one-time only report for a single customer.
That customer would ideally be paying but failing that, would open doors and lend their name, ultimately for landing the next customer.
2. Incrementally add basic work-flow automation (e.g., Clojure, D or Python version) with hard-coded configuration for recurring reports available to a single customer, for some fixed number of consecutive weeks or months.
Servicing this customer must be limited in scope and duration, lest they become legacy.
That customer would definitely be paying in hard currency. They are paying for results by way of a report as output but otherwise never have direct access to any software.
This is really about building the foundation of your SaaS platform.
3. Further automation with customer-directed knobs & levers for self-service work-flow.
This may be comprehended as alpha quality SaaS functionality but with manual billing. The customer remains without direct access to any software.
That represents a valid approach to being
If you require seed funding to begin, perhaps use that catchphrase when talking with friends & family, and for anyone else, emphasize instead that they won’t get diluted!
First and foremost, unless your professional network includes potential investors and probable customers: don’t bother continuing until firmly satisfying those criteria.
Without the right professional network, you have nothing.
A clue to understanding this: If cold-calling anyone (investors, customers, resource providers, etc.) within your first three years, your network is inadequate. Stop here, and address that first.
As with preparing a sound business model or an effective business plan, complete exercises such as the Lean Canvas or writing a 1-page business plan.
Being able to express your business idea completely yet concisely enough to populate those documents is priceless.
The same applies to various types of messaging:
These should exist but need not be perfected.
In fact, these might never be perfect. So be it.
Each of the documents and messaging will probably be revised weekly at first and eventually monthly as you discover more about your idea, strategy, implementation, yourself, your investors, your customers, your staff, etc.
The remainder of this document focuses on implementing and executing.
A civil engineering firm had a particular type of survey data that could be tabulated such as within a spreadsheet and produced interpolated data points for separating actuals from values adjusted as if fitted to a perfect grid. This was a discrete step immediately following dumping data from the survey equipment and before creating the 3D map in AutoCAD.
There may obvious opportunities for further automation, but begin with small steps.
Another business performed a specialized method of cross-referencing documents, which facilitated deep research involving that document repository. The pool of documents would be enriched by applying synonyms (which in turn involved Parts-of-Speech tagging, reducing words to lemma form, and generating a massive inverse-index).
With such use cases, some degree of efficiently executing may need to be demonstrated in order to acquire the first customer.
Sometimes it may be enough if the customer had a prior professional relationship enough to trust in the principals.
Whether to go with pre-paid or post-paid invoicing is a topic for another time.
Some advisors might be quick to mislabel this stage as the “Minimum Viable Product” or MVP, but that would be a mistake. At this stage, the product would be the “report” resulting from the spreadsheet calculations.
Something closer to an MVP would emerge upon completing the next stage.
The point to this stage is that all resources such as software tools remain private and completely under your control, which frees you as principal from worrying about leaking Intellectual Property (IP).
This stage produces end-to-end automation, albeit locked to a particular customer’s dataset and operated by you or your staff exclusively.
It is where automation would jump from the functional prototype (e.g., spreadsheet version) to using more rigorous tools.
For the business providing tools to civil engineering firms, it is only at this stage where data might flow directly from the survey equipment through the new tool to AutoCAD, such that the “results” would be a 3D map with different layers for actuals versus interpolated values.
For the document repository search business, it is only at this stage where the system might allow incrementally adding individual new documents rather than requiring a single batch ingestion.
Each feature implemented must be considered in terms of opportunity costs.
While there would ultimately be various knobs and levers afforded future customers, for this specific iteration and specifically the second customer, those configuration choices would appear in the source code as constant values.
Deferring implementation of a general purpose configuration mechanism (e.g., config file, command-line parameters or query strings), frees whatever time that would have consumed. Especially at an early stage company, time is precious and should be managed judiciously.
At the time of writing (mid-2020), the leading edge software tools among elite Data Scientists are:
- The Clojure programming language due to the vast landscape of numerical tools available to JVM languages, fearless concurrency afforded by it, accommodating data science and other diverse workflows all due to this dialect within the Lisp family of languages.
- The D programming language due to speed nearly that of C, extensive numerical libraries and a work-flow accommodating data science.
- The Python programming language due to NumPy/SciPy packages that overcome some of its constraints such as the Global Interpreter Lock, which otherwise limits throughput and performance.
This stage most closely resembles an MVP, but customers still only receive benefit of its results– without access to the service directly.
That is, you continue to operate it on their behalf.
Maintaining complete control over its operation is critically important.
Since this would be the first paying customer for this service, there are bound to be flaws, limitations and programming errors/bugs. You not only want to catch those issues immediately but also will benefit from avoiding any tarnish to your emerging reputation that would otherwise occur if having direct access by a customer.
This version may be launched for a customer that has been hand-picked because of their willingness and tolerance for working with you when problems emerge.
Otherwise, the customer has direct access to the software but (perhaps initially) possibly only when in the presence of you or your staff.
You need to experience using your offering through the customer’s eyes. (However, you are unlikely to have any level of instrumentation for receiving telemetry, because the time and resources required for that would have likely been used for simply building the core product or service. If you’ve spent time on any such capabilities, you’ve probably waited too long before putting a paying customer in front of it.)
Additional features include:
A parable that applies here is: rather than giving someone a fish which only feeds them for a day, teach them to fish, so they can eat for a lifetime.
Immediately upon completing this stage, however, any mention of “consulting” either literally or as analogy should cease. If your longer-term business model calls for this type of effort, use another conventional descriptive name such as “Professional Services”. Otherwise, continued use of the word consulting may become a concern to future customers or if you have them, investors.
Upon completion of this stage, your Software-as-a-Service may be considered alpha quality.
Anything other than the primary functionality would begin after this stage, such as automated billing or payment.
Successful entrepreneurs have initiated selling their business upon completion of the third stage. Knowing that an actual sale would take time, other customers are likely found during the process, thereby bolstering the value proposition for a potential buyer.
Upon completion of the third stage, you will have accomplished the proverbial “eating your own dog food.”
There might be enhancements that seem crucial, so additional stages may be added to continue such development efforts.
Move beyond the urban legends swirling around genius-founders that allegedly arrived in Silicon Valley with only an idea and just happened to make it big. What you should learn from them: build your professional network first!
Consider this as practical advice for succeeding on your own with a little help from your network, such as having a few initial customers in place first.
Create the least amount of automation required to produce meaningful results for your early customers. Only add functionality incrementally and only when absolutely necessary.
You are providing results to your early customers, not software and not a service. The SaaS part remains internal for the time being.
This resembles consulting, but “consulting” is just an analogy.
The goal throughout remains being funded by revenue.
Pursuing angel investors or venture capital later becomes a business decision but one in which you may negotiate from a stronger position.