This essay chronicles Calcapp’s long history. It was written by David Polberger, Calcapp’s technical co-founder, and was originally published on Medium. (The “SaaS” in the essay title stands for software as a service and denotes software licensed on a subscription basis.)
When I was 21, my father asked me to create an app for the hospital department where he worked as a doctor. Numbers would be entered and other numbers would appear. I thought it sounded simple enough.
My father worked with babies born too early and had written his PhD thesis on their nutritional needs. The breast milk consumed by premature babies is often fortified with various nutrients and my father’s research indicated that the amount of fortifier given should be adjusted based on the weight of the child and on the actual contents of the milk. This finding was contrary to the standard practice at the time, which called for using a fixed amount of fortifier.
Luckily, analyzing human milk at a local hospital department had just become economical. Earlier, milk had to be shipped off to a centralized lab for processing by expensive machines, but new technology enabled departments to buy their own milk analyzers.
Armed with a state-of-the-art milk lab, my father set out to put his research findings into practice. Doctors and nurses would make decisions based on the results from the milk analyzer. The only problem was that performing the calculations manually turned out to be a slow, error-prone process, especially in a high-stress environment.
That’s where I came in. I was a computer science undergraduate at the time and my father correctly assumed that I wouldn’t find creating a simple app too taxing. After a few weeks of work, I delivered the app, which the department quickly came to rely on. We named it Nutricalc.
The only problem with Nutricalc was that it needed to be updated constantly. Preparations and formulas would change, forcing me to keep up. My father would deliver the mathematical formulas as a constantly-changing Word document. Here’s the formula to calculate the protein intake:
U = 1/A x (D x 0.0087 + E x 0.0087 + F x 0.0174 + G x 0.0174 + M x (I/100+O x 0.16/100) + N x (K/100 + O x 0.16/100) + P x 0.023 + Q x 0.019 + R x 0.015 + S x 0.012)
I had to manually make sense of the new formula, comparing it to the old one, and make the required changes. Needless to say, this was a time-consuming and slow process.
Computer programmers don’t enjoy tedium, so I set out to put myself out of my misery. I wanted my father to make the required changes himself and just send me a new text file with the formulas when changes needed to be made. I would then ask a computer program I wrote to turn the text file into an app. By 2004, I had programmed myself out of the app creation process.
It dawned on us that the software I had written could be used not just for a nutritional calculator, but also for any number-crunching calculator app. I unimaginatively named the app creation software I had written Calcapp.
My father next set his sights on creating a drug dosage calculator. While two adults are often prescribed the same drug dosage even if one person weighs twice as much as the other person, you need better precision when administering drugs to premature babies weighing as little as half a kilogram (18 ounces). Doing the required calculations manually was, again, error-prone and tedious, meaning that his department immediately took a liking to our new app. Pharmacalc was born.
Calcapp was created partly because we were expecting to create lots of Nutricalc and Pharmacalc variations. Every hospital department would need a unique copy, as they used different nutrients, different drugs and had procedures that differed. We envisioned selling our apps all over Sweden. (Before moving on to conquer the rest of the world, obviously.)
Our lofty ambitions soon faced resistance in the form of constrained hospital budgets. What we were offered wouldn’t even cover our costs for updating the software.
We found our savior in industry. A maker of breast milk fortifiers and formula was interested in acquiring an unlimited Nutricalc license in Sweden and in neighboring countries. Their Nutricalc variant would only have data for their products, but would be distributed to hospitals for free.
In 2007, we had our deal and the first Nutricalc CDs were distributed to hospitals.
By 2008, the global headquarters of our corporate protector had gotten word of what their Swedish office was doing. They envisioned distributing Nutricalc all over the world. Many countries are too poor to afford analyzing breast milk and the plan called for Nutricalc to use data from the scientific literature for those markets.
We were excited by the new project and the prospect of doing some good in the world and I was able to quit my full-time software job. We signed a contract and got to work.
Calcapp wasn’t ready, though. It had been built for simpler apps and had trouble coping with the new requirements. I managed to get a prototype built, but under the hood, it was a mess.
In parallel, I began working on Calcapp 2, which would right all the wrongs of the previous generation. It would satisfy the new requirements and then some. It was exceedingly ambitious and would be built from the ground up. We already had a customer, what could go wrong?
Our commercial benefactor stopped showing interest after we delivered the prototype. We were paid for our time, but nothing came of the project. Years later, it came to light that the person championing the project on their side quit the company before we even delivered the prototype. The software was fine, but nobody wanted it anymore.
With our primary funding source dried up, I made the call to continue the project. By 2009, Apple had fundamentally transformed the smartphone market with the iPhone and I envisioned a future where line-of-business calculator apps would run on mobile devices — built with Calcapp.
When you’re embarking on a risky business venture, you need to think through where the future money will come from. Who are your future customers? How are they currently solving the problem you’re trying to solve? Will your future product improve their lives to such a large degree that they will be willing to spend money on your product and retrain their employees to use it?
I have since learned that creating and finishing a product without first validating that there is market demand is folly. You need to talk to your future customers, ideally before you start building the product itself.
In retrospect, all that sounds obvious. In 2009, though, I stubbornly clung to the notion that I had to finish the product before reaching out to future customers (which in and of itself was a scary proposition). Besides, I really, really wanted to finish Calcapp 2 and probably felt that I owed my creation the pleasure of being finished.
I had big plans. I wanted to enable apps to be described once and then have my software create native apps for Android, iPhone and iPad and the PC. I wanted support for rich user interfaces, automated tests and state-of-the-art code.
Unsurprisingly, realizing my ambitious plans took a long time. All in all, I spent two and a half years finishing Calcapp 2. Along the way, we gained a new enterprise customer who contributed funds to the project. The new income didn’t come close to covering our costs for the project, though, and I spent many months going without a salary, depleting my savings.
I had assumed that there would be a market for producing calculator apps on a consultancy basis, being able to do so with healthy margins compared to other vendors thanks to Calcapp doing most of the work. Our experience did not bear that out.
A landing page was launched and we took on a few projects, but all were significantly less lucrative than the enterprise contracts we were able to get thanks to my father’s connections. If there was a thriving market, we didn’t find it, making the project an expensive failure.
With a baby on the way and a need to shore up my income, I accepted a consulting position at a cell phone maker in 2012, doing software development for their Android handsets. After 13 months, I went on government-paid parental leave with my newborn, spending close to a year with him. (This, I might add, is normal in Sweden.)
Calcapp was still on my mind, though, and I was itching to get back in the game.
Having reached a dead end, we contacted a group of business advisors paid for by the Swedish government. The government doesn’t do this out of the goodness of its heart, they’re counting on the companies they advise to help expand the tax base, lower the unemployment rate and ultimately make Sweden more successful as a country. We didn’t want to give these advisors the impression that we wanted to run a lifestyle business, that is, a business only supporting ourselves with little in the way of growth prospects.
We needed a bolder vision for our company. We needed to build a business where we would earn passive income from customers as opposed to charging for our time and we needed to appeal to a much larger segment of the market. In other words, we needed to answer the questions I had stubbornly avoided earlier.
If you need to do calculations using a computer, do you turn to an expensive consultant to create an app for you? No, you turn to the innovation that sparked the personal computer revolution of the 1980s: spreadsheets. You don’t need to communicate your needs to anyone and you can probably create something that works acceptably well for a low cost.
I hadn’t seriously considered spreadsheets when I started work on Nutricalc ten years prior. Spreadsheets often make it easy for end-users to change formulas, ruining the calculations, and lack built-in support for running automated tests. This makes them less than ideal for, say, a drug dosage calculator. As a result, we hadn’t considered the elephant in the room when thinking about what a market for Calcapp might look like.
In the process of fooling our advisors into thinking we had an audacious product vision with a bright future, we also managed to fool ourselves. We were going to create “Excel for apps,” a do-it-yourself app designer for the spreadsheet crowd, delivered as a software-as-a-service (SaaS) product. We wanted to build a product for all the accountants, scientists, tradesmen, academics, engineers and health care professionals proficient with Excel and other spreadsheets, but with no ability or interest in creating software the traditional way.
I started working on a landing page to gauge interest in our new vision. I put in a few user interface mock-ups, wrote advertising copy to the best of my ability and asked visitors to sign up for the upcoming beta version.
The landing page went live in 2014.
Search engines were good to us and delivered the visitors we had hoped for: 18 percent signed up for a future beta version. We made it a rule to write lightly personalized letters to each and every person who signed up, asking them about their needs.
This process was tremendously valuable. About a third of the people we contacted replied and we learned that our imagined market probably was real. We also learned a great deal about what users were expecting from our product.
After hundreds of conversations, I started working on a “minimum viable prototype,” a bare-bones version of the future product intended to demonstrate that there is a market for the product without bothering to build all features.
Learning modern web development after having spent my career working with embedded systems and desktop software proved to be an uphill climb. Also, I could reuse very little work from Calcapp 2, which was centered around reading app descriptions written in a text file format only a programmer could love. Most of the code I had spent so much time laboring over was ultimately thrown out, with only the parts making sense of mathematical formulas surviving.
From the ashes of Calcapp 2 emerged Calcapp 3. An arcane tool for the technically proficient was about to be transformed into an app builder for everyone capable of using a spreadsheet.
In late 2015, the first beta version was delivered to the visitors who had signed up. An initial surge in traffic quickly leveled off, probably because users realized that this early incarnation of the software was very limited. Only number fields were supported and twenty formula functions. Worst of all, it would be months before apps you created could be shared with others.
We weren’t overly fazed by the lack of interest and started working on making the product more useful. We enabled formulas to be used not just for calculating results but also for determining what colors to use, the recipients of PDF reports and whether fields would be visible. We made the resulting web apps offline-capable, added support for rich text, drop-downs and text fields. We added support for over 240 Excel-compatible formula functions and made it possible to format numbers in a way that would be familiar to Excel users. All the while, we created a website with learning resources and an active blog.
It has now been two full years and we’re on the verge of launching Calcapp commercially. Today, it’s obvious that we should have commercialized the product much earlier — well before we had written a quarter of a million lines of code. The truth is, you should start charging for a product, even when you’re mortally embarrassed by it. As its creator, you’re painfully aware of all its failings. Your users, on the other hand, mostly reflect on whether it gets the job done for them. If enough of them find your product useful enough to pay for, you’re in business.
Traffic picked up markedly in late 2016, and today I’m heartened when I look at all the apps that are used every day. There‘s the South African electronics chain requiring hundreds of employees to send an “end of day” report using Calcapp, lots of health care, engineering and finance apps and, of course, a yogurt making app and a tip calculator. High school students in the United Arab Emirates have, just this month, started using apps to help them with their physics problems. The Argentine film industry even set up a special website dedicated to hosting their app for calculating the salaries of workers in their industry.
Most gratifying of all, though, are the four hospitals in Sweden that now pay to use Nutricalc and Pharmacalc, after we navigated the byzantine world of regulations governing the use of medical software. Twelve years later and we finally have our deal.
I once took a badminton class. The instructor remarked that she had never seen anyone expend so much energy yet accomplish so very little. (I am a terrible badminton player.) With all the years I have spent on Calcapp, I hope that the same won’t hold true for my entrepreneurial efforts.
Later this year, we’ll know.
Thanks to David, Camilla, Marianne, Harry and Staffan for reading drafts of this essay