Akrity was started by a bunch of programmers who really enjoyed building software. In the early days, we didn’t have HR, Marketing, or Sales teams yet and we did not even know if we needed them. Yet, even in the early days, we decided we still needed a website. Because? “Well, everybody’s got one.” We wanted to show the world we existed and that was exciting. At that time, we didn’t know it’s called marketing.
First Mistake: One Wrong Turn
A few of us decided that given we are a bunch of engineers ourselves who knew well to use the right tool for the right job. We were so proud to be developers, that we looked around for a tech solution so programmers could run the website. We decided on Jekyll: it allowed programmers to build and deploy static websites using code. There was no WYSIWYG editor, but “Hey! Who needs them?” “Muggles may be!” We thought. When the website came up live, it was super exciting for us. The website was simple but elegant, pixel-perfect, responsive, and loaded super fast on all devices. “Time well spent, of course.”
With time the programmers got busy and the website got ignored a bit: we always had more work than we had people. Client work was more important than internal stuff. Even though we all knew how to update the website, updates took more time, because often we had to wait for one of us to get free. Every time we wanted to update the website, we had to make a small release. We also had to test our code a bit to ensure that changes in one area did not break the code in other places. No one wanted to push code that broke our main website. We all avoided rushing it. A bunch of smart programs running a simple website was not as painless as we initially thought.
Repercussion: There’s never enough time!
Initially, we would wait for a week or two for one of us to get free to update the website. But, that got worse over time. I remember the worst case when fixing a few typos took us two months. Our first sales & marketing colleagues would complain emphatically about these delays, how they prevented them from acquiring new business, and how frustrating it was.
As a business owner, I realized this was unsustainable but I wondered what we did wrong. Updating a website should not be this hard I thought. I started looking for what other people were doing and found that most people were running their websites on WordPress. No surprise there! WordPress powers more than 43% of the web, a fact we all knew even while we chose a different platform. Yet, at that time, we thought we were different because all of us could code and WordPress was for us. After multiple such delays, it was finally decided that website builders with a WYSIWYG editor were the way to go. That way we didn’t need to make a release whenever we updated our website and even a non-tech person could update and maintain the website. Incidentally, the sales & marketing people also were better at presenting our work to the world. It was better for them to run our website independently of programmers.
On the surface, choosing the right tool for the website was a simple low-impact internal decision and we went with our strengths. Yet, over time, we became really frustrated about how long simple things took and how complicated our lives became. In time, another egotistical programmer bit the dust and followed the rest of the world in using WordPress.
Small Mistakes, Big Learnings
Even though this was a long and frustrating experience, it taught me many important lessons. Like most frustrating experiences often do. One is, that when we are good at something, we tend to overuse our strengths and try to solve all our problems using existing strengths. Oftentimes we fail because different problems need different strengths and solutions. We should be careful not to overuse our strengths. You need to save them for areas with the highest impact. Two is, that executing successful teams involves different functions coordinating and working well together. While coordination is important, independence is just as important. Marketing is a different function than development and should be treated like that. Developers can’t solve everything. Should not solve everything. Marketers, or any team members, should have the tools and the independence required for them to do their job well. Otherwise, their effectiveness and job satisfaction will be subpar.
Today I find new founders surprised when I insist their product teams should not build their website. “If they are capable of building my product, they are definitely capable of building my website, they say.” But it’s not really about capability, I explain. There are plenty of tools available for running and maintaining websites today. WordPress, Webflow, and Ghost to name just a prominent few. These tools have tens or even hundreds of features that are required for buying and running websites efficiently that your internal teams can’t replicate. SEO optimization, payment integration, plugin ecosystems, integrations just to name a few. What’s more, these features are tested and fine-tuned by thousands of users using them for hundreds of hours, providing multiple usage and failure feedback. That would be impossible to replicate by an internal team for an internal purpose. These tools are built by hundreds of developers but the costs are distributed over thousands if not millions. You would be better off evaluating which tool is the right fit for you and using that, than building one yourself.
Besides, you want most of your team working on your customers’ problems, not internal ones. You want them to use all their magic for your customers’ products, not for your internal needs. That’s the best use of their energies. Your internal needs become opportunities for other software companies to build solutions that you would buy.
If you are a new founder who wants their team to build their website, hope this article persuades you to do otherwise; and helps you avoid the mistakes that I made as a founder. Hope it also convinces you that renting a website software is often more economical than building one yourself. Over the years, this experience has also influenced how I think about rent vs. buy vs. build decisions in a SaaS world. Read this article to know more about it.
