Power User Spotlight: FOXO’s Calli Clay, Andee Burling & Quinn Chu

All three were hired as software engineers by the CTO of FOXO, a company at the forefront of commercializing proprietary saliva-based epigenetic biomarkers with a plan to create a non-invasive underwriting process. FOXO hired candidates with roughly three months of coding experience to build their MVP… in just three months. We spoke with Andee, Quinn, and Calli to learn more about their career changes and achievements with codeless development.

 

Let’s start with some introductions. What was your application development background before joining FOXO?

Andee: Interestingly enough, all three of us are from the same coding bootcamp. We were hired by our CTO because he had great experience with the Unqork platform and thought it would be beneficial for us to learn how to use it. FOXO wanted to build an MVP of their product quickly—that also looked good. Not having to use code and leveraging out-of-the-box features meant that developing an MVP could realistically be done in three months, as opposed to six or nine.

Quinn: I studied Media Studies & Cognitive Science in college, and I basically went into bootcamp straight out of graduation. During undergrad, a lot of the computer science I was exposed to was the very early stages of coding and website building, which felt more democratic. As you go on with learning how to code, there is a higher barrier to entry for successful front-end coding. I think that working with Unqork was a really interesting way to reflect on that because Unqork recaptured some of that democratic “anyone can code” approach for me.

Calli: My experience is similar to Quinn’s. I went into the bootcamp right after I graduated from college, where I was introduced to some back-end coding work, with a degree in Mathematics. I didn’t really have any experience with front-end development, and that’s where Unqork steps in. I can easily push out something into the UI and not focus on its placement, so those out-of-the-box Bootstrap features have been very nice to use.

The fact that we are able to build something like this for a tech company is a testament to how no-code surpasses generational gaps, and how the Unqork CMS is great for building for anyone.

Andee: I want to add to how user-friendly the Unqork experience is. I’m 13 years older than Calli and Quinn, and I have a Bachelor of Science in Nursing. I graduated college in what feels like a different era. Before coding bootcamp, I didn’t know what a zip drive was and how to use it. The fact that we are able to build something like this for a tech company is a testament to how no-code surpasses generational gaps, and how the Unqork CMS is great for building for anyone.

It’s interesting that FOXO hired three people without traditional, long-term coding experience to work on such a big project. Was that purposeful?

Calli: Yes! We were all hired specifically to learn and config in Unqork. That was what Tyler, our CTO, was looking for. He had utilized the coding bootcamp that we were in at other companies, so he recognized that we were all adaptable and able to shift from one area to another.

Andee: We’ve been described as Swiss Army Knives of the company because we work really well together and are able to learn quickly. Working in Unqork also provides a lot of opportunities for pair programming which allows us to discover different approaches to things. I feel like if we were working with code, we wouldn’t be as close as we are. 

What are the specific requirements of the project build, and what features are you using to meet them?

Calli: Andee and I are on one project, and Quinn is on another. The two of us are building out a life insurance product powered by molecular health technology. We’re focusing on a mobile-first design and the ability to apply online in record time to help promote longer, healthier, and happier lives for our customers.

Example of a FOXO customer portal.

Andee: You’ll see we have tons of dashboards. I know Unqork originally pitched the ability to customize using simple drag-and-drop functionality, but the vast amount of logic, styles, and collaboration for this means that this is just one example of what we can do. It is actually pretty cool that the same Unqork platform can be used to build very different products with very different experiences.

Quinn: My product, a study tool, deals with the scientific testing side. FOXO has several partners for clinical studies and data collection. The product I’m building is a questionnaire-building tool that allows the study managers to conduct studies and reify data.  Unqork has been really instrumental in making the UI streamlined to boost completion rates for participants. 

Andee: Quinn’s application is more clinical study-focused, while we’re consumer-focused. We utilize the Unqork workflow whereas Quinn’s product utilizes orchestrator modules. Again, very different experiences and very different use cases, but all within one company. I think that’s what informed the choice of platform: handling all these different workflow requirements in an efficient manner. 

For us as Creators, we’re going to leverage features like Snippets for when we want to do a quick proof of concept—I just drag-and-drop a general form field. Key integrations with Google Maps are already set to go. Unqork already has ways for us to process data within the data workflows, which is super important for both of our products. We’re utilizing the node package manager, Nunjucks, and query parameters so we can leverage API URLs and query the MongoDB database that we have access to.

Both these projects seem like big undertakings. How fast were you able to move?

Andee: Within three months of Calli and I starting, we were able to put together a large part of our underwriting engine workflow. For us straight out of bootcamp, being able to accomplish that and then our leadership being able to demo it was… I don’t even know how to explain the experience. We were so nervous at demo time, but we were so, so proud of the work. 

Calli: As soon as we finished our Unqork Bootcamp training, we were just thrown right into building this application from scratch. There was nothing there when we started. We went in and built out all these questionnaire modules.

[W]e actually often run into the scenario where development overtakes the design process. They’ll have designs and we will complete development so fast that they actually run out of things to give us…

Quinn: For the study tool, we actually often run into the scenario where development overtakes the design process. They’ll have designs and we will complete development so fast that they actually run out of things to give us, which is an interesting problem to have. So, it’s more of an iterative process, but it’s been very efficient. Especially after we discovered this JSON copy-and-paste functionality, where—if we were really consistent with our naming conventions—we could just replicate a bunch of modules really, really quickly. Unqork’s imported module functionality has been really helpful in getting things developed really quickly, we just reuse components over and over.

I think the UDLC toolkit is so helpful to quicken troubleshooting, too. A lot of debugging tools can get a little bit too granular, so I think it’s really helpful how the toolkit gets broken up into API calls and you can compare submission revisions.

How was your experience learning no-code with Unqork’s resources?

Calli: We continually use the Community Hub to look for answers to some of our more weird config questions.

Andee: Unqork Bootcamp definitely helped set up the basics, but I didn’t realize how creative you could actually get with config until we were thrown into the project. It’s our first experience with Unqork and it’s just been fantastic. When we first started, our project manager and our tech lead were both from Unqork, and that really helped define the culture and the relationships of our current team now. When we run into issues or have questions, I feel like there’s always someone there from Unqork to help.

I also sign up for Unqork’s feature showcases, which is another way I learn aside from the deep dives in Bootcamp. We definitely needed the guidance of someone more senior in the beginning stages to help us get our footing.

Calli: I think what we’re doing with our products is also kind of outside of Unqork’s typical basic trajectory. We’ve learned a lot of interesting ways to use Unqork to successfully get what we want out of it.

Speaking of resources, do you leverage Unqork Marketplace at all?

Andee: I’ll go on Community and look for help with a specific problem and then realize that a new Snippet or set of modules just came out on the Marketplace to help with that. The DocuSign integration and the looping Snippet come to mind as examples.

Calli: I use it in a similar way, too. When we want to implement some complicated config or set up some basic integrations that we can then tailor to what we need, it’s definitely something we utilize quite a bit. 

Do you have any best practices for Creators beginning their no-code building journeys?

Calli: Use the config analysis tool and establish a cadence for it. For example, when we started building out our application, we weren’t paying attention to the fact that buttons should be set to single-click to improve the user experience. The config analysis tool flagged that. It helps us fix things we weren’t doing correctly or optimally.

Andee: We’re using the analysis tool about two times a month in two different environments. It actually helped facilitate a discussion with our Security Officer at the company and align with their policies for review and compliance.

Calli: We incorporate anything that comes up on the config analysis into our sprints. So we dedicate a number of tickets to either fixing some of these issues or determining that it’s something we can’t do. The most important thing is flagging what may or may not be security risks—those are our highest priority.

Quinn: On my side of things, we have a tagging system for all of the sensitive health data we’re collecting. We have an entire data dictionary created by the science team, so we make sure those names are mapped directly onto the component IDs of the data-specific information we’re collecting. Standardization and consistency was a critical first step to take before getting into building any of these modules, so I recommend setting up a process for that at the beginning.