Small Team, Big Success. Part 1: amCharts is Building the Future of Data Visualization on the Web

For the last 5 years I’ve been dreaming about starting a podcast where I would interview indie developers who made it big and still decided to stay small and frugal rather than shoot for some imaginary stars just because our society considers it to be the “right” way. Why after creating a successful “indie” product developers would decide to prioritize freedom and happiness over a chance to manage thousands of people is a question I can relate to and like to explore. From dabbling in podcasting in the past I was reluctant to do it again — preparing, juggling meetings, producing, etc. is a lot of work. Additionally, no one probably wants to hear my Eastern European accent in audio-only form and I don’t have the time or determination to try and shake it :) So, I finally decided to do a series of written interviews instead of a podcast. And today we have the first “episode” of the series. Who should be the first was always a no-brainer to me — I’ve known Antanas Marcelionis and Martynas Majeris for years. success has been a solid example of defying the “Silicon Valley model” that I’ve witnessed first-hand. They’ve built a leading charting library in Flash and then repeated their success when the technological landscaped has suddenly shifted under them. Now and it looks like another great milestone in the history of the product.

So, I got the final push to do this series and here we are…

Disclaimer: as I’ve mentioned above I’ve known Antanas and Martynas for a while. We’ve been partners in several businesses and I’ve been an on-and-off part of the extended amCharts team since 2008. So, I’m hardly unbiased. Having said that, this could have had an opposite effect on this interview (as opposed to shameless praise) as I tried to steer clear of controversial topics related to our personal relationships.

Tell us a little bit about yourselves and how did you get to what you are doing with amCharts now?

Antanas Marcelionis

ZX Spectrum () Since I was a kid I saw business opportunities practically everywhere and explored a lot of them. And the main reason for doing business was to earn money for a computer. I even tried to build one myself, but it didn’t go well. So, I helped my father grow tulips and with the money we earned by selling them in the market I’ve got my first computer. It was . I think I was around 13 then. Later, I’ve got an IBM PC and then a connection to the internet. All I did since then was internet-related. I even helped people, mostly Americans, to find relatives in Lithuania for a fee (even if it was basically looking up people with some last name in a phone book).

amCharts website circa 2007 I’ve built my first homepage on Geocities and then started offering web design services to some companies. I always worked for myself, opened and closed (or left) 3 web design companies until I was 27. During all this time I wasn’t actively programming, only sometimes (mainly because I haven’t had any programming education). I left my last company without a clear idea of what I will do next and it happened that we rented the same office space with Martynas and Alan. I was working on some freelance gig and I needed to draw charts a few times. So, I thought I can make my life easier if I create a utility to draw charts. That’s when I started coding more seriously and become quite an annoying colleague as I was asking a lot of questions about programming. And it happened so that the first chart I built (it was a pie chart, of course) became quite popular in Japan! When people started buying licenses, I promised my colleagues at the office that I will buy pizzas on the day a more expensive type of license is bought. Pretty soon we couldn’t look at pizzas anymore. The rest, as they say, is history and since then (2006) I am working on charts full-time.

Martynas Majeris

Ever since my mom brought back an IBM PS/2 some 30 years ago, my life had a clear path. From first forays into programming as a teenager, into full-scale IT-related jobs, up to a point when I was juggling my time between a local dev house, a co-owned web consultancy in New York, some personal projects, and part-timing for amCharts since it was founded back in 2006. At some point, the burden of divvying attention between so many things got old, and half a decade back I dropped everything else for a full-time attention to amCharts. Since then I have been responsible for certain parts of development, ran support crew, managed sales, and web operations. Your typical COE (Chief Officer of Everything). With the team growing, when we were starting development of v4 I was able take on more development responsibilities — exactly what I’ve always wanted.

Paul Chapman

I’ve always been a geek, I first used a computer when I was 8, and I was immediately hooked. I started programming when I was 16, just for fun. A friend taught me the basics, but after that I was completely self-taught. Since then I’ve been programming for over 11 years, and I’ve learned a lot of programming languages. I needed a part-time job, and unfortunately part-time programming jobs are pretty rare, but amCharts had a part-time opening as a support personnel. I did a good job at that for a few years, left for a couple years to work on a non-amCharts side project, and then came back to work as a programmer for amCharts. My main responsibilities are handling the low-level infrastructure stuff: tools, utilities, libraries, integrating V4 with other technologies (Angular, React, etc.). Beyond that I offer advice and handle anything else that needs to be done. I’m quite happy working for amCharts, I get along well with Martynas and Antanas.

Why did you decide to stay small after you’ve seen the initial success?

Antanas

Most likely because we are all introverts, 100% of our current staff work from home — myself and Martynas work from our home-offices in Vilnius, Lithuania, Paul works from Hawaii, and our support team is scattered all over the world — we have one guy who does support when he is tired from surfing in Bali. The main reason I quit my own web development companies was because I got tired of formally communicating with and managing people. And now, when some important-looking person from an investment company with a tie says that they want to invest in amCharts and will help us build a “normal”, more valuable company, I keep reminding myself that I’ve tried being normal. And I didn’t like it.

Martynas

We’ve faced this choice a number of times during the years but dismissed it every single time. We’ve been enjoying this too much, to willingly concede our freedom for a bigger chunk of money. Going big(ish) would mean accepting outside capital, becoming accountable to someone, shifting our own responsibilities from development towards management. Yuck :) We sometimes make huge business decisions in, like, 5 minutes, over Slack chat, then go ahead and implement them in the next hour. Just trying to imagine how it would have to go down in a growth-at-all-costs oriented, VC-backed company gives me seizures :) We also have a philosophy that we work for developers. That means everything — licensing, installation, features, support is designed to make sense — for developers. And if something doesn’t, we can change it on a whim, without long brooding how this will affect growth or the revenue stream. Accepting VC, growing the team, would require us to shift our focus towards pleasing the investors — increasing revenue. Both — to keep investors happy and to feed the large team. That inevitably lead to decisions that are more biased towards growth, than common sense in the dev community. So, staying small, having no one to be accountable to, except our users — the developers — made the most sense to us 10 years ago, and it still does now.

Antanas, you’ve been a Flash/ActionScript developer and transitioned to JavaScript with v2 of amCharts 7 years ago. Was that transition difficult?

Antanas

It wasn’t, ActionScript is very similar to JavaScript. I remember I was copy-pasting a lot of code from my charts made for Flex and only fixing some small differences. The main things that I missed in JavaScript were classes and, of course, type-safe programming.

Martynas

The first reaction was “Oh no what are you doing, Steve? You’re gonna kill Flash, and we’ll have to do everything from scratch”. Once that initial reaction passed, we quickly saw it as an opportunity, both to rewrite and better our products, and to get ahead of our (at that time) “sluggish” competition.

Was the web platform at the time ready to take on replicating what you were able to do with Flash?

Antanas

The only difference between now and then is that now people do not expect a library to work with old IE browsers which do not support SVG. Our v3 could be rendered using both SVG and VML (the vector format which IE8 and older support), and this caused a lot of problems as VML is much less flexible than SVG. And SVG today is the same as it was 7 years ago, so everything is possible now was possible then too. Well, the computers and the browsers got faster so you can do some more fancy effects and worry less about performance. With SVG you can do everything you could do with Flash. The only thing is that quite often you need to invest more time — Flash offered a lot of things out-of-the-box, plus you didn’t have to worry about differences in browsers.

Martynas

Yes. It was ready before that. The industry just needed a nudge, which came from Apple. We transited from clunky, proprietary, plugin-based Flash into open, standards-based JavaScript and SVG. Best thing that could have happened.

With v4 you switched to developing in TypeScript. What prompted this decision?

Martynas

We needed to up our game. We needed to do something flexible, extendable. Something that modern web developers are comfortable with. That is compatible with current frameworks and technologies. We needed modules, we needed type checking and error handling, we needed our stuff to be compatible with IDEs. Vanilla JavaScript just did not cut it, and was a de facto standard. Easiest decision we have ever made.

Antanas

I tried the very first version of TypeScript when it became publicly available and I liked it, as I said I was missing strict types, classes and other things from ActionScript a lot. And even the first version had most of the things I expected. I wrote first lines of amCharts V4 in 2015, with TypeScript 1.5. And it’s Typescript 2.9 now — the development team has been improving the language all the time (and making us rewrite our code quite a few times, but no regrets there).

Have you considered any other options?

Martynas

Only briefly. There are a lot of options out there, some might be even better at some tasks than TS. But frankly, with all the muscle behind TS, and overall acceptance in the community, it’s kind of a no brainer.

Antanas

One friend advocated Coffeescript to me, but I must say I never tried it. The fact that a company like Microsoft is behind TypeScript with the right philosophy that played well with ours was enough to tip the scales right away. And during the time we were starting work on our v4, Google announced that they will use TypeScript in Angular so it felt like we made the right choice and there’s no reason to “shop” around anymore.

Paul

The biggest alternative at the time was Flow, which is also quite good. But ultimately the fact that TypeScript was more popular (and was gaining traction with things like Angular) made it a more attractive option.

After working on v4 for a few years we can finally , and they are amazing. Congratulations! Would you say that your decision to choose TypeScript paid off?

Martynas

Too early to count the ducks, as we’re yet to see commercial implications of switching to TypeScript. However, from the development side of things, it most definitely paid off. Without strong type checking, we’d probably still be chasing weird bugs now ;)

Antanas

I am sure it did. We’ve spent 3 years developing V4 and I am afraid we could have spent twice as much if we had to do it without strict types, all the refactoring possibilities and all the other good things TS offers. And I don’t even want to think of the number of bugs we could have left without all this.

Paul

I was skeptical of TypeScript at first (Flow had better features at the time), however over time TypeScript has added all the features that Flow has (and more!), so I think TypeScript was definitely the right decision.

Obviously, you are happy with your decision to go with TypeScript but there must have been some roadblocks you hit along the way or things you’d like to see in TypeScript in the future…

Martynas

The biggest beef I have with TypeScript is that it requires compiling, and there’s not one but whole three garden varieties of compilers out there. All with their own complexity, faults, bugs, and huge learning curves, it almost seems like a rocket science managing a huge project. I can’t count the times we hit snags with compiling. This might be a serious burden (one that might not be prominent until you’re well underway) for people trying to get into TS dev.

Paul

We’ve encountered a lot of minor problems with TypeScript (and filed a few bug reports), but overall we’ve been able to work around everything. I think our unique situation (we’re providing a large and complex library, and we also need to worry about compatibility with JavaScript users) makes things more challenging: I think application developers will have a lot fewer problems with TypeScript.

Aside from TypeScript were there any other technological changes you’ve made for v4?

Martynas

We can’t speak in terms of “changes” between v4 and older versions, because it’s a completely new dataviz library. Imagined and done from scratch. That said, I’m particularly proud of some conceptual decisions we have made. One in particular is what we call “states”. It’s a way to dynamically change, or gradually transition, anything to anything. Any setting, data, property. The engine will automatically take care of it. For example, we could say this column will now have different value and color, and it will just magically happen, transiting gently to a new value and changing the color gradually. It’s so powerful yet so natural, it still gives me goosebumps :)

Antanas

When developing v4 we started from building a core. I loved ActionScript so a lot of things in the core are done in the way I remember from Flash and Flex. We even call our main visible object Sprite (I hope Adobe won’t sue us for that :)). So, this core does everything — lays objects out on a stage, does animations, interactions, changes states, filters, does math, number, string and date formatting, processes data — everything you need to build any kind of SVG project, and you indeed can use it separately from charts. When the core was ready we’ve built charts using it, improving the core at the same time to meet our needs. Our charts are architected in a way that lets user control everything — access every sprite, change any property, add interactions. If you are a developer, you can also extend our chart classes and build your own new chart types or add some things that are not supported out-of-the-box. And, as we have a really good core and very flexible classes needed to build charts we are planning to add a lot of fancy chart types soon.

From the amCharts v4 website

Paul

In addition to TypeScript, we also now officially support npm, Webpack, Angular, React, etc. Because V4 was rewritten from scratch, we were able to ensure that it works great with modern JavaScript tools and ecosystem.

What are the parts of your toolkit while developing amCharts in a small team?

Martynas

90% of the work happens in . The rest is pile of other stuff: Git, Node, Webpack/Rollup, Selenium, and … Spotify :)

Antanas

My colleagues call me “an artist”, because I don’t really care about the “beautiful code” too much. I make things that work and do things I need but don’t care how I got there. For a year or so I was developing v4 alone and built the early prototype of the core with the main things I needed from it. Later Martynas and Paul joined me and they practically rewritten everything so that the code would meet the quality standards, be fast and well documented. At the moment I am more focused on developing the chart part of the product and they still make the core better each day. I think this approach worked very well for us, as it’s quite common that the perfectionist developers cannot finish their products because they get stuck perfecting their code and do not allow themselves to do some small crimes code-wise because then it would not be perfect. I don’t have such constraints. As for tools, besides Sublime I use paper and pencil a lot — drawing charts requires solving a lot of geometry, so I draw things on paper and write some math there. Luckily geometry was one of my favorite subjects at school.

Paul

Yes, that’s certainly true, there are many small “crimes” committed daily, haha. But overall I think the code is in a pretty good spot right now.

We use the normal TypeScript compiler (tsc) for transpilation, it works quite well for our ES6 and TypeScript users. As for our JavaScript users, we pre-bundle everything with , because it has great support for code splitting and dynamic loading, which improves the startup performance. As for personal tools, I don’t use anything fancy, just Sublime Text 3 and a console. I’ve written a bunch of custom scripts which automate various things for amCharts (building, testing, publishing, etc.) Being a programmer is a bit unique because you really don’t need much: even if you have no money, you can still be a top-tier programmer, because all of the tools are free or inexpensive.

As a remote team, how do you keep the processes on track? What tools and routines do you use?

Martynas

We basically live in Slack. Before that we tried a number of solutions like Basecamp, and even plain ol’ Skype. Nothing stuck. Now all of the team — dev, support, sales, and even part-time help — are on Slack. Git does a perfect job of versioning and issue tracking. Naturally. Build processes are all automated (thanks to Paul’s phenomenal affection to perfection and automation ;).

amCharts is a very successful library for web developers both in terms of mindshare and praise, as well as commercially. Do you have any advice for aspiring developers (and entrepreneurs) who want to focus their career and business on the web space?

Martynas

This might seem like something taken straight out of a motivational poster, but whatever you do, make sure you love doing it. Boring stuff quickly gets old and deteriorates into neglect. No point in wasting your time on throwaway stuff. There’s absolutely no way we could still be doing this after 10+ years if it seemed like work.

Antanas

Be patient. We’ve spent 3 years developing v4. It’s a really difficult thing to do it for such a long time and not have an opportunity to enjoy the results.

Paul

There is a saying that it requires 10 years to master something. I think that’s true, so you need to be in it for the long haul. If you expect immediate results, then you’ll just be disappointed. — Check out and follow them on .