From Gynger’s earliest days, the team had a clear mission: to build a product that would allow customers to buy software and infrastructure on their own terms.
The goal, according to Product Lead Varun Sridhar, is to empower these companies with flexible payment terms for all their software, infrastructure and advertising expenses.
However, like many ventures, Gynger faced its share of obstacles. The team’s initial concept centered around a sales acceleration tool for SaaS vendors with financing options, but while talking to potential vendor clients, they discovered this was a lengthy and complex sales pitch, as different enterprises had their own processes around sales. During these conversations, the team was introduced to customers of those vendors who were looking for flexible payment terms — which was the real turning point for the company.
Rather than slowing down, Gynger’s team forged ahead, informed by new findings. The team decided to build a platform for startups and enterprises to finance all their tech spend, with the focus on a seamless user experience, quick approvals and direct vendor payments. At the same time, the team pivoted the vendor offering to be a complementary app that is low touch, requires no integration from vendors and gives them the ability to close deals with customers who need flexible payment terms.
“We believe we can become the payment platform with built-in financing that companies will use to manage and pay all of their technology vendors,” Sridhar explained.
Built In sat down with Sridhar to hear more about the importance of listening to customers, adapting to changing market dynamics and nurturing a positive workplace culture on the way to achieving ambitious goals.
What was the vision behind building Gynger?
We realized there is a huge opportunity to build a product that allows customers, specifically startups, to buy software and infrastructure on their own terms. The total addressable market for such an offering is massive since it essentially encompasses the SaaS/IaaS industry as a whole. The industry continues growing every year, yet the process of buying software and infrastructure for our target customer is inefficient and difficult.
We believe that providing founder-friendly and non-dilutive financing to companies — which allows them to access flexible payment terms for all their software, infrastructure and advertising expenses — is a game changer.
“We believe providing founder-friendly and non-dilutive financing to companies is a game changer.”
In some cases, there is even a discount-arbitrage play where companies can obtain big discounts by signing long-term commitments for business-critical software instead of going month-to-month. In that case, Gynger pays the lump sum upfront, and then the company can choose the flexible repayment terms that work best.
We want companies to focus on their growth while we help them improve cash flow and extend runway in the background.
What role did you play in developing and launching Gynger’s applications? What tools or technologies did your team use while building?
I lead product at Gynger and have been closely involved in the entire lifecycle, from ideation to launching version one and every subsequent version of the product. I spend my time continuously iterating on features of the current product while also planning what we build in the future based on feedback we are getting from customers and prospects as well as evolving industry trends.
Our app is built on the Google Cloud Platform and Firebase using Firestore for document storage and a PostgreSQL database for all our data. Our tech stack is Typescript using Node for server-side and React for the front-end, similar to stacks of many other modern web applications. It allows our developers to rapidly develop and iterate without needing to switch between frameworks or languages.
We use GraphQL for our entire API architecture because it is developer-friendly in addition to the number of benefits it offers over REST, like smaller payloads with declarative fetching, powerful tooling and no API versioning. We are heavy Retool users and have implemented a variety of admin dashboards to act as de-facto finance and operations teams as well as interact with the graph for ongoing workflows or one-off updates.
What teams did you collaborate with in order to get this across the finish line?
For the initial months, we were a very small team consisting of two engineers, one QA, one designer, one product expert and two sales people. As we have grown, we’ve added on our CTO, more folks on the engineering side, we’ve grown our go-to-market team with marketing, account executives and business development representatives, and we’ve added a credit risk team.
Throughout our journey, I’ve tried to maintain the balance between being extremely nimble and process-oriented at the same time.
“Throughout our journey, I’ve tried to maintain the balance between being extremely nimble and process-oriented at the same time.”
On the product, engineering and design side, we maintain a two-week sprint cadence with a daily standup, and our JIRA board is the source of truth. We keep dedicated times for design feedback sessions, tech design reviews and sprint retros. We have a biweekly product and marketing sync to ensure the website and app are aligned from a branding and storytelling standpoint while marketing offers the most recent updates in the product for use in campaigns and outreach. There is a biweekly product and sales sync to solicit feedback from sales on features that go directly into our backlog and roadmap planning. Separately, we have dedicated channels on Slack for all of these forums for anything urgent and ones for product issues and updates and individual customer accounts.
How do you lead the product team to success?
I try to maintain full transparency across product, design and engineering in terms of what product and design are currently working on and to provide a forum where everyone can critique product and design decisions, voice what they would do differently or share any concerns that they may have with the approach or timelines. When it comes to roadmap planning, I try to synthesize and distill discussions with leadership and sales into actionable epics or features that we then discuss together as a team — the motivations, the approach and the desired outcome as well as the level of effort.
What’s different about how Gynger works?
We are one team marching towards the same goal. We may be geographically diverse with a big presence in New York, but everyone is engaged and in good spirits, which all comes down to the culture. The larger team is provided visibility into company strategy at all times and leadership is very active and engaged on Slack. Everyone is recognized for their hard work and wins during weekly all-hands meetings as well as on Slack.
In terms of how we’ve operated — we’ve been careful about burn and hiring too quickly by being lean during the initial building phase and learning from industry trends and early customers. We didn’t want to dedicate too many resources or time to what we believed was the final version of the product and instead focused on building iteratively and in small steps. We have found success so far in taking feedback and potential hypotheses we’ve had and then deploying features to solve for them, often starting as a proof of concept, using a rapid design and development methodology.
