‍

Disclaimer: The following transcript has been edited for clarity and readability. Some parts of the conversation may have been condensed, rearranged, or paraphrased to improve comprehension.

[Ruben Izmailyan]

At the core, I would say the secret sauce of Quiltt is that we're a unified API for multiple different types of APIs and data providers. And we're normalizing that into a single standard data model. So one of the assumptions that we made was, okay, we're solving the backend problem, and that's the really hard engineering problem.

The front end, that's easier, we can deal with it later or our customers can figure that out. One of the learnings from our last year in beta, they're coming to us to solve integration issues, right? They wanna make it easier to access this data. They wanna accomplish a particular job.

My name is Ruben Izmailyan, and I'm the co-founder and CEO of Quiltt.

[Code Story]

This is Code Story, the podcast bringing you interviews with tech visionaries who share in the critical moments of what it takes to change an industry and build and leave a team that has your back. I'm your host, Noah Lahar, and today how Ruben Izmailyan is stitching together consumer FinTech, enabling you to launch innovative technology.

All this and more on Code Story.

Ruben Izmailyan, grew up in Armenia originally, then moved to Russia when he was 12. When he was 14, he and his family came to the US and eventually he attended Brown in Rhode Island. He's an avid barbecuer, which fits perfectly now that he's living in Texas with his young family. He did let me know that he was even into this style of cooking when he was living in Brooklyn against the wishes of his landlord at the time.

In a previous role, Ruben was made aware that although financial institutions and brokers had access to useful data, normal consumers did not. Starting out with the budgeting app, he and his team ended up pivoting to creating the tooling and infrastructure needed to interact with financial data sets.

And this abstraction started to gain traction. This is the creation story of Quiltt.

[Ruben Izmailyan]

The idea behind Quiltt is to empower, all sorts of users, technical and non-technical, to really quickly connect customer accounts, stitch different financial APIs together, and ultimately kind of release, intelligent workflows and user experiences to market. So the genesis of the company really started out with kind of my own personal sort of struggles with personal finance, was actually living in New York at the time, worked for a financial data company, more like Wall Street type of stuff, and was really flabbergasted by the fact that we had this amazing technology for, investment banks and hedge funds and all these type of kind of financial companies to interact with data and to make good data driven financial decisions.

But, for most of us, regular people, we're stuck with mostly kind of antiquated technology. A couple of budgeting apps here and there that are really laborious, generally take a lot of time to set up. So around the time I moved from New York to Texas, I had a bit of a quarter life crisis and realized that I wanna be building stuff.

I don't wanna be, I was in a sales type of function before, so I actually, got back into programming. I did a lot of programming in high school but hadn't done it since high school and started hacking away at a couple of ideas that I had in mind. Started playing with some of these newer APIs, really starting to really open up kind of new plumbing and new ways of programmatically getting data out of our banks.

And so was working on a couple of these budgeting ideas, realized that I needed to become like a really good engineer to build something good. So at the time was fortunate enough kind of to have an opportunity to invest in that a little bit. So I started working professionally as an engineer, mostly self-taught.

I did one of those boot camps that helped me get started a little bit. And eventually, we put together this budgeting app that we started selling into community banks and credit unions to add into their offering. One thing led to another. We ended up eventually pivoting from that, from having an actual app ourselves to providing a lot of the tooling and the data infrastructure for folks to be able to interact with these type of data sets without necessarily kinda going through the struggles that I went.

Hooking everything up and really learning the ins and outs of these systems. So the idea really has evolved into building this kind of new abstraction layer for this increasingly fragmented and sophisticated, landscape of data infrastructure and APIs that are available in the consumer financial services space.

[Code Story]

Okay, so let's dive into the MVP then. So tell me about that first product you built, that first version. How long did it take to build and what sort of tools did you use to bring it to life?

[Ruben Izmailyan]

to the point where it was a functional MPV, probably took me at least a year in part because I was learning as I go.

So it was built in Ruby on Rails, standard relational database. Postgres Ruby on Rails. Hosted it on Heroku. Really, I tried to maximize using the kind of tools that were just accessible to somebody like me because I, I knew what I knew and I knew what I didn't know. And using things like Heroku for example was a no-brainer for me because, I didn't know what a load balancer was and I wanted somebody else to figure that out for me. I'm a huge fan of Rails. We still use Rails extensively in our application so it was really mostly reaching for the kind of tools that, I could use and that would make me productive as an engineer.

And the MVP, essentially what it would do is it would allow you to sign up, connect your bank accounts using the Plaid api, and then we would essentially analyze that data and we would put together this holistic financial picture of you. So from the basics, like what are your accounts and transactions to a lot of derived data sets like what are your recurring expenses? What is your income? When do you think you'll run out of money or when much will you be able to save, at this type of a spending clip? And so the next phase for us was starting to build different sort of scenario modeling tools.

We had a couple of sort of developments that led us to abandoned course a little bit and start focusing on infrastructure that we had built. We were better at building the infrastructure than building, really dynamic user experiences. Frankly, I was just seeing so many entrepreneurs and so many companies really wanting to leverage this new tooling that was available, but feeling locked out because of, often just how much stuff you need to build in.

And I felt that a lot of this tooling should be, more available off the shelf, should be a little bit more repeatable. Everybody shouldn't have to translate the way a particular API models out the finances of the person into their own data model. When the data model ultimately, should be a little bit more canonical, right?

Like person has a certain set of accounts these accounts are cash, these accounts are liabilities. Being able to figure out recurring expenses, like someone’s Netflix bill or somebody's rent. These are really important things to understand about a person if you're gonna be building any kind of financial experiences, particularly those oriented around driving better financial outcomes and financial wellness for folks. So we really decided to focus on that side of things. And that's when we essentially, reincorporated as Quiltt. The old company was called something else, it was called BudgetIt and we decided to go down this infrastructure direction.

[Code Story]

Okay so from that point then you have your MVP, you've reincorporated as Quiltt. How did you progress the product from there and mature it? And I think to put that in a box a little bit, what I'm looking for is how do you go about building your roadmap and how do you decide, okay, this is the next most important thing to build for Quiltt.

[Ruben Izmailyan]

The easy answer right is you put this in front of customers and folks that can tell you what they want. I think that's the age old way of building products. At the same time, I think most of the experiences we have with financial tools typically come from really large and sophisticated institutions, right?

Most people bank with a major bank like a Chase or Bank of America. And so we'll look at their app and we say, okay, this app has a bunch of features that we don't need. And I could always do it better. I just think that's something that I see a lot with folks in this space is there's a lot of creativity.

Everybody has an opinion on money. Everybody has an opinion on how to better present and show information to folks, but the reality. That I think most folks run into as they start building in this space is that, hey, there's a lot of things I didn't think about. There's a lot of these additional, data sets.

There's a lot of this complexity. Not to mention the bar for security being much higher in this space than in some other spaces. Perhaps part of this is combining the kind of stuff that our early customers would tell us with frankly some intuition and some kind of creativity that we had myself and my co-founder, and then, as we brought on more folks onto our team, we really prioritized kind of hiring people that had a certain opinion or maybe not the most positive experiences with the financial system, right? Because ultimately I think you need to have that kind of empathy for the end users.

But then also have empathy for the builders, right? Who are gonna be, either sort of software engineers who are just trying to get their job done, or it's gonna be a startup founder, who left some kind of a nice secure job to to build something brand new and really, needs to hopefully have somebody that can help them avoid a lot of the common mistakes when you're building with financial data and when you're building the type of experiences, to put in front of end users.

[Code Story]

Let's switch to team then. So how did you go about building your team and what did you look for in those people to indicate that they are the winning horses to join you?

[Ruben Izmailyan]

Currently we're a team of seven. Seven full-time rather. And the main focus in the early days is convincing somebody to come join us on this crazy ride before we have money before there's a lot of uncertainty right, at the really early stages of a startup. So I think the first kind of domino to fall really was bringing on my co-founder. So Mark, him and I are old time friends. He actually got me into barbecuing in Brooklyn many years ago.

So we're old time colleagues and we had that personal relationship. He was at a bit of a career crossroads and we started chatting. He's the best salesperson I know. I really wanted somebody to help me with that side of things. And so he came on board and, that was like incredibly validating, right?

I'm working on this thing and you off to feel like a crazy person in the early days of any kind of a startup, particularly, pre-funding and getting him to join was a really big deal for me, frankly, psychologically. And I think it made it feel like a real company for the first time.

And then, in 2020. When we really transitioned into Quiltt, we were fortunate enough to raise a small preseed round of capital and that kind of allowed us to, go out and hire, additional folks.

The first priority for me was of course, as the product, this should be bringing on engineers but not just any engineer, I really wanted somebody that would start off as a kind of thought leader, a peer to me, and eventually eclipse me in many ways, right? I don't have the most traditional background for a technical founder, and I think that can be an advantage in many ways, but it can also be a disadvantage in certain contexts.

So getting somebody who really both had a passion for the type of problems that we're solving, but also had experience in this domain was really important. So we hired, our lead engineer, came to us from Chime, which is a big neobank, probably the biggest neobank and the most successful banking startup.

And so yeah, he was a really transformative hire for us in that he went in and started deleting most of my code, which is always really fun. Deleting it and replacing it with better code, of course. But I think somebody, who has the confidence to come in and leave their own footprint on this thing.

And I think that's really important at the early phases, I think a lot of founders tend to be, because you start out having your hands in everything, there's a sort of fallacy that I've built this thing so you know I'm in charge of it. And, you kinda have to realize as early as possible that, my job as a CEO of a startup is to first and foremost build a team of people that are better than me at X, Y, and Z.

And eventually get to a point where, maybe I'm helping direct traffic and helping unblock people. But ultimately, There's not a single, I think, transformative type of company, particularly in this space that's built by, one or two people, right? It really takes a village to build, any kind of a really complex software product, but especially, something like this where we're effectively asking our customers to trust us with a really important part of their applications.

And so making sure that a team behind it isn't just a, somebody who's, for lack of a better word, somebody kind of clocking in and out and doing the work, but actually cares about the product in a deep sense. That's really important.

[Code Story]

Let's flip to scalability then. So was this built to scale efficiently from day one? I guess this would be rebranding from Quiltt or sorry, reincorporating as Quiltt. Did you build it to scale efficiently from that point, or are you finding this as you grow in capacity?

[Ruben Izmailyan]

I think we, we made a lot of really good architecture decisions early on, in part because again I was learning as I go and in the very early days, so I was trying to do things right, so to speak. And perhaps if I were to do it all over again, I wouldn't have optimized for some of the things I was optimizing in the very early days.

But, one of the reasons why I was really excited to collaborate with Zane on this, is that Chime is, I believe, the fifth largest bank in the US by cardholders. I think they have more customers than than Citi. And he had touched and built systems that were being rolled out to millions of customers, right?

That was a really big litmus test for me is frankly, getting a sense of his reaction and using his expertise to see, what of our core stuff needs to change and when. And so we've been incrementally addressing scalability issues. We just migrated off of Heroku onto a serverless AWS database, so trying to focus on kind of the worst case scenarios or the best case scenarios, depending on how you put it from a scaling perspective.

But in general it's pretty core, I think, to the DNA of a company, to make sure that any feature that we roll out, can work, just as well for, 10 customers as a thousand customers, right? So I think it's really important to solve these problems early on because it's never gonna be easier to do it later, right?

When you're having, production outages because you design something wrong. So yeah it's something we think about quite a bit. I think there's a lot of trade offs too, right? If, for particularly for companies that take home venture capital, you just have this default dead sort of perspective, right?

Where you need to hit certain milestones, for you to be able to continue on your journey and sometimes those milestones may not be, sometimes you can cut corners right? To get to those milestones from an infrastructure perspective.

And I think that's a really important trade off. I view that as one of my core jobs as well, right? Is to balance sort of the trade off of, building a really well approved system, but also making sure that it's not significantly slowing down our ability to build the type of features that our customers want.

[Code Story]

As you step out on the balcony and you look across all that you've built, what are you most proud?

[Ruben Izmailyan]

The team that we've assembled. That's definitely the number one thing for me. I think there's a lot of ambitions that, I have as a startup founder have regarding the success of my company and the impact it can have on our customers and their end users.

But at the same time, I think it's a huge responsibility to have payroll hit, and make sure that, you're able to bring people in that are dedicating, what our sort of prime career and earning years towards an idea that I started with.

So I think being able to really build the kind of team that we've built at the stage that we're at, I think is something that I'm probably most proud of. And then I would say on a personal level, this has been a very fun and rewarding journey in a lot of ways, but it has, by no means, been an easy one.

And so I think the fact that, my cofounder and I stuck through it through challenges and through successes and just stayed on track, I think when, perhaps and sometimes it would've been easier to give up on it. I think that's been also really validating to be in a position that we're in today with a great product with the cash in the bank. It's a really nice feeling and kind of validation for just persevering through the classic ups and downs of early stage startup life.

[Code Story]

Okay. Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.

[Ruben Izmailyan]

I think there was a big assumption that we made that, not to get too in the weeds of the product right but essentially the core product and the core, I would say, secret sauce of Quiltt is that we're a unified API for multiple different types of APIs and data providers. So by integrating into Quiltt, you're ultimately integrating into Plaid’s data network, MXs data network, which are large and very successful aggregation companies in the space.

And we're normalizing that into a single standard data model. And because we're doing that on a hosted basis, we're able to supplement that data that we can access from other third parties. So typically companies would have to integrate with each of these providers, one at a time.

Everybody has their own data model. Everybody has their own sort of data schema. You end up stitching together all this stuff in house and we've basically said, we have a normalized data model and we have these integrations already pre-built, focus on the actual core user experience, don't focus on boring data plumbing.

And, you I think that continues to be the main reason why people are coming to us. But one of the things we never really considered is to use these type of services there is a frontend component, for example, to use Plaid, you need to go through the Plaid link flow.

So an indelible frontend module that you need to configure, put in front of your own user. The user goes through that flow and then we take over from there and, and we do the rest. So one of the assumptions that we made was, okay, we're solving the backend problem and that's the really hard engineering problem.

The front end, that's easier, we can deal with it later or our customers can figure that out. One of the learnings from our last year in beta was that this is true to a degree, but ultimately people are coming to us not for the normalized data model. They're coming to us to solve integration issues, right?

They wanna make it easier to access this data. They wanna accomplish a particular job, and the front end is a really important part of this user experience. You need to configure, multiple providers. You need to set them up a certain way. There are UX trade offs and considerations that you need to think through.

And, unless you've spent a long time playing with these type of services, you don't necessarily know the right decisions to make until your product is out in front of customers and you might be running into some issues. We really didn't prioritize the front end piece. And so that's something that we realized I would say in the fall of this past year and spent the last few months building a, what I think is, a really powerful front end experience.

So now we're not just handling the back end, we're also handling the front end. So if customers wanna handle the front end fully themselves, they still can. So what we ended up doing is we effectively dog-fooded our own API and built the Quiltt connector. So the Quiltt connector essentially handles all the logic and configuration that you would need to use if 99% of the most common scenarios of these type of providers that we integrate. And so now folks can essentially add all the power of the core platform into their application with literally a single line of code that they can copy and paste into their application without losing the flexibility of going custom if they want to.

[Code Story]

So what does the future look like for Quiltt, the product and for your team?

[Ruben Izmailyan]

One of the main ambitions that we have for the next year and a half is to start bringing this type of data into the mainstream for the average tech savvy, but maybe non-technical user. If you look at low-code and no-code platforms like Zappier or Airtable or Notion to some degree.

We're at this really interesting development and on the web where 10-15 years ago, if you needed to build a website, you were building HTML templates, right? That's the only way to build a website whether you're technical or not. And building HTML isn't that hard, and then, you started to see companies like Webflow, right? That came and said, you know what, like building websites is actually building good websites, is actually really hard and there's a way to do this without writing all the code. Here's a drag and drop builder, and all of a sudden really anybody with a creative eye for design or just good visual eye can build incredible websites.

And you're starting to see this sort of leak into the enterprise, right? There are massive Fortune 500 companies that use services like Webflow or in the eCommerce space services like Shopify, right? They're not building all this stuff from scratch and in effect, their engineers are now able to focus on really core user experience problems rather than repetitive and repeatable work.

Our big thesis is that, the same thing is happening in the financial services space. The first domino drop, I would say has been payments. So if you're, familiar with Stripe’s no-code product roadmap over the last year or so, many to most of the things that you could do with Stripe, and Stripe is the original, probably company that made payments not painful for engineers. You can do most of that stuff with no-code now, right? They have these payment links, really powerful web hooks. There's, Stripe Apps and Zapier. There's all these tools and you can increasingly take advantage of the power of a Stripe platform without speaking code.

In the financial services space, when it comes to the financial data space, we just don't have this yet. You still need engineers to integrate with most of the services. Most of the stuff takes longer than people anticipate. The integrations are hard. They can be brittle. The core problem with this is that you are logging out massive current and potential builders from even attempting to solve the inordinate number of problems that Americans have, managing their personal finances and working to live more prosperous financial lives.

And so our big focus for this year is to take the tooling that we've built and make it just, frankly, easier to use for people who don't know how to code. So that involves, Zapier apps that we just launched that's in beta that involves the connector, which again, you don't need to be technical to use.

And eventually it's gonna move into sort of embedable UI components. So we're gonna start with the, copy this line of code to get the functionality. But I think you're getting to a point, pretty soon where you'll be able to do a lot of the common financial data workflows, frankly, with drag and drop and being able to, let us handle the complexity, let our code the type of, user experience is that you're designing without code yourself. I think that the tricky part here, of course, is making sure that these type of systems are not worse than the code-based systems, right? And so being able to build on this, we like to think of it as a no code to all code spectrum.

So it's not that we're, we want to have a no code only product. We want to have a product that's built on code that different parts of it require less and less code so that we can reach a less technical builder over time. And, if folks wanna drop deeper into code, they always can do that.

So that's a big trade off for us as we think about becoming more, no code. I think no code and low code tend to be a little bit over. I really do think most applications that use that term are really on, on a certain, in a certain place on the spectrum. And so we really want to have a product that works across that spectrum so that we can, engineers love us, but also people who, who are like what is code are also able to build really powerful experiences using the same platform.

[Code Story]

Last question, Ruben. So you're getting on a plane and you're sitting next to a young entrepreneur. Who's built the next big thing. They're jazz about it. They can't wait to show it off to the world. Can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?

[Ruben Izmailyan]

Main advice I would say is I think it's very exciting to be in tech. I think it's very exciting to be able to will products into existence. But I think it's also important just to remember that ultimately, depending on what you're building, of course, there will be human beings at the end of this.

Just making sure that you never really lose empathy of the end customer, the end user of your product, I think is really important. I think the related piece of advice would be, make sure you're taking care of yourself. Make sure you're sleeping, make sure you're spending time with your family.

Make sure you're being a full person, which can be sometimes hard to do when you are laser focused on getting a product off the ground. But I think like remaining a functional human I think is really important so that you can build a product for humans. I probably wouldn't be very fun to sit next to on the plane if I'm kinda lecturing people on that.

That's what comes to mind. I think.

[Code Story]

That's great advice. Ruben, thank you for being on the show today and thank you for telling the creation story of Quiltt.

[Ruben Izmailyan]

Thanks so much. Thanks for having me.

[Code Story]

And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Lab Hart.

Be sure to subscribe on Apple Podcast, Spotify, or the podcasting app. Your choice. And when you get a chance, leave us a review. Both things help us out tremendously and thanks again for listening.

‍