Something that has always fascinated me about start-ups is that you always get learnings you didn’t expect. One would assume that positive learnings automatically attribute to positive results and vice versa. Unfortunately, this is not necessarily the case. An example.
(Reading time 3 minutes)
Product vs Research & Engineering
At Parashift, there are basically two phalanxes. A Research & Engineering front and a Business front. We have spent the last 12 months pouring knowledge from our R&D into infrastructure so that we can a) do research & engineering more efficiently and rapidly and b) build products for the markets. These products help us to have the money available to invest in R&D again.
The products have two strands: APIs for software vendors (such as ERP systems etc) who want to integrate autonomous accounting document processing into their systems and the Parashift Platform; a kind of fully automated DMS SaaS for accounting documents tailored to the needs of medium-sized companies.
We focus on the 100% correct delivery of the document information. We achieve this by super-high automation-level and reworking the missing part through our operations team – which is again one of the key drivers of our fast machine learning improvements. (we will give a really detailed technical break-down in due course).
“100% Extraction API”
We were able to win our first customers and already received numerous enquiries. Behind each of these inquiries stands a dedicated software project and a usually a complicated decision tree for the customer – the sales cycles are correspondingly long. In most cases, a political component also plays a role, as at least a partial change of strategy has to be tackled.
What I have personally underestimated is that there is also great interest in the results generated by the machine only. I was so focused on 100%-, and ultimately, autonomous processing (because this is basically the real game-changer) that I was blind to this demand. Pretty stupid.
“Continuous benchmarking.”
At Parashift we maintain a set of competitor-cases against which we benchmark. It contains pretty much every solution that is on the market. We regularly test with a document-mix that we consider representative. At the end of this summer, we realized that we had a better overall command of this set of documents than any other provider. At the same time, we received more and more requests to simply deliver the non-100% result via an interface.
So, we decided to build a corresponding API product and named it “Basic Extraction API”. What works well on the prototype level is not yet a product. So we ended up spending September and October expanding our infrastructure (among other work).
With the “Basic-Extraction API” some basic requirements change, because potentially the infrastructure must be able to process a much larger amount of documents in parallel.
“Breakthroughs per week”
New findings and results from Research & Engineering then burst into the middle of this work. These are always great news, because that means that our technology is quickly getting even better.
As a rule, however, we are somewhat unprepared to such events, as we try out and combine new ideas in different strands. In addition to a logical approach, we also pursue initiatives that do not make sense according to current rules of art. Often this has already played a crucial role to our overall progress.
We jokingly called this moment “Breakthrough” – which, of course, they are by no means in the true sense of the word. They are substantial improvements, ok. However, as a new metric we immediately defined “Breakthroughs per Week”. After all, we measure everything.
Well, these improvements need to be analyzed and quantified first and later incorporated into the product. Determining what works better or what works worse is incredibly time-consuming, even though we have already automated it to a large extent. In the best case you would use all the documents and results ever processed to measure your findings.
Delay due to progress
As a consequence, we have not yet released the “Basic Extraction API”, which we actually wanted to have available in October. Individual customers already have access, soon we will finally be able to add a public test API plus a freely available demo.
The delays are not tragic in the long-term perspective – on the one hand, because the reason is a more positive one – on the other hand also because the lead pipeline continues to build up. But it’s anything but nice to put future customers off. We are confident that we will be able to complete the work in the coming days and weeks. New “breakthroughs” will be released later.
