So I'm Lee Edwards, the VP of Engineering at Teespring,

and I get to follow up probably the cutest tech talk I've ever seen in my entire life. If you didn't see the talk on father-daughter pair programming, you should definitely go to ConFreaks and check that out. So now that this is off to a really good start, I told everyone to leave. So yeah, my name's Lee, and I want to talk about how we do global manufacturing

at Teespring using Ruby and in the fashion of 2016 Ruby talks, we also use lots of software that isn't Ruby. So I'm super excited to be working with hardware again. I've been writing Ruby since about 2008, but before that, I worked in robotics for a company called iRobot, and I was actually a mechanical design engineer,

so I worked a lot with different manufacturing methods, sheet metal, milling, CNC, lathe, so 3-D printing. So manufacturing is something I've kind of always really liked, and I had no idea my career would kind of swing back this way. So you don't always think about technology when you think about T-shirts and garments,

but the truth is there's a whole lot of technology behind it, and the oldest one is screen printing, and we actually started seeing screen printing in China during the Song Dynasty in about the 10th century. And so the technology looks very, very different, but the principles are very similar. So essentially what you have is a screen that has a negative of an image on it.

You fill this with ink or paint, and then you're gonna squeeze or roll that ink or paint through it onto a substrate like a cloth or a garment. So you can see a lot of really cool Chinese art that was created during this time using screen printing. But we didn't really start to see it spread outside of China until the 17th, 18th century

when they were using the block chain through something the Dread Pirate Roberts created called the Silk Road. But that's actually the real Silk Road, which was a real road. And basically this was sort of the trade route from China to the rest of the world at the time. And the reason that silk and screen printing were tied up

is obviously you've heard kind of the phrase silk screen printing. So the silk was kind of required because it was a very strong material. You couldn't really do screen printing using cotton for the screen. So we start to see it go into the West around that time.

But then we see a lot of really cool advances in screen printing in the 1950s and 60s with Warhol and Lichtenstein. And the thing I think is really cool about this is what screen printing was essential to what Warhol was trying to do with his art. So his whole idea was he was trying to comment on, and I'm not an art history major, but he was essentially trying to comment on

kind of the way that art is perceived and valued and how there's only one Mona Lisa, and that's part of why it's valuable. In every painting you make, there's just one. And Warhol wanted to turn that on his head, and it's like, well, I'm gonna make 1,000 of these. I'll make 100,000 of these. And they're still beautiful. They're desirable. And they're all exactly the same. They're identical and repeatable. And that's exactly what you get with screen printing

is you can create large quantities of something that's identical. And so Warhol figured out how to make that art. And today, screen printing looks... A factory that makes screen printing looks a lot like this. So it's come a long way in 1,000 years. This is our facility in Hebron, Kentucky, which is called Mercury.

So it's about 15 minutes from here. And I guess at this point, I should tell you a little bit about what we do just so you can kind of get context for some of the stuff I'm talking about. So the way I usually describe Teespring is that we're essentially a marketplace that allows someone with an idea, a design, a brand, to create a product and turn it into reality.

So one thing that we do is we sort of take away the need for you to understand how to manufacture it. So we have this facility. We work with third-party printers, which I'll talk about a little bit. And these creators will create a business online, or they'll create a campaign where they're raising money for a charity. So for example, I'm wearing this shirt, which Beau Bergeron, a designer

out of Oakland, California, created to raise money for Louisiana flood relief. It raised, I think, over $50,000, maybe even quite a bit higher than that. So that's kind of what we do and how we do it. So screen printing is how we do those kind of larger campaigns where we're printing thousands and thousands. And the way this sort of works typically

is first you'll have to do artwork separation. So you have a design that's got, say, ten colors. That means you're gonna need ten screens. So the first thing you'll do is kind of separate it. So we have a room of designers that use Photoshop on IMAX, and they are actually pulling the layers apart on the image.

And one reason that you don't actually automate this is there is a good amount of artistry and craftsmanship involved. So there's a lot of things that they'll do during this process where they maybe remove some, like, some discrepancies, or maybe two colors are close to each other, so you can reduce the cost by combining the two colors. There's a bit of a judgment call as to, like, whether that's desirable or not.

So basically we'll do artwork separation, right? And after that, or possibly at the same time, we're sort of picking the blank inventory off of the rack. And if you work at a traditional, like, e-commerce-type company, this is generally the entirety of what the Fulfillment Center does, which is receive product, scan it,

enter it into some kind of inventory system or warehouse management system, stock it on a shelf, put a barcode on it so then you know it's there, and then every time you pull one off, right, you're scanning it. So that's... we do that, but it's just a part of what we do. And then also, this could happen simultaneously

or perhaps next, you actually create the screen. And so the way... There's lots of different ways to create screens, but all of the very, very high-volume manufacturing facilities for screen printing do it similar to this. So essentially... Whoops. Essentially you have kind of a lie-flat inkjet printer,

and you have a screen that has this substrate on it. It's...and you... The inkjet printer will print the positive of the image on top of the screen, and this can be done, like, very quickly, and again, you need one screen for each color. So the next step is you put this...

You put the whole screen through a sort of heating process that will burn through the emulsion and turn the positive image into now a negative. So this looks a lot like the screen you would expect to see that has a negative, so you can actually push paint through it. So the next step is...

You'll usually have, like, a large inventory of paint. A lot of times you'll need to mix paint based on, hey, a design came in, and we don't have that color. And then you sort of slab the paint onto the screen. And I think one thing that's kind of cool about this is, like, a very thick latex-based paint, and it's designed in a special way to be able to bond with the shirt

so that it can actually survive washes. And this is how a lot of retail-quality shirts that you see are created. So these things, I mean, the paint will, like, outlast the garment usually. So once you have all that... So here you see, like, a rack of blank T-shirts. This is a screen-printing press,

and you can see the operator here is insanely fast. You kind of can't really tell, but he's actually having to line up very precisely the shirt against those screens that are sort of above each station, and that's to, you know, make sure that the print is well-aligned. So a really talented screen-press operator

can do a shirt in about eight seconds. And... Let's see. So when you see the machine in action, you can see each screen presses down on the garment and then uses a squeegee to force the paint through the negative and onto the shirt. So then the last step is,

we have this curing step that kind of dries the shirt, and it cures the paint so that the paint bonds to the fabric. So I mentioned multiple manufacturing processes. The second one is very, very, very new compared to screen-printing. So digital printing,

the company that makes the digital printers we use has been around since about 2002. And if you've seen digitally printed shirts from that early in its life, they're not the kind of shirts, well, you probably don't have it anymore. They didn't last. Originally, digital printing was very low quality, very difficult to make off the right quality shirts with digital. But today, it's amazing.

And the way it works, if you're familiar at all with inkjet printers, it's very, very similar. So essentially, you have a pump that's connected to a piezoelectric crystal. So a lot of sort of small electronics will have piezo crystals. Any time you see something that...

a small device that has a little bit of motion or uses a pump, it's often using a piezoelectric crystal. So the idea there is the piezoelectric effect, and there's gonna be a material scientist in here who's gonna be, like, face-palming when I try to describe this. But the best that I can explain it or understand it is essentially the crystalline structure of the piezo crystal is kind of special

so that when you... if you were to squeeze it, apply mechanical pressure, you'll create an electric field as the crystalline structure or lattice kind of, like, shifts and reassembles. And the converse is true. If you apply a charge over it, you actually will cause motion on that crystal. So you can use it to drive pumps. It's used, like, in speakers.

And so the piezo crystal pumps a very small amount of ink, and then it drops through a charged electrode, which gives an electric charge to the ink, and then it passes between two high-voltage deflection plates that can ensure that the droplet is... is sort of deposited directly onto the substrate. So a lot of...

This is a very simplified version. I think a lot of the printers that we use and that you see in the industry are using more complicated multistage versions of this, but a lot of the key components are basically the same. So what does that actually look like? So this is one of our printers in action, and you can see here someone who is not a printing professional. My good friend Alex is not quite as fast

as setting up the T-shirt on the machine, but similar to screen printing, you do have to sort of align it with the seams and kind of make sure that everything's lined up and then sort of press that lid down. And so then the next thing you'll see when this runs is you'll see a little bit of wetness around that ink,

and so that's the affixant. And the first thing that the printer does is spray that on the material. And they call it sort of wet-on-wet. So you're spraying wet ink on top of this affixant, and we'll get to later when you dry it, what this is for. But there's two heads you'll see here. One is sort of like white-black.

The other is RGB or CMYK, depending on what you're doing. And this machine in particular is able to handle two shirts at once. So one thing that's really interesting about this is that there's a lot of configuration that goes into this. So we have configuration files that are for each individual garment that depend on their materials, their colors,

how we sort of manage that. And it's actually one of the, I think, more interesting pieces of technology or, I guess, IP that we have is around a lot of the hard experimentation and how do you make a really high-quality shirt using digital printing. So I'm about halfway through,

and you haven't seen any Ruby. So you might be wondering about that. And if you were hoping that I was gonna show you all the cool REST APIs that are on top of these digital printing machines and screen presses, you are gonna be very disappointed. These are all proprietary machines that do not expose nice, beautiful REST APIs. But I think what I wanted to talk about here, and I saw this a lot in robotics as well,

is that a lot of times, building a... working with a production system, you don't always get the kind of awesome and fun APIs that you'll get when you build, say, like, an Amazon IoT or, like, an Arduino or Raspberry Pi. A lot of times, you are dealing with

very closed-source commercial vendor software or you're working with, you know, machines that don't expose APIs. So what you're really doing as a software engineer at a company like this is you have to remember that the software is about people. It's a mantra that I think people

on the commercial side, retail side of software often repeat, but it's just as true on the operational manufacturing side. And software is also about processes, which, by the way, are also about people. So most of the software we write is really we're trying to watch what people do. We have 200 employees who are working, basically 24-7, someone is working that facility.

And we're looking at how do they work and what are their problems, how do we make them more efficient. We're looking at the operational processes and how do we model these. And so I think the reason that we use Ruby is, in particular, Rails, is, you know, a few years ago when we started the Rails app for Teespring

before my time, you know, not knowing where your domain is going while you're kind of evolving a startup. One really good example is started with screen printing and now we're moving to digital. And a lot of the domain that we'll talk about in a minute has shifted during that time. So dealing with a monolith is a little bit easier, right? I think dealing in a microservices world

has a lot of advantages, but one of the disadvantages is it can often be really difficult to iterate quickly. So we've really had a lot of benefit from sort of keeping all of our stuff in a, I guess to borrow a phrase, majestic monolith. Um, so, um, yeah, so the basic elements of Teespring,

um, there are, we've, our Rails app is kind of divided up into a few engines, and I'll talk about a few here. So where I say commerce, I'm really glossing over the fact that there is multiple Rails engines involved here. But by commerce, what I really mean is the buyer experience. So people who go to teespring.com and they're searching, they're browsing, they're looking at categories, they're getting recommendations, they're buying things.

And then the creator side, which is, um, you know, as a designer, I'm uploading my image, I'm managing my campaign, I'm, you know, saying how long I want the campaign to go for, I'm setting prices. Um, so kind of call that, like, the commerce side. And once I've designed, once I've created my design, uh, there is, there's a whole sort of domain around artwork. And some of that is in the Rails app.

Uh, we also have some artwork-related things that are written in Go. So we have an image mockup generator called Van Gogh because, uh, it's actually a law that if you make a repo in Gogh, you have to put Gogh in the title, so we called it Van Gogh. Um, so, uh, so a lot of that stuff's in Ruby, some of it's in Go, and, uh, it communicates with both commerce and fulfillment.

So the fulfillment engine, and again, there's actually kind of more than one engine related to fulfillment, but kind of handles the handoff from everything that happens from an order to when you get this package in your hands. And the reason we've sort of built this stuff as Rails engines is I think, you know, as I've said, the monolith works really well for us right now, but we're kind of looking towards the future of once we have more and more engineers,

once our sort of domain is a little more solidified, I think it's gonna make a lot of sense to potentially pull, um, some services out of the Rails app. And I think a really natural division is kind of like right down the middle of commerce and fulfillment and would allow us to sort of, um, define, like, a really formalized API and contract between the two parts of the application.

Um, so key piece of, uh, domain that's in the, uh, fulfillment engine is called the fulfillment job. So I'm gonna walk a little bit through the life cycle of the fulfillment job, uh, both in terms of how we handle it inside of Teespring and with third-party printers. So when you create an order, I kind of alluded to the campaign model earlier,

when you create an order on Teespring, um, you are not gonna get it fulfilled right away necessarily. So this idea of a campaign, it really came from, uh, if you look at Kickstarter, Indiegogo, like, there's a lot of benefits of having a campaign model. So if you say, hey, this campaign ends in seven days by now,

people want to jump on board. It also, uh, if you have sort of the social proof of, hey, 100 people have bought already, it makes people feel like they're part of something, particularly if they're, uh, raising money for a charity. Um, and if you say, hey, three more needed to tip the campaign, um, right, you get that sort of sense of urgency.

But I think a bigger reason around why we have the campaign is if you think back to what I said about the manufacturing methods. So when you screen print something, you're spending time and labor up front and money to basically print the screens. There's a big fixed cost up front.

And then every shirt you print, like I said, it can take as little as eight seconds. So the marginal cost is very, very cheap. And so if you think to, like, Econ 101, the way that you kind of amortize, uh, up-front fixed costs is you have a very high volume. So it's kind of analogous to injection molding. Um, in, uh, in sort of the mechanical design world.

And, uh, digital printing, on the other hand, uh, you can, it's sort of a fixed cost. No matter how many you print, it's the same amount of time to, like, put that shirt in there, bring the thing down, print it. Um, but what's nice about it is that you can actually print, say, three items, and it can still be profitable. So, um, so the campaign model really was built around the old idea of screen printing.

And hey, if I run this campaign for, say, seven days, I can collect a whole bunch of orders, and then it's a lot cheaper for me. And so it was cheaper for us, so we charged the creator a cheaper amount of money, a lower amount of money, and, um, and they were kind of incentivized to run these longer campaigns. Um, but, uh, yeah, so that's essentially

what, why the campaign exists and why it's a central part of Teespring. So, uh, CampaignEnder is a, uh, is a worker that runs on Sidekiq. And, uh, basically, if you read this code, it's, uh, it's kind of like one of those great methods that, you know, the only way you know how to refactor it is to basically take all the procedural code and extract it into methods

and give each one of them a name that's like a sentence long that describes what it does. Um, everyone's seen these methods, right? Um, so, uh, so what it's doing is it's checking that the campaign's valid and it's valid to end, and then it checks does it meet the minimum to print. So it used to be the minimum to print was really high when it was screen printing. Now it's down to three for everyone, and it's down as low as one for some people. Um, and then it checks is it profitable.

And when I say is it profitable, I don't mean is Teespring making a profit. I mean is the creator making a profit? So, uh, based on the cost curves, right, the manufacturing method, how many were sold, um, we can calculate are they actually gonna make money or have they charged less than they're actually gonna spend? And we actually, we don't want to put them in debt, so we only, you know, tip it if it's profitable.

Um, and then have all the orders been charged? And if so, it ends successfully. And so the campaign ender has a reference to this campaign object, which is, uh, pretty standard, like, active record object that has a state machine attached to it. Um, so then the next step is to essentially figure out what printer does this go to. And so there's a number of printers inside of Mercury, our facility in Kentucky,

and we also work with a bunch of third-party printers. And the third-party printers exist for a few reasons. There's, uh, geographical reasons, right? We can, we can actually ship things faster if we, uh, are printing them from different locations in the U.S., or even, uh, we have print partners in Europe. Um, and also we use them to work with, uh, as we add new merchandise. So obviously we do T-shirts, and, um, you may have seen the tote bags floating around

that we handed out yesterday. Um, we also do mugs and stuff like that. But as, as we test out new merchandise, I think it always makes sense to work with a third-party printer to test out, you know, does this work? Do our customers want it before we decide, hey, let's operationalize that and bring it in-house? But regardless, the way that, um, the next step is, is the job has to essentially

get assigned to a printer. Um, and, uh, there's two ways that can happen. So one is the auto-assigner. The auto-assigner runs periodically, and, uh, and will, will basically say, okay, are there any printers that have signed up for our auto-assignment program? Like, they, they're eligible, and they have capacity, and they have the capability. Then we'll just automatically assign the job.

But most of our assignment actually happens from, uh, a place inside of our Rails app called the printer-assigner. And so someone looks at that every morning, and they're looking at, here's our capacity in Mercury, and here's the capacity of our partners, and here's the type of job. Um, and, you know, oh, we're really slammed today, so we're gonna send it over here. So basically manually assigning the jobs.

Um, and so what happens when a job gets assigned is it actually creates the fulfillment job. And the fulfillment job is, again, an active record object that, that has, uh, a collection of, of line items, of fulfillment line items. And the analogy there is, if you're familiar with sort of really common e-commerce domain modeling, uh, it's kind of like an order in a line item. It's a fulfillment job in a fulfillment line item.

Uh, so each fulfillment line item could correspond to a particular product that you're, that you're actually printing and shipping. And the fulfillment job sort of exists, uh, throughout the entire life cycle of, uh, of, of sort of the fulfillment process. And the way that it's managed, uh, there is, well, there's two ways that it's managed. Inside of Mercury, and some of our print partners

use this, uh, product that we have called the Printer Portal. And so this gives you a view on, on all the fulfillment jobs that you've been given. You can actually accept or reject them. So if you reject a job, and you say, hey, you know, everyone is out on vacation today. We have to reject it. So, um, it'll go back to assignment. But basically, Printer Portal will, uh,

will, will take you every step of the way through the processes that I described earlier. Um, and the other way, and this is relatively new, is, uh, you can actually, you can actually integrate with our API and fulfill a job that way. And so there's sort of two halves to the API. There's, there's the pieces where, um,

uh, there's a request from Teespring to the fulfillment partner, and there's a request from the fulfillment partner to Teespring. And for all of our, for this, and we have other APIs, we have APIs for creators, and we have, uh, lots of internal APIs, and we have APIs for the mobile app that are all kind of subject for a different talk. But, um, but for all of our APIs, we're using, uh, grape,

and we're using swagger for the auto documentation. And we have a style guide gem that we put on top of this to make it, uh, look as pretty as possible. So, um, so yeah, the, the main pieces of domain, it's, it's a REST API, and it's, I think, pretty predictable, right? You have jobs. You can sort of get a list of the jobs assigned to you. You can get information about a specific job

by passing an ID. You can update a job by saying, you can say, like, hey, the status has changed from this to this. And the same with shipment. So shipment is, right, a physical thing that's, that's shipping out of the facility. Um, so, uh, inside of our facility, we have a system called Apollo. Uh, and, you know, other, other facilities

may have something similar to this, but this is the software that we run literally inside of Mercury. Um, so this is, this is actually built in Python, and it interfaces with our Rails app through some APIs. Um, so the idea behind Apollo, well, one of the ideas behind Apollo is that you essentially can't, um, improve what you don't measure.

So Apollo exists on every station throughout the facility, and, you know, you may be working one station one day, one station another, um, and whatever, whatever job you're doing, you're scanning your badge to get into Apollo, and you're logging what you're doing, right? So, um, I think one thing that, that I've always loved about manufacturing and, and software development,

uh, agile software development, there, there's some shared principles in Kanban if you've ever done sort of, like, uh, Kanban software development. Um, the, the principles exist in manufacturing, right, and it comes from Toyota, uh, lean manufacturing. So one of the ideas in that is Muda, which is Japanese for waste. Um, so I don't have any Ruby in this talk, but I do have Japanese.

Um, so, uh, um, so, uh, basically, if you're, if you're able to, to eliminate waste at every step of the process, um, that's, that's sort of one of the, the lean manufacturing principles, right? And another is if you imagine these sort of Kanban columns on a traditional Kanban board,

if you inspect sort of what's in each stage of the process, you can figure out where are the bottlenecks, where are the sources of error, what parts of the process can we actually remove? And you can't do any of that unless you're measuring it. Um, and so other facilities might have their way of doing it. This is how we do it. Um, and of course, it's, it's all driven by software, and it's very, very closely tied to

the specific operations that we're actually doing. So once, so, so Apollo manages the, the job all the way from beginning to end, and the very last step, well, I guess the second to last step, um, is, uh, is actually bagging it. So we have this thing called an autobagger, uh, and essentially, so you'll see here she's scanning this barcode. The barcode is on the garment through the whole process.

And if you were to ever order from Teespring, you actually get that barcode in the mail. We don't even take it off when we send it to you. Um, so the autobagger, uh, will bag the thing in our cool little branded thing, and then we've got a, uh, a label printer. So another part of our Rails application, we have, uh, so, so actually, either way that you handle fulfillment,

uh, you, you'll be printing labels. So in, uh, in our Rails application, you can log in and say, hey, for this fulfillment job, I need to print all the labels. And when you work with the API, what's kind of interesting is you, you actually request the label, like, we'll, we'll send it to you. Um, so obviously, the shipping label is what it takes to get from, uh, the factory to your door.

And then the last thing, the last piece of machinery or, or hardware that's in the facility that is possibly easy to overlook is, uh, the conveyor belt that just sort of takes the bag, um, from, uh, from the bagging station all the way to, to a truck. Um, and the fun anecdote I like about the, uh, conveyor belt

is, uh, every time I go to Mercury, the, the, the layout is changing, right? As we're learning new things, we're always moving things around. Every time I go, something's different. There's new tape on the floor that says, don't stand here. This is the whatever lane. And, like, there's all, like, computers in different places and screens all over the place. But the conveyor belt can't move because it's bolted to the concrete.

Um, so, uh, so it is, like, the one constant. Um, and, uh, the last, uh, the last thing is hopefully that all works perfectly, right? You get your shirt, and you're like, this is awesome. It looks perfect. It's exactly as described. I'm so happy. I got it on time. However, sometimes it doesn't happen.

So we actually do have customer service and returns. And, and a big part of the Rails app, and you can see, without even, like, needing to read exactly what they say, but along the left-hand side, these are all the different sort of functions in our admin, and there's, there's so many of them. So customer service will have to deal with, hey, what's the status of this order? Or, hey, I need to issue a refund, or I need to do a reprint.

Or someone's asking a question that will look up the answer for them. Um, so, so basically this Rails-based admin, uh, allows our customer service agents to manage all that. So, so again, I think that the takeaway that I'd love for you to, to take from this, you may not remember, you know, what century screen printing was invented in,

but, but I think in, uh, you know, especially where I live in San Francisco, there's so much commercial software, uh, consumer software, and people there are obsessed with the UX, and it's all, and the phrase software about people, my roommate actually has this shirt. Um, but on the, on the back end,

it's also about people, right? Because it's about processes, and processes are made up of people. And so to us, I think the technical challenges that, that we face are not, if I showed you a lot of this code, you'd be like, yeah, that's Rails code. I, you know, I've written Rails before. That's Rails code. Um, but what, what's interesting is actually trying to identify these problems and solve it, right?

And we have hundreds of people who are, who are doing this stuff day in and day out, and how do we make their lives better? How do we make their jobs faster, more efficient? How do we reduce error? How do we model new and innovative processes as we come up with them? And that's kind of what we're doing, and, and at the end of the day, you don't have sort of clean, beautiful REST APIs, but what you do have

is software and lines of code that you can run, and out the other end, you get a physical T-shirt, which is, which is pretty cool. I mean, everyone wears T-shirts, right? Um, so, uh, yeah, thank you. And, uh, love to answer questions.

Yeah, so this one here. Um, so you can kind of tell by, uh, the screen-printed shirts will often have, like, a little bit of elevation on the top of it, so this, this one's screen-printed. Um, the digital shirts, uh, don't, don't have quite that elevation. The ink is kind of, like, part of the, of the garment. So there is definitely a stylistic choice.

I mean, I talked a lot about the economics of the two methods, but there's also, you know, I think some people describe the screen-printed look as retro, um, and I think part of that comes from, like, Warhol in the 50s. Um, uh, but yeah, so they're, they definitely do look different. Yeah, yeah, so the way it's architected, we, yeah, we have, so the question was on, uh, the sort of pieces of domain that I showed in an earlier slide.

Uh, so those are, those are implemented as Rails engines, and yeah, the, the reason for that is essentially there, there is definitely some shared state between those Rails engines and shared active record models, and it's all hitting the same database, right? But, um, but the idea in making them engines was that in the future, we, we sort of have some of this stuff separated out already, the tests that belong in one engine

are already there, the controllers, um, some of the non-active record models, which we have a whole lot of, like, services and non-active record models, are all kind of separated out into their domains. Um, so it's not gonna be easy to move them out into services, but, uh, I think maybe easier. Um, but yeah, I think at the moment we, we do benefit a lot from the monolith,

but we're just kind of trying to be a little bit future looking. Yeah, so the question was about, like, sort of why the APIs don't exist for these kinds of printers. So I think that's interesting. I mean, there may be, there may actually be printers that do have the APIs. The reason that we use the printers that we do, I guess I'll give them free press, because they're, they're good guys, but, um, so Corny is the company we use, and they're, we pick it because it's top of the line and highest quality product. Um, it, it doesn't

at the moment have these kinds of APIs. Um, it's actually really interesting. So I've been to their, I've been to their factory, which is in Rosh Ha'im, Israel, and they actually, um, they actually, uh, I would, handmade is maybe too strong, but they definitely don't have, like, a large scale manufacturing process for these machines.

There's actually a very limited number of them. So even though they're, like, a publicly traded NASDAQ company, um, they're still, they're doing a lot, a lot more manual construction of, of these machines than you'd expect. So I think they're sort of, speaking for them, I guess, but I think they're, I think they're sort of not in the business of, uh, of allowing that level of automation. It could change in the future.

Ha. So, uh, the question was if I, if we had ever hacked, uh, the Corneit interface, and, um, uh, this is being recorded, so hi, Corneit guys. We've definitely never hacked your interface. Um, no, I mean that sincerely. Ha ha ha. Um, I mean, I think one,

the question is, is it a limitation? I mean, I think one thing that is really interesting is I think the people that are involved in these processes, I don't see them necessarily going away. As I said, there, there is a good amount of skill involved in, uh, in sort of screen printing and, and digital printing, so I don't think it can be fully automated at this point. I think there is a fair amount of craftsmanship in artistry that really does require people.

Um, so, uh, so yeah. So it's, I, to, to me, that's actually one of the really rewarding things about this job is this is an industry where a lot of that manual labor is overseas, and, and, and we sort of, we employ people here in the U.S. and sort of give them fair wages and healthcare and lots of really great benefits.

Um, so it's a point of personal pride for me. I, I don't think I would necessarily want to automate it away. Ha! Someone who works at Teespring asked, is Teespring hiring? Um, so, so the answer is yes, so I'd love to talk to you about it. Um, great. Uh, well, thanks, everyone.