From time to time a business idea pops into my head. I got particularly excited about two ideas in the data analytics space. So, I decided to test them out in the market by “selling” them to companies in the aluminium industry. Their interest was mediocre at best, and sales were non-existent. Below I summarize what I’ve learned from my mistakes.

Idea one: Time Series Dashboards

Time series are measurements of a variable in time. There’s plenty of time series in the aluminium industry: temperatures, flow rates, voltages, … I got this idea from my first job where I had programmed a dashboard with R, a specialized programming language. The dashboard displayed time series as line charts, making it convenient to inspect the production process for problems. Using LinkedIn, I compiled a list of 10 engineers at various aluminium companies and cold called them one by one to pitch them my solution.

I managed to reach 5 engineers. There was some interest (it was the peak of the data-hype after all). However, no one really understood what I was offering and why. What does my dashboard show? What problem does it solve? And what is this R programming language anyway? The engineers did not see how my solution would make their job easier.

It took me a year to understand that my idea could never grow into a business. I wanted to code everything myself because I liked programming in R. This is a trap that many engineers like me fall into: we’re hard wired to look for someone that pays us for exercising our technical skills. I realized I didn’t know or care what the client would do with my dashboard – I just wanted to have fun building it! And what if I hypothetically found many clients that needed such a dashboard? Because all companies have different data, I would have to program a unique dashboard for each one. An approach that requires so much customization is impossible to scale. This venture was therefore just a job disguised as a business.

Idea two: Analytics as a Service (DAaS)

I got this idea from my accountant. He filed my taxes and offered unlimited advice for the same fixed fee every month. I liked this cost model so much that I decided to apply it to my data analytics skills. I reached out to an R&D Manager at a metals recycler for whom I once interned. I offered him to “watch over his company’s process data” and “raise alarms if I spot a problem in the data”. I felt qualified for this work because I was employed as a process engineer early in my career. I would copy their data to my servers in the cloud. This way, I could access the data from anywhere at any time.

This idea is arguably more scalable than the first. I could automate repetitive tasks as I got more familiar with the plant’s data while still charging the same monthly fee. With the time saved through automation, I could serve more companies and generate more revenue. One day, I could even hire employees to further scale the business. At least, that’s how my bookkeeper made it work.

My idea failed due to a compliance problem: “transferring our process data over the public internet to someone who’s not our employee? No way!” Another problem was vendor lock-in: “what if this guy suddenly decides to close his business?” I learned that companies prefer to keep critical data infrastructure in-house. Even if this means hiring new employees to build an internal data team. And although aluminium companies have started moving their data into the cloud, they prefer to control this process themselves.


But is this compliance problem really a deal breaker? What if secure transfer of data between the plant and the cloud can be guaranteed? I explore this topic in my post about data security.