Polytomic with Ghalib Suleiman

Outline Summary: Polytomic Platform Overview and Founder Insights

Intro

• Overview: The discussion centers on Polytomic, a unified ETL and reverse ETL platform crafted for RevOps and data teams. The host, Anthony, interviews Gallop (Gallub), co‑founder and CEO, about the founder story, the platform’s purpose, and real‑world use cases. The conversation underscores how Polytomic enables rapid data movement across silos, empowering RevOps to act with data‑driven confidence.

• Key premise: Data often lives in silos controlled by engineering, product, marketing, or finance. This fragmentation hinders GTM teams from acting on complete customer insight. Polytoic offers a single control plane to move data between systems with low engineering lift.

Center

• Founder story and motivation

  • Gallop describes 10+ years in data, leading data teams that served RevOps needs. Frustrations grew as data sat in silos, with RevOps repeatedly requesting essential data (billing, product usage, user activity) that lived behind engineering walls.

  • He reflects on the org silos driven by structure: RevOps, engineering, data, marketing, and sales each owned different data sources. This created friction and bottom‑line impact.

  • Realization: the lack of cross‑team data flow was a revenue risk. The “traffic cop” role in data led to delays that hurt upsell and churn prevention. This motivated building a platform to unify data movement.

• Product vision and capabilities (demo highlights)

  • Demo environment: Polytomic connects to multiple systems and focuses on moving product data into Salesforce—a notoriously challenging use case due to API limits and field quirks.

  • Data models: Define a data model as a catalog of fields from sources to synchronize. Fields are greenlit (authorized) for syncing, creating a portable surface you can reuse.

  • Sync setup: Choose a destination (e.g., Salesforce), select target objects (e.g., Contacts), and pick a sync mode (create, update, or both; with some caution for deletions).

  • Identity mapping: Link source fields to Salesforce fields, using a unique key (often email) to align records. Address Salesforce requirements (e.g., last name) via mappings and overrides.

  • Filters and overrides: Apply text, number, and date filters; use overrides to substitute missing values (e.g., last name) when necessary.

  • Scheduling and execution: Options include manual or continuous (every 5 minutes), with hourly, daily, or weekly cadences. Polytomic emphasizes syncing only changed data to respect API limits.

  • SQL flexibility: Data models can be generated from custom SQL queries; embedded query runner enables ad‑hoc data exploration and model creation. Salesforce sock queries can be run directly.

  • Monitoring: A history and completed logs section provides auditability and direct linkouts to records in target systems. Error notifications via email or Slack keep teams informed.

• Impactful use cases and strategic value

  • The two biggest pain points: product data and billing/finance data. Product data resides in engineering databases; billing data often spans finance and product usage. Integrating these into CRM enables better churn prevention and targeted upsell.

  • Revenue focus: data movement is framed as revenue optimization—retention, expansion, accurate billing, and reduced manual reconciliation.

  • Real‑world claim: a five‑minute setup can move product data into Salesforce, dramatically faster than multi‑week engineering cycles.

• People and process: breaking silos

  • Emphasis on empathy, humility, and collaboration between RevOps and engineering/data teams.

  • Practical advice: start with current priorities, listen first, and avoid “us versus them” dynamics. Recognize the value of small time investments in empowering other teams.

Outro

• Closing sentiment: Gallop and Anthony celebrate Polytoic’s potential to democratize data movement for RevOps, enabling faster, more reliable data flows that drive revenue outcomes. The conversation reinforces that empathy and cross‑functional collaboration are essential to reducing silos and delivering measurable business impact.

• Final credit: The host thanks Gallop for sharing the founder’s journey, the practical demo, and the strategic lessons on aligning teams around shared revenue goals.

Full Transcript

Today we have Gallup Sulleon and we are so excited to dive into the Polytoic platform. It's the ETL and reverse ETL platform that is built specifically for RevOps professionals and data professionals. And he has built a platform that makes it so easy to get the data into the places that you need the data to go to. So Gallob, I'm so excited to dive into it today. And I think anytime we have the founder, the best part, I'd love to kick off with the founder story. You have such an interesting background where I feel like you have some deep empathy for the problem and would love to hear how you got kicked off. Sure. Yeah, pleasure to be here, Anthony. So, I'm Gallop, co-founder and CEO of Polytoic. Beginning with founder history, my history is 10 plus years working in data. I used to be the guy running data teams who would collaborate with RevOps teams to get them the data they needed. Now, back in the day, I'd get a lot of requests. Think of your typical SAS company. You've got data in silos. You've got Robops in charge of the CRM. Those guys need data. Like, for example, our users. Our users are locked up in systems controlled by in the engineering team. We as a sales team want to maximize upsells and minimize churn. We'd like to monitor usage. For the heavy users, we'd like to engage with them. for the light users. We'd like to engage with them as well for different reasons to prevent them from churning. So I was at a crossroads really at the company, but in particular with RevOps and the GTM side of the house on data they needed. It could be billing data often it was indeed product data of some kind, user data, which users are using what, who last logged in. A few fields in Salesforce or wherever your CRM is containing this data can go a long long way. You can then generate reports. every customer success manager can generate reports in the CRM could be atio could be HubSpot could be Salesforce whatever it is then they have a view your full customer 360 as they say regarding all the product data about that customer as well as whatever's in the CRM now I was the guy sort of play the role of a traffic cop often and this is rather unfortunate and unfortunate admittance I make now but often I would tell my robops counterparts Sorry, we're too busy for you. We're working on sexy data projects, whatever they may be, and your asks are sort of on the mundane and painful side. Thus, just wait. And they'd go, "What do you mean just wait? This is bottom line stuff for the business." And I'd go, "Well, we just don't have time. We're doing other things. You see, uh, we report to the engineering org where we're special." Well, many many years of this, I ended up at some point realizing, hang on, this is actually a real problem. Um, data remains siloed because the org chart results in teams that are separated with boundaries. Everything follows the org chart. You're never going to have a combined revops and engineering team in one. As long as they're distinct teams, you will have silos. And then you have the sales team who often make the decision on what CRM to buy, right? That's sort of another silo. They're hassling RevOps. Marketing is hassling RevOps. Revs is hassling us. We're now three degrees removed from the company's bottom line as far as impact goes. And so the realization was people are buying different solutions and begging internal teams just to move data around within the company. Well, at some point we thought let's just start a company, make a platform. It's just the one platform to move data between these systems. And I do often joke the surreptitious goal for starting a company is me paying penance for all the times I somewhat abandoned my robust counterpart who in hindsight was very correct. They were all very correct about the fact that this was bottomline business high impact stuff. But me of course the academic rather underweighted it. In a world where they could have served themselves I would never have been an obstacle. And so this has really been the goal here. Well, as a fellow founder, I don't think there's a better way to give yourself some lashings and pay penance than to start a company and then go solve the problem. Um, because I know there's there's plenty of challenges I'm sure you've gone through um you know, birthing a company into existence. So, I I think um that's great and and I I love the perspective of that and and I actually really like that you were almost on uh the villain side of the story that like you know switch sides a little bit because we hear people feeling the pain but you recognize that you are causing pain in someone else's life and that's what motivated you to fix it. I love it. Yeah. Well, yeah. Exactly. Well, I'm really excited. I know you prepared a demo today to show how easy it is to get data moving because this is not typically an easy thing. Usually you need developer level talent, at least engineering level talent to make this happen. And I think the way you've designed Polytomic has really just empowered RevOps people to take control, take part in their own hands and and make it happen. So excited for you to show how you chose to do it. Sure. Let's get going. Let me share my screen here. Okay, so here is Polytomics demo instance. Now we have a blank slate here. However, if I do click on connections, we're connected to all kinds of systems. For this demo, my initial use case will focus on moving product data from our sample product back end into Salesforce, which is usually one of the most difficult use cases to make happen. For sure. For sure. Especially if you're building it in house. Salesforce has API limits. It has field quirks. Um, all sorts of things. We just take care of it with clicks. We are connected to a couple of product backend databases here. We'll be grabbing user data from. And then if I scroll down amongst our, you know, many sample connections here, we also have a connection to Salesforce. Now, let's get going with this. The first thing to set up, and it does sound fancy, but it really is not, um, is one or two data models. Now a data model is simply a list of fields from your sources that you authorize for syncing. For example, let's add model. We'll go to this product backend database. Let's call this model user details. Now I can click here and we see what sort of tables or collections of data are available in our product back end. In our case, I'm very interested in users. We'll click that. And then what we return is all the fields behind this collection. Just like every Salesforce object has fields, all the collections on your product back end have fields as well. In this case, we've got a few named fields for users, email, first name, and so on. For every field, we'll show you the robots person, the example value behind that field. So, you can see the shape of your data without even asking your engineering team. We'll just surface an example value for each. Your leftmost column is your actionable one. This is a true false column that decides what fields are surfaced in a data model. In other words, you're greenlighting fields. I am greenlighting these fields and allowing them I'm declaring them to be allowed to be synced to other systems. Right? So, it's an authorization process. In this case, I'll actually select all here in the users collection from our product. Hit save. And we have a data model here, meaning a mini catalog of fields we can now sync anywhere. CRM, finance systems, support systems like Zenesk, spreadsheets. It's a catalog available to be grabbed from. We'll now go to model syncs and actually finish the initial run of this demo. And we'll create a sync into pick our destination to be Salesforce. All target objects are available as options including custom ones. We'll show them all automatically. But since we're moving user data, let's go into contacts. really then it's on you to pick a sync mode. Now you've got a few options here. Update or create meaning. We will update any matching records with Salesforce within Salesforce. We'll also create records that don't match from the product. Update only mode is where we'll just update matching records but not create any new ones. Create mode. Well, it's creating only no updating any matching records. And one has to be careful, but we do allow you to delete stuff if you need some mass cleanup. Most commonly, people will pick option number one. They want records both created and constantly updated. The first thing to pick with any sync to CRM is what we call an identity mapping. So on the left hand side, it's this data model we've just surfaced before and its fields. On the right hand side, it's a Salesforce contact fields. Now this identity mapping is really any kind of unique field on both sides. Some kind of unique ID. You can use whatever you want. Often for users, you will have a custom user ID that's unique. For the sake of this demo, I'll use email, but just realize you can do whatever you want. Once I select identity mapping between the two, in this case, email from product will map to email on the Salesforce contact. Now, it's just a case of field mappings. I can grab first name from our users table in the products mapped to first name in Salesforce. If you look up here, our Salesforce requires last name on contacts. And so this is actually a Salesforce validation rule, but we are propagating to you the user. And you can see, oh, hang on. My Salesforce requires last name to not be empty on contacts. Fine. Let's map last name as well into last name and contacts. And I could go on, but I do think the audience gets the point. It's really a field mapping exercise from whatever your data sets are. And so we can dismiss this and move on. You can even set some point-and-click filters here. Now B2B companies often do this where for example they only want to sync users where say email let's say does not end with gmail.com. Right now, in this case, often, especially if you have some sort of PLG or self-s serve motion as they call it, right? You may have all sorts of random signups and you may care about only moving ones that are under the guise of corporate domains into your CRM, right? You may want to exclude gmail.com. We do offer a full list of filtering abilities for text, other ones for numbers, and other ones for dates as well. We'll show you the right sets automatically based on your field. Um otherwise overrides is a minor feature but the robots crowds sometimes is quite thankful for it when they do use it. This is where you can do some quick substitutions. If you remember how our Salesforce requires last name. Well suppose people have signed up to your product and have not provided the last name but your Salesforce requires it. What do you do? Are you out of luck? Not quite. You can use overrides to set text substitution rules. And so for example, I can say well if last name is empty, I'll replace that emptiness with the literal text m/ a. This means it's now not empty. I can get past Salesforce as blockage and then maybe I have some other process in Salesforce to update these guys later on or deal with them later on. So overise again can be quite handy just text substitution rules on the way to your destination. Otherwise, you really just hit continue and this is the last step. You set a schedule. Now, manual just means someone needs to click a button every time you want updates sent. Continuous, the guarantee here is will run every 5 minutes and no later than that. Otherwise, you have more structured options. Hourly, daily, weekly, and so on. I'll set this to run hourly, say at 30 minutes on the hour. You hit continue. That's really it. Verify a summary of your sync and their settings. And you can leave a note. Let's call this um user signups sync to Salesforce. Just a descriptive note for you and your team about what the sync is doing. And note one magic about piece of magic about Polytoic is we automatically detect what's changed in the source and only move that for those who are squeamish as you should be about API consumption when it comes to your CRM's daily API limit whether Salesforce or otherwise. Note, Polytomic is rather clever. Not only do we use the right APIs to minimize that, but we only ever move changes, new records or updated records. And so we're not doing the dumb thing of just syncing everything every time and consuming resources from your CRM's allocation. Otherwise, going back to this, you hit save. Well, here we have a sync created going into Salesforce. One can run a test sync, which would sync five random records for testing sakes. Or instead, I'll just enable this guy. And instead of waiting for the first scheduled run, I'll just click sync now just to force it to get going. Click sync now. We've got a sync currently starting up and running. As this goes, couple more tabs to cover. We've got a history tab. So, you get full auditabilities on everything that's currently running. And then anything that's completed gets recorded down here in the completed table where you'll get logs for what was inserted, updated, any errors and so on. And then under error handling, we can toss in any number of email addresses or Slack channels in the subscriber list and we'll automatically notify everything on this list if anything fails. But really at this point for this particular example, this was a setup from scratch. You walk away at this point and anything that changes on the lefthand side will move to the right hand side. Now going back to these data models, this really becomes your central catalog for you to specify what's available to sync from. For those who are more sophisticated, maybe you know custom SQL, you can actually generate these data models through custom SQL. Um we can go to this SQL source here and often for example in this day and age of um API token consumption a lot of billing models are maintained by engineering teams here you can hook into the database let's call this billing info for example and you can switch from table select mode to SQL query mode now some of our customers have the complete works of Shakespeare in SQL form we won't bother you with that but I'll have a very dumb sort of a very dumb query here just to illustrate the fact that you can write SQL. You can actually write anything you want, complex joints, aggregations as you see fit. You hit continue and it's the exact same flow. You get back fields, examine them, choose which ones you want to authorize for syncing. In this case, I'll select all again. Hit save and now you've got another catalog you can move data from. This is a heterogenous control plane if you will or can connect your hetrogenous systems. You know, I can go to whatever. I can make a data model of Netswuite or I believe I've got a Google sheet here for example. Provost people will use Google Sheets often. Let's go to the one tab on the sheet. And here I've got um city, country, and state for example as example fields. I can hit save. And now I've stitched together. Well, we've got a catalog containing data from three different places here that we can sync anywhere. So, one could go on, but this is the core concept. Anyone can now jump in here, grab whatever fields they want and sync them to whatever system. And this really concludes it. Um, for the Salesforce card in particular, I will mention one more thing. This can be quite neat. We have an embedded query runner tab. Now, this lets you run arbitrary SQL queries against any SQL databases we're connected to. Run a query, preview some data, maybe make a model by clicking here. for the Salesforce crowd. You can connect directly to Salesforce and run sock queries directly against Salesforce. This can be quite powerful both as data exploration and as an alternative to rollup helper and so on. You could make a complex sock model, create this model and then sync it back to any Salesforce fields. This ends up being quite powerful indeed, but it's really the same method. You hit create model. We then create a model here. Pick the fields you want to authorize for moving. Hit save and you're off to the races. This really covers it. Uh this is a full setup from scratch. You can see the sync here just completed. If we go to history here, you'll notice we have a log that we can click on and I can click on what was updated which was, you know, all hundred were updates. And even within the logs, I can click on any of these IDs and jump straight into the record in Salesforce or again if you're using AIO HubSpot and so on, you get links directly in there. So really as a robots person, you have complete control of this situation as well as its results. This basically concludes the demo here. Yeah, I really love how simple yet powerful and enabling it is and empowering for the RevOps professional. um often tasked with getting I think two of the main ones getting product data in and billing data into the CRM um whether it was Salesforce HubSpot wherever it is and I think the way you've designed it just really gives them the tools to be able to do that. Now it's clocking how long it took you. So it was five minutes. Five minutes to Oh, there you go. Yes. build the model, sync it, and so in five minutes you have product data into Salesforce. Um, which is normally, I'd say, a few weekong uh engineering project and red tape to go through to make happen. So I I think that's just absolutely incredible. from from your perspective um because you're dealing with these use cases all the time. What tend to be some of the heavyhitting use cases that everybody's having a tough time with where Polytoic just handles with Breton? Yeah. As far as the sales CRM goes, the two big ones are product data and let's call it billing data or sort of the buckets of finance data. Um, for product data, realize all data about who has signed up to your product, who's using it, and in what capacity is sitting in a database locked up by your engineering team. Could be your data team, could be your engineering team, but it's certainly not the GTM side of the house that controls that data. No. Now, I certainly care about this regarding our sales team. We and everyone else cares about minimizing churn and maximizing upsells. These are, you know, your two and of course acquiring new customers, right? But that's the very definition of sales. But then beyond that, we all also care about minimizing churn and maximizing upsell. The biggest indicator of churn. There are many data points about do they use your product, do they not? If you simply begin with the last login date into your platform, that ends up being extremely telling as to who is likelier to churn than not. I remember running this analysis back when I was running data teams and we try all these sophisticated signals, right? Products, they've done this in a product, they've done that in a product, realized, hang on, if we just look at last login dates, that correlates so very well with the likelihood of the lack of it to have turned. So even just beginning there right if you simply want that data point that's sitting in a database locked up by the engineering or data teams you can get sophisticated based on your product you know could be if you're for example some sort of AI platform um you are probably looking at who has instigated agent actions for example maybe you're running some agent or you're offering some sales agents that your customers can use if people haven't put the agents to work and they're not using the product then they're a churn risk right so the premise is you have this data in there you've got your users in there you now can organize who you reach out to and why you marry that with product usage data you can now segment your users as reports in your CRM assign them to each of your customer success managers and each person can pull up a list of their accounts see are they heavy product users or not so not only do they have the users present they can also see who's used the product who hasn't. They can then segment people into churn risks or upsum opportunities. Someone who's heavily using your product is clearly already bought in. You don't need to talk to them to find this out, which means you can immediately target them with a script to upsell them on more stuff knowing that they're heavily engaged. Someone who's barely using the product will not listen to an upsell pitch. They're barely eating the product. For them, maybe an education pitch um is warranted. Maybe there's some org dysfunction that's preventing them from using the product, but you can enter that conversation beginning with a different set of assumptions without having to be surprised. And so by far that tends to be most impactful. Billing is a big one. And again in this day and age of AI with token consumption measurements and so on. Mhm. A lot of billing infrastructure is somewhat split between your usual sort of finance systems and engineering also owning some of the data and mechanics behind who has consumed what. You own the price books. You know how much to build them. You just don't know what they've consumed. Right? And you can call that product data and certainly it's part of the product or guys pose but really your goal is to reconcile your finances and you need this who's using what so that we know who to bill and how much. Have they exceeded overages or not? This is just pretty common in this day and age of consumption. And again that's just sitting in some other system that can be synced in. And so you can imagine going from Netswuite or Quickbooks or whatever and then you bring in this other proprietary billing information held by your engineering team in your CRM and again you've got your single window where you can see everything. Yeah. And and those things to highlight the point you you were bringing earlier all of this is to maximize revenue. So all that data all of that data is helping your CS team execute plays that are going to help with retention or expansion. identify upsell opportunities for sales teams and then also make sure you're collecting the revenue appropriately because a lot of the models were so complex. We've worked with companies where they're not billing properly or or it's costing, you know, thousands and thousands of dollars of manual effort, manual work to reconcile everything. Yep. Um so you're definitely leaving revenue on the table or spending too much to go collect. Exactly. Our customers often ask us they go well you know what data should I move and why and so on and you know we'll always say well forget the data itself do you want to make revenue right and the revenue could be from straight collections could be from monitoring your overages and again that falls under collections or it could be avoiding churn right you are making revenue by avoiding a churn incident you're keeping someone subscribed and paying money and then upsells too it's really exactly what you said Anthony it's all under the guys at making revenue. Everyone needs to put food on the table. We'd like to put as much food on the table as possible and these are the dimensions through which you can feed the problem. Then it just becomes well where's the data sitting and polyomicle took care of that. Right. Right. Given your experience, I'm curious. I feel like this is a big problem and I do think the way you structure companies tends to be one of the most important components of how your company is going to operate because at the end of the day, people will listen to their boss. So if my boss tells me to do something, I know that's usually my definition of success. And what you're saying earlier is RevOps teams usually living under the go to market organization, data teams usually living under engineering. If you're an early stage company, you will have like RevOps working directly with the product or engineering team. And then if you're more mature, you may have a dedicated data team. But what advice, if any, do you have for breaking down the silos? What can RevOps do to help engage their engineering or data team? And if we have somebody on the engineering or data team listening, what can they do to help engage RevOps or maybe empathize with what they're trying to do? Yep. Certainly beginning with the RevOps side. Well, beginning with either side, I think it's worth remembering that no matter what label we assign, companies, teams, business units, it's all human beings at the end of the day. The reality is no matter what org chart you have, if the humans in question are not getting along, all bets are off. They could even be on the same team, which is why because it's all humans. So, of course, of course, right? There's no such thing as a company deciding anything. It's just the management is deciding something. And who are those managers? They're human beings. There are some particular moves though that do engender and foster these relationships. And so for example robots person going to the daisy team or engineering team with a request what breeds partnerships and agreeableness and I think empathy is a big one I think simply starting with what are your current priorities right I'm here to be educated you know there's a social aspect of sort of lowering yourself somewhat temporarily yes I'm the ignorant person you're teaching me something and the topic happens to be I'm ignorant about your priorities, but it really doesn't matter, right? Hey, you know, what are your priorities? What you working on? I'm curious. Sort of just a slight understanding of what their world is like. And that then I think opens up a discussion where you can go, well, we have this really important thing. And it feels to me like this is more important than X or Y that you've listed for these reasons. But you at least have an entry point rather than coming out and going, "Listen to me. This is important. Get it done." Because the reality is there are as flippant as I was earlier regarding oh I was the traffic cop saying no thanks there were some legitimate reasons sometimes where the VP of marketing wanted some complex attribution analysis that involved cobbling data from many places and understanding it and so on and as a team we were just very busy at some level the service teams engineering and data and they should see themselves as that for internal um requests sometimes things do need to be kicked up to the org charts you know what VPN sales and VP of marketing need to tussle a it and come back with priorities as to who should be listened to. But usually the engineering data people are just not aware of these mechanics at all and it's really on the person to come in get educated and then use that as an opportunity to provide some education of their own. Well, let me tell you about my world, right? Let me tell my world and your parties. I think the same thing can apply to the other side rather than, you know, some people do get a bit drunk with power. That sounds a bit crude, but it's maybe somewhat true, I think, where you just sort of your ego grows larger and larger every time someone comes to you with a request that's important. Rather than focusing on that, you start realizing, oh, I'm the important one. And you start sort of trusting your instincts, which frankly may be very incorrect. You do not work on these other teams. What may seem not important to you or trivial to you may be extremely impactful to the other side. And sometimes things are a bit perverse where something that can take you 5 minutes starts feeling trivial, right? You're a technical person. Uh this only takes 5 minutes. How impactful could this possibly be? You're only saying this because you're in a position of ignorance. You have no idea how starved to the other side is for help where these five minutes can really change a team's weak if you just simply spend the time. So I do think it's on the technical people to also have this empathy and just find out hey what's on your plate tell me more why is this important who's going to be affected and so on. Sometimes it works out quite well where the other side can't quite describe why this is important in which case you know maybe it's not. Um some some requests are vanity requests. Hey I need help with this dashboard. Great. Who is going to be looking at it and making what decisions? Oh I don't know. So and so just asked and you know walked away well let's talk to so and so is this really important to them or was this an academic curiosity so it is on the technical side too I think to understand the other sides and I suppose if there's a theme not to sound too you know woolly about it but empathy is is a big one just simply understanding a little bit about the other side both helps you make better decisions and has the great advantage of um engendering some level of um understanding and partnership I think that's really well said and I think uh approaching things with humility, empathy, um realizing, hey, we're all on the same team. Um at the end of the day, our company's trying to grow. We're trying to get more revenue and take care of our customers. So, I think, um you know, let's all do the most impactful things that can make it. Mhm. Yeah. Exactly. And you just be surprised. I think people in general, maybe if there's a general general piece of advice for everyone, is you would be surprised which opportunities you spot if you open up your minds like this. You may think you know what lane you should be walking down, but I've been personally pleasantly surprised um once I've discovered other lanes by complete accident just by talking to people. 100%. Gallb, I think this was really really phenomenal and I think you actually created the platform that enables people to serve themselves and also build empathy to break down those silos. Um, you mentioned, hey, this 5 minutes can help anyone. And I saw you were able to get product data into Salesforce in 5 minutes. So powerful. Um, I'm really excited for our customers to see this. I'm excited for our general audience to see it as well. Um, I just appreciate what you're doing. You're you're using your experience, um, where maybe you were the cause of pain and correcting it, paying penance as you put it. I love that and just thank you for what you're building. Thank you for what you've done. and really really excited to see what you do next at Polytomic. Absolutely. Thanks so kindly for hosting me as well. Thank you, Glade.