Tech stack to build SaaS -Reimagined
After 3 years of pivoting DronaHQ to a SaaS model — we have learnt a few things while building the SaaS platform while keeping a laser sharp focus on velocity and growth. But before I get there, let me give a bit of background.
DronaHQ was a rapid app development platform till 2019 march. 2014–2019 our sales and marketing was focused on selling enterprises a platform to build their mobile applications on the RAD platform. Platform was cloud native and it gave a bunch of SDKs to our customers using which they would build their applications. Our distribution was top-down and our customers were business buyers in large enterprises. Say HR or Sales or Marketing heads would signup building their application on the platform. Behind the scene — we would have to create an account for the customer on the platform and give appropriate licenses to the account. Top down meant sales was 90% outbound and sales cycle would look like: leads ->demo -> proposal -> Closure. Everything under the sun that Aaron Ross would write in Predictable revenue is what would be applicable in our operating model. At a high level (product & sales) & (product & marketing) were mutually exclusive and had 0 integrations between the two systems.
2019 March we went beta live with our evolved RAD — Low Code/ No Code platform and we also made it SaaS enabled. This meant we were now opening the door for bottom up distribution. As signups grew, we were staring at a few challenges ahead of us:
- customer management had to be automated and couldn’t rely on a manual process (managing trial period, upgrades, downgrades, etc)
- our sales team wouldn’t be talking to every prospect to convert them to a paying customer. Nor could we add every prospect from our signup into the CRM as is to manage the lead due to multiple reasons. One major reason — SaaS was self serve.
We now had to reimagine our customer journey from visitor to paying customer and figure intersections where our sales, marketing and customer success team would get in touch with the customers and figure out tools that they would now need to help them do their job.
At a high level customer journey looked like Visitor -> interest -> evaluate-> engagement -> purchase -> Renew. Let’s take an example by zooming in to this customer journey. Say in evaluate phase — customer may need an extension of evaluation. A simplified user story would then be — account executive would get a request from within the product and he must have a simple interface to add a trial extension.
Similar such commerce enablement features would be needed at every step in the customer journey.
Subscription management, Invoice automation,Annual contracts & license management, Upgrade/downgrade services, Ticket management, Refund management, Promo code management, Incentive management
Now to deliver such stories, your engineering would have had to deviate to non engineering tasks and build the system to enable commerce on your SaaS. This would be super critical for commercial success of your SaaS.
We had to add commerce blocks on top of our SaaS. Our SaaS block diagram now looked like in the figure below
SaaS in last 2 years went on to a >10k MRR service and is growing at 15% on month on month. To enable this growth we had to augment the SaaS engine with commerce modules and even integrate them to existing business systems like CRM/Payroll etc at a break neck speed. Besides there are many moving parts to the commerce. For instance pricing, business model evolves as we keep learning from the customers & the market.
Besides we also had to deep integrate usage metrics for every prospect in sales CRM and make it available on a dashboard for our inside sales to be effective. For instance we now were looking for a leads who had created x apps or added x users or consumed x tasks. This list of users had more probability to have positive conversation with our reps and further engage to convert them. And we were looking for every data point that we could capture — support tickets, website chat, automated emails, marketing newsletters, questions asked in the events and tag it to a user. On the other side of things — website & support had to be integrated with the product. For instance — whenever we were adding new templates, we wanted them to be real time synced and available on our website. Similarly our support had to be available on the platform for developers to easily raise and track their tickets.
Given our engineering team was already pressed with a super aggressive roadmap — building these modules and integrations looked like a big daunting task & could have spread our engineering thin and defocus attention from building the core platform. To overcome this — we decided to integrate low code into our tech stack with the scope to build commerce modules. And this paved the path for us to dog food our own platform. This decision worked wonders for us.
We enlarged the scope of our CRM from lead-to-win to visitors-to-renewal system and made it a central system cutting across rev-ops, marketing ops, sales & support. So we would build commerce services in the product and make it accessible to commerce teams at DronaHQ via the internal tools that would be built with DronaHQ low code platform. We assembled a 2 member team from our non engineering team and tasked them with building internal tools that would eventually deliver the visitor-to-renewal process.
Non engineering team now picked up the above business modules of our SaaS system in its sprint. Scope for these modules extended from self-serve, sales, customer success and account management teams. This team built the modules and stitched it to our CRM (central tool to manage leads, customers & accounts), also built workflows and processes including APIs to be used by the engineering team to integrate the events generated in the platform into the central system. So in a nutshell — engineering got augmented by the non engineering team with the help of low code to increase the pace at which the process was to be delivered.
In the hindsight, adding low code to our stack helped us
- build these modules way faster
- stay super agile to meet ever evolving business requirements.
for instance upgrade/downgrade service was not our day 1 requirement. But as number of customers grew and such requests increased, we took it up to build the service with low code.
