From Zero to Accel Funded Startup: CTO’s Journey

By Armen Solakhyan, The CTO @ Pharmaccx

In February 2018, my now colleagues Nathan, Richard, and Marc visited me in San Francisco to outline the vision for a company that will set to solve a deadlock in the market access for the new cancer therapies. I was working at a San Francisco based hedge fund but was passionate about the space since an immuno-cancer drug from Genentech saved my mother’s life just a couple of years earlier. I have spoken to all of them on the phone, but I was dying to meet the team and make sure one of the essential rules of mine is satisfied.

Startup is a long journey, so make sure to work with people you want to be friends with.

From the moment we met, the connection was clear, and the work began. I have left my job at the hedge fund three weeks later and concentrated 100% of my time on this new venture.

In November 2018, we got funded by Accel Ventures, one of the most respected venture capital firms in the world. Accel invested primarily because of the validity of the problem we were solving and, most importantly, the team we had in place.

In this blog, I wanted to take you through my journey as the CTO of the newly formed company and describe the essential steps which took place pre-funding and how things shaped out post-funding.

From Zero to Prototype

As a CTO of a four-person startup, you must wear multiple hats: architect, engineer, product manager, project manager, UI/UX expert, etc. After we first outlined our vision for the product, it was important to showcase this vision to potential customers as soon as possible.

Build a functioning prototype as soon as possible.

We used ReactJS to build one with a Boostrap template I have purchased from https://wrapbootstrap.com for $39. There was no connection to the back-end; the data was stored in the browser’s local storage. Some industries, such as Finance and Healthcare, have high expectations about the solutions you are trying to sell to them. It was essential for us not to underachieve. The prototype had a look and feel of a real web application. We were presenting it as it was ready to go into production today and carefully gathering feedback.

Get a UI/UX Expert early on.

I was working very closely with Richard, who had the domain expertise and running the customer development efforts. I do, however, regret not having a UI/UX Expert on the team early on, as I feel it would considerably speed things up.

Add a technology advisor early on.

You want to have someone you would share your ideas with: someone you trust immensely, someone who can give you their honest opinion. Besides these important points, having a technology advisor early on would create a business continuity (what if you get hit by a bus?).

From Prototype to Real-Thing

Once we gathered enough feedback from the potential users, we were set to build the real thing. We did not have institutional funding yet but gathered enough interest from potential investors and customers.

There are three crucial aspects when choosing the tech-stack to build your product:

1. You have the right amount of experience developing using the tech-stack.
2. You will be able to hire experienced resources relatively easy.
3. The tech-stack will not be an issue during the customer and investor due-diligence process.

Start maintaining an architecture document where the choice of the tech-stack is documented with pros and cons for every technology considered.

Our technology choices were the following:

• Cloud Provider: AWS (runner up Azure). You can do lots with AWS for free. AWS gives startups a $10,000 per year in credits, so your cloud costs for the first two years ~ $0.
• Database: PostgreSQL (runner up MS SQL Server). PostgreSQL is a relational database with NoSQL support. It’s swift and costs zero.
• Back-End: SpringBoot/Java/JPA (runner up MS .NET tech stack). There is more talent available for Java-based tech stacks then for .NET.
• Front-End: ReactJS/Redux/Bootstrap (runner up AngularJS). We had better expertise in ReactJS.
• Dev Tools: JetBrains Suite of Dev Tools. The only significant expense we had on the development. JetBrains offers substantial discounts for startups.
• Source Control: Git. We used AWS CodeCommit mainly due to the zero cost.
• Feature/Defect Management Tool: Trello Boards. Actually, we use Trello Boards for everything including recruiting.
• Customer Communication: As an enterprise product provider we communicated with our customers directly. We use Zoom and Zoom Webinar most often, but face-to-face meetings typically are the most effective mechanism.

Design your product with security in mind.

As part of Accel’s technical due diligence, we have presented them with our tech-stack document. The majority of the questions we got back was around security specifics. Here are some of them:

• How do you store user passwords? What hash algorithm do you use? Does it use salt? Etc.
• How does the front-end communicate with the back-end? Does it use authentication tokens? What is the encryption algorithm used?
• How do you store data? Is it encrypted? If yes, end-to-end encryption or encryption at rest? What encryption algorithm used?
• Do you use multi-factor authentication? If no, why not?
• Do you use single sign-on? If no, why not?
• Describe your authorization.
• How do you guarantee that the user’s data is not going to be shared?
• Do you use an auditing facility to record the user actions?

Not all of these would apply to your specific project, but you should be able to explain why not.

Start maintaining the product road-map.

In addition to the architecture document, the product road-map must be kept up to date. Potential investors and customers will require this during the due diligence process. If you have current investors, present this to them as part of the board meeting deck.

Use a qualitative approach when building your team.

Accel funding was a great moment in the history of the young company. With that came a responsibility to expand, and the technology team is the focal point of that expansion as our road map had grown significantly.

In my opinion, tech team hires could be classified as quantitative and qualitative.

• Quantitative: Expect a linear increase in productivity with the addition of a new team member, i.e., 3 engineers, will accomplish 3 times more than one engineer. The output could be measured, and goals can be set based on such measurement.
• Qualitative: Expect an exponential increase in productivity with the addition of a new team member.

At the early and even more mature stages of your startup, you should apply a more qualitative approach to your team building. I have tapped into my network and was able to get top people who are able to take a problem from zero and turn it into one with minimum supervision and most efficiently and elegantly.

Invest in interns.

It’s no secret that it is incredibly difficult in today’s job environment to find quality people. Groom them yourself by bringing summer interns or coops early on. They will learn on the spot and will form the hiring pipeline. We were fortunate to recruit a computer science major from MIT.

Do not over-hire.

It’s very easy to get carried away with the hiring, so in this section, I wanted to list the typical positions which form a scrum team and emphasize an argument whether or not the position is vital to be fulfilled at the early stage.

• Software Engineers: The number of engineers to hire into the team should directly correlate with the product road-map. I typically prefer full-stack engineers, but getting a specialized web developer also could be beneficial for some projects. Be careful though; engineers are expensive. Stay as lean as you can until you lend a customer.
• Product Managers: A major responsibility of a product manager is to be a liaison between the customer and the tech teams. If you don’t have a customer, you don’t need a product manager. Remember, the user who is trying your software is not a customer yet. He/she is still in the sales process and, therefore, under the “jurisdiction” of the customer development (sales) team. In our case, the customer development and tech teams were tightly integrated to be able to react to the potential customer needs as rapidly as possible. The opposite is true; if you have a customer, you need to bring a product manager on the team for this person to manage the customer expectations, write user stories, manage the backlog, etc.
• Quality Assurance Engineers: Whether or not you need to bring QA engineers early on again depends on whether or not you have a customer. In my opinion, the major responsibility of the QA engineer is to make sure regressions are not introduced with the new release. In our case, we did not bring QA engineers early on. The whole team took responsibility for testing and case writing.
• UI/UX: Part-time basis. Today’s users, no matter enterprise or consumer demands a high-quality UI and interaction. A good UI/UX expert can significantly elevate your product offering. You don’t need to hire one full-time, you’ll be surprised how much can be accomplished on part-time basis.

Many times, I am asked, if the team requires IT engineers, release engineers, project managers, etc. The short answer to that — for the early-stage startup using HCP (like AWS), the developers should pick up that work.

Stay laser-focused on product delivery.

Life could be exciting at a startup. As a CTO, you would be pulled into investor meetings, customer visits, interviews, etc. But remember one thing: The primary responsibility of the CTO of an early-stage startup is product delivery. So, be very selective and strategic when deciding which meeting to attend. Remember, there are 24 hours in a day, and there are many days when you need to use all 24 for your work. Maintain your focus at all times.