New Developments is a series about internal tools and the people building them. This week, we talked to Curtis Cummings, a Senior Software Engineer at On Deck. Curtis walked through how On Deck scaled their internal tooling quickly to support hyper growth, and how they approach building MVPs in low-code tools.
Introduce yourself and your team!
I'm Curtis Cummings, and I'm a senior software engineer at On Deck. On Deck's mission is to build the modern education institution. So think of what Stanford would be if we built it native to the internet today.
We're building a new approach to continuous online learning, delivered through 6-10 week programs or cohorts that have 100-200 people in each. The programs are highly curated with a lot of emphasis on peer to peer learning. In 2020, we had 3 programs and launched 10 cohorts, and right now we've got 17 programs. We're on track to launch about 30 programs this year and a total of 120 cohorts.
The cohorts mostly live in Slack for communications, but we also have an internal tool that is our version of LinkedIn, very high signal. And it's for active fellows and alumni who want to continue to take part in the On Deck universe.
How do internal tools help your company grow?
So the interesting thing is On Deck was built entirely with no code and low code tools. So everything from our website to our application forms and all the processes in between were built on things like Webflow, Airtable, and Zapier.
So internal tools have been vital to allowing us to start as a scrappy startup with just a few people, but doing the work of tens of people. We've actively built platform features to enable no code or no code development because we believe in it so, so highly. We're launching programs and cohorts constantly, and it's a very engineering heavy process. So while that was okay when we had three programs, it just does not scale when we've got the number of programs that we're planning to launch.
Without significantly scaling your engineering team, we empower the operations team to kind of do whatever they need to do to launch these new cohorts and these programs without involving us.
What kinds of internal tools does your team build and maintain?
We've got a whole bunch of tools built in Zapier and Airtable. So a lot of automation tools, but we also make really heavy use of Retool now. We've built a bunch of tooling for operations teams to manage all the program, every facet of a program in a cohort, including all the member management. We've also built a light CMS so that we can communicate weekly updates to fellows.
And right now I'm working on a bunch of tooling around Slack for mass messaging, doing a bunch of invites, and the manual work that we take hours and hours to do every week. And we're going to roll that up into a Retool app.
What does your internal tool stack look like?
The LinkedIn tool is built all with code, but we actively build out the platform to enable more no code stuff. So we have Zapier integrations, we have Integromat integrations, and now we're integrating with things like Billflow, still making heavy use of Airtable.
We have probably the most intense Notion workspace you could imagine. It's almost like a crazy web app all on its own. And we encourage folks to experiment with new tools. So there are probably 5 or 6 that are kind of out there on various MVPs and experiments. One really cool thing about On Deck is we're currently about 90 people, but I'd say half of those could qualify as no code operators anywhere. So we've got a huge amount of talent that is really proficient with no code. And so they can just run on any sort of problem and build up these really high impact MVPs.
We search far and wide for different tooling. And we usually do spikes of MVPs, and if it works, it works. If it doesn't, then we, we can move on to the next tool so that, but that's the core stack.
The integrations are kind of all over the place. The main one is Postgres because the directory tool is built as like a code stack. So Postgres is our database, but we're starting to pull in Data Studio, we're pulling in Stripe data now, integrating with Slack, we've got a couple other REST APIs that we've set up, etc. And we also use some custom queries where we're using just huge chunks of Javascript for running some custom internal processes.
What's the most frustrating part of building and maintaining internal tools?
I'd say one of the biggest ones that is very recent is sometimes they become single points of failure. So we rely heavily on Airtable and they've had a couple of downtimes recently. So we haven't really found a good way to replicate that. Luckily, the downtimes aren't too severe and they usually come up pretty quick and then we can just continue as normal.
Another one is – especially coming from an engineering environment – I'm used to more mature tooling around testing and environments. And so this is one thing I really loved about Retool is you have the concept of staging and production, resources, and apps. So I can take someone who's pretty new on the job, throw them into a staging environment and be very confident that they're not going to mess with any of the production data. If you compare that to something like Zapier stack, It's really easy to trigger a bunch of workflows by accident and then send out a couple of thousand emails to someone that you really didn't intend to send to.
How does your approach differ between internal tools and the core product?
We don't have, besides our website and application flows, anything that's technically external. Everything is internal and all these fellows become part of the On Deck universe. So they are our internal customers and it's a pretty small subset of people. So when we evaluate building a tool internally for the On Deck team or for the fellows, it's pretty much the exact same thing. We use the same stack of no code tools.
When should you build an internal tool vs. buy it?
That's a pretty interesting one. On Deck does something a little different than I've seen at most other startups. We won't build an internal tool ourselves unless we built a V1 with no code or low code tool first. In most cases, the scrappy MVP gets you 70 or 80% of the way there. And along the way you gain all these insights and user data to actually back up and validate why you built it and things that you might want to improve. And then from there, there have been cases where that 20 extra percent was worth building internally.
And that's just something you have to evaluate on a case by case basis. Like, is that 80% tool good enough? Or do you want to spend all the engineering resources you need to get that extra 20%? I've been on a couple of different projects in my consulting career where we had this perfect spec, we built it perfectly to spec, went out to users and it fell flat on its face because all the assumptions that backed up that spec weren't validated or grounded in user data.
So we built something nobody wanted. That's why that a no-code MVP is really important to actually validating what you're building before you put a bunch of engineering resources onto it.
We've done the same thing for external tools and internal tools. So we've built out things like matchmaking processes that were based mostly in Airtable and Zapier. And then once it made sense and we knew the different pitfalls of different approaches, we built some of that into our platform. So all these different ways of getting cross program collaboration usually get spiked out as an MVP. And the fellow has actually used that MVP before we actually build it into the platform.
How do you measure your success and improve your internal tools?
Yeah, that's a really good one. It's more art than science at the moment. We're growing so incredibly fast that it becomes very obvious and painful when a tool isn't pulling its weight or it's becoming a bottleneck.
So we're getting more sophisticated at identifying someone's weak spots, but like I said, it's still kind of an art. We can use some of the metrics that we get from the fellows in terms of their satisfaction, to know if there are any other gaps in like their experience that we can use with the tool, but the tools themselves, they kind of talk to us. They tell us when they're, they're struggling and we've had to rewrite different tools or switch tools entirely when they start buckling under the weight of the load that we give them.
On Deck is hiring!
If you're interested in joining a rocketship startup that's just entering hypergrowth, and want to work with a remote first team full of the most impressive mission-driven individuals you've ever worked with, checkout beonddeck.com/careers. We're looking for senior engineers that are proficient with no code tools and machine learning.
The stack we use is React, Next, GraphQL, and Prisma, just to name a couple. My DMS are open, so feel free to reach out to me – Curtis J Cummings on Twitter, or you can email Curtis at beondeck if you have any questions.