Tech stack to build SaaS -Reimagined

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:

1. customer management had to be automated and couldn’t rely on a manual process (managing trial period, upgrades, downgrades, etc)
2. 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.