Jigsaw Stack is a startup that develops a suite of custom small models for tasks such as scraping, forecasting, VOCR, and translation. The platform is designed to support collaborative knowledge work, especially in research-heavy or strategy-driven environments. Jovan Kemlani is the founder of Jigsaw Stack, and he joins the podcast with Gregor Vand to talk about making use of small models for diverse applications. Gregor Vand is a CTO and founder, currently working at the intersection of communication, security, and AI, and is based in Singapore. His latest venture, Wintik.ai, reimagines what email can be in the AI era.
For more on Gregor, find him at van.hk or on LinkedIn. Hi, welcome to Software Engineering Daily. My guest today is Joven Kemlani. Welcome, Joven. Hey, hey, good to be here. So Joven, you are the founder of Jigsaw Stack, a ultimately Singapore company, but you're now in the US, which is a pretty well-trodden path, I think, for this part of the world. So before we get into Jigsaw Stack, which I can't wait to get into, it's a very interesting product and very timely. I'd love to just hear a bit more about your background. I know this is, as I say, not your first rodeo when it comes to having founded the company. So yeah, just tell us about your journey to Jigsaw Stack. Yeah, I think...
It didn't start very exciting. It's like every other engineer. So I'm an engineer like everyone else. I love building products. I love exploring new technologies. And that's kind of like where I started. So I started as a game developer, which many choose not to take that path because it's one of the hardest industries to kind of break into from a revenue standpoint or from a salary standpoint, like your initial career. But something I enjoyed. Did that for a bit. Loved building. Did love the industry. Went into the banking industry. Didn't love the corporate industry. Decided to leave that. And as I went to...
study my master's at imperial covid hit right at the right moment so i decided to drop out i didn't want to pay over 200 000 just to sit in my dorm room so i decided to drop out and eventually that's when i got inspired to start this company called say our way back i think it's like four years ago it was a hotel aggregation company in southeast asia that basically did short-term bookings for like the pool the gym and different things within the hotel because domestic markets were growing back then then that grew to a point we went into co-working spaces and eventually we sold it and i think that kind of kicked off my path of like okay startups is like where I want to be. I love building and I love building for people, right? It's like, how can I make money from the things that I build? And that's when I realized that I specifically love building tech for developers and tools and software. And that's when I went into this rabbit hole of what should I do next? And this was like during the GPT-3 when it came out. I was like, AI space is getting interesting and a lot of technology being built is for front end human in the loop applications, right? Chatbots or tools that people can use in the loop. And I was like, can we...
bring this technology to backend applications where there's no humans in the loop. It just works. It takes away processes that used to require a lot of manual intervention. The most common thing right now is like web scraping, right? Like everybody's trying to scrape their web. Can we structure it in a way where you don't need to write property code anymore or play write code anymore? And basically you just give a URL and you prompt fields that you want to extract and it does the work for you at a 98% accuracy, not just marked out like actual fields that you can pull out. So that's the pain point that we realized that can we automate these backend tasks? And we went down this rabbit hole of like fine tuning models and training and like how can we increase the accuracy to 97, 98 and get it up there. So that's kind of like the how Jigsaw Stack started.
narrowing our field there. Nice. So I think you've kind of hinted at it there, but Jigsaw Stack, what is a, in sort of, I don't know, one sentence, what is Jigsaw Stack? So Jigsaw Stack is a suite of small models to automate your backend task. That's the way I like to phrase it. Awesome. Okay. So let's kind of dive just into that. You kind of already touched on, there was a pain point around pure web scraping, but then I guess when did that morph into small models versus just going down, like, oh, we're just going to make a web scraping model.
Yeah, so the first challenge that we tried, or the way we tried to tackle this problem, like, can we use GPT-3 or GPT-4, one of the big, large LLMs, the best in the class at that point, to solve this problem? Most of the times, we get good solutions for very human in loop. things you can markdown generated from a website that you can use to pass into a chatbot to then, you know, talk with that markdown. But you don't get structured data that you can actually use. For example, if you want to do pricing comparisons between two products on Amazon, typically a developer would need to write some code to extract that specific price field that they need to. And OpenAI with any kind of scraper tool can't achieve that. That same accuracy a developer would be able to. So that's when we realized that you had to fine-tune. So when we started fine-tuning, we tried 400B models, like the Lama 3.1 at that time. And we started scaling down. We said, can we take the same and bring it to a 70B model? Because then we reduce our cost, increase your efficiency. And then we started going down even further. Can we bring that down to a 13B model?
13B didn't work really well. So now we're kind of on average at like the 70B scale. And that's where we see it's easy to deploy, it's cheap. And since we're so specialized in that one use case, we can get rid of a lot of the other generic use cases built into the model, right? And kind of read and train a lot of it specifically for that one thing. So that's where the small model kind of utility really came in. Nice. So let's sort of maybe go through a few, I guess, well, you have many small models, is my understanding. So could you kind of go through a few of those? You've touched on kind of web scraping, that which is still very much in the product today, I believe.
What are some of the other ones? Yeah. So when we launched the web scraping that blew up and it kind of opened this door of like, where should we go next? We didn't want to dive super deep into web scraping because we realized the technology that we built for web scraping, it was 50% of model, 50% of infrastructure, because we trained the model specifically to Puppeteer, for example, that controls Puppeteer and inject JavaScript code. So now the question is like, How can we broaden the scope to do other forms of data extraction? And that's when we exploit data extraction as one pillar. So OCR is an example of pulling out text from things. So traditional OCR, like optical character recognition, uses machine learning to kind of recognize the characters. A very traditional way of doing it and very inaccurate way of doing it. Now we combined it with today's tool, like vision LLM, that gives us a whole new realm of OCR with bounding boxes and these kind of tool sets. And then we went into things like speech-to-text. It's basically extracting text from an audio. That's where we took WhisperTree, optimized the shit out of it, and basically made it one of the fastest speech-to-text.
We're actually faster than Grok at this point. So that's the direction we're taking. So that data extraction is just one example. Eventually, we realized that generative data transformation was not a big pillar. A lot of the users were asking, like, hey, I script this chunk of data from, let's say, a Mexican passport. Like they were doing passport verifications with our OCR. And then now they need to translate some of the information. Translation became a huge pillar by itself, where people were moving away from Google Translates and the typical translation providers because the quality of the product elements that exist today. So can we take a model, train it specifically for translation, and then add languages as we go, right? And then become a specialized translation model.
So that's what we basically started to do for data transformation as well. And I saw you give a presentation a couple weeks ago and you were talking also about translating text in images. That's a kind of interesting challenge, right? It is. I think people have seen this in like consumer apps like Google, where you point the app at a match and it kind of like overlays a bunch of text in a different language. And they have this in Apple, Microsoft. And we were looking into this and we're like, I'm surprised there's no API for that. Literally all these cloud providers don't provide an API for that specific service. I think one reason it could be because it's not high quality. They're actually just overlaying like a blurred text on top of the current text. So what we're exploring is that we saw that...
image ads and image generated content is becoming a big thing in the market, right? Is there a way that we can take an existing image, understand the text on that image, then translate it and diffuse it back with the same style, right? So basically, don't affect the style and the way, the shape of the text is. And that's something to explore. So with diffusion, you can really do a lot of that. So you can train a model on glyphs or text glyphs to then basically translate things. So I think we're like two weeks away from like version one. And then version two is going to be the full diffusion model that we're going to launch. So right now, we're going for like English and Chinese as the two major languages to kind of like diffuse against. And then we're going to include Hindi and Arabic and like different languages here.
Awesome. I'd like to touch on another sort of, I guess, part of the product offering, and you can correct me whether this is sort of an amalgamation of bits of the product or totally standalone, but the prompt engine, that's something that we've talked a bit about before previously outside the podcast. And I had a sort of specific use case, which I can always talk about, but could you just describe what is prompt engine and like, what is that solving? So prompt engine is also three big problems. First is prompt management, which there's a lot of providers in the market that do that for you. The second is prompt model routing.
another suite of products in the market that does that for you. And the last is prompt techniques, right? Techniques that you can apply to obviously increase the quality of the output, reduce your token costs and all these other things. So we decided, and we see in the market, there's so many challenges for like developers using three different products just to solve this. Like they use Langchain Plus. They use another product to track their tokens and another product to track, evaluate their model outputs and stuff. So what we managed to do is like, can we train a really small model, like 1B, 13B size to basically make these decisions for you at runtime? So we took different data sets in different industries, law, history, English, mathematics, and we trained a really small model.
that can make decisions on which model to pick at runtime based on your input of your prompt. So whenever you give an input, say, generate a podium, it will understand, okay, it's a writing-focused product, it needs to generate podiums. Then we have a data set that has been trained, okay, podiums are really good with GPT 4.5, like they're really good at writing. It'll automatically pick that model for you, but it will also run the same prompt against like five other models. And when you get the output, every single time you run that same prompt, it narrows down the best model based on this concept called mixture of agents. Have you heard of that idea where it basically runs it and then uses LLMs as a judge to basically say, hey, three out of five, this thing gives the same output. Typically, this is going to be the correct output. And then we merge all these three into one output.
it gives that so the chain of techniques that kind of basically gives you this thing so from a user perspective you don't pick claw 3.7 or gpd 4.5 or gemini 2 you basically get everything and the selector just the model picks that for you and you can also store the prompts and rerun it and stuff yeah i mean the example i spoke with you about previously was it was around time zones and i think we all know in programming time and time zones is hilariously difficult thing to still achieve various scenarios on so that was kind of what i at least ran through prompt engine initially to kind of get an understanding of what is this product and like how can it actually help us and it was super interesting because it was far and away better from a results perspective if i put into just pure gpt or i'm talking about gpt over the api or just go to cloud and just put it in there or go to prompt engine and say like hey we've got three people in three different time zones here's a few rules though like don't start a meeting before 6am for any of these participants strangely the other two really struggle with this like you have to keep correcting them like when they come up with at least three like oh here's the three times yeah one's at 5am it's like i explicitly said not before 6am oh yes you're right and then whereas prompt engine came back pretty reliably
covering that. So I think that's a very, I mean, can you sort of help explain why then it's able to produce that result? So when you sent your request, what happened behind the scenes is basically it sent a request across five models, right? And typically what would happen is that maybe two or three out of that five models gave the right answer. And what happened to be the smaller model that we trained, X as that judge, right? So models, small models are really good at consuming data, but are horrible at generating. So they can make a decision if you give it a lot of information and be like, yeah, this is the right one.
based on its context, but it's really bad at saying, hey, I can give you the right answer. So if you tell it, okay, these are five of the answers and pick the best answer, it automatically uses a weighted average. This two has these answers coming up more often. Plus, from my understanding, this is the prompt, the initial prompt, this is the answer. And it will automatically start merging those top two answers together. So what happens is that you now, you always guarantee the best answer and you're not going to get the worst answer because...
two out of three or three out of five of their models are basically giving you that same answer or similar answers. And it merges the output. So even if one of the models is, let's say, the NAM and the other model SPM, when you combine it, it overrides based on the initial prompt. So make sure agent is just one technique that we apply on it. Recently, you know, using the O1 concept of chain of thought is another thing, another idea.
implementing an entire model like r1 or o1 mini or o3 mini into front engine it's going to take tons of token costs and like a really long time process but we applied the same technique of chain of thought into our models from scratch way before like the whole deep see r1 came out but obviously the smaller scale so it runs a lot faster and cheaper for the user so that's why it tends to work more accurately especially even for structured data so if you ask it for a structured response you almost guarantee I think one thing I'm curious though, like if a lot of users who are relying on LNs, they're not actually tuning models themselves. That's kind of usually a sort of secondary exercise once you have an approved product market fit or so forth. And clearly the next step is to then tune a model and become more deterministic for their use case. So at least where I say, I kind of get used to understanding the likelihood of what's going to come back from a specific model. For example, if I look at our use case we have, it doesn't really matter the details of it, but if I put that use case to a Lama model versus to GPT, again, very different responses back. And I'm like, okay, we're always going to go with GPT for this one because I'm just confident that what's coming back. In the prompt engine example,
how does that work in the sense like the result might be quote better but i guess would the model behind the scenes have like flipped i'm just trying to get my head around like how much can the same prompt going to prompt engine end up then changing from sort of i don't say quality perspective because quality clearly is what the product's about but change from sort of structure or like, oh, that's completely different to what I was showing. Yeah. A hundred percent. That's interesting question. So the way we do that, that's why we always suggest the user to create, we have two parts to this system. You create a prompt first and then you execute that prompt. That's where the prompt management layer comes in. The reason we suggest to the user to always create a prompt and run it, like the typical LLM, you just execute the prompt, right? Like you just generate the prompt. But in our approach, you create, because you're storing this thing, there's a level of memory that takes place. Meaning every time that you run your prompt, we store a generated version of that prompt, like how it outputs it.
every single time. So let's say if you run this prompt six, seven, eight, 10 times, it basically will always store the version of the output previous to the next run in a database. And then we use that as a baseline as well. So if you keep changing your prompt and you keep tuning your prompt, we know clearly something is wrong. But if you kind of run the same execution of the same prompt, then we know, hey, we say, hey, this is positive, this is positive, this is how the structure should kind of look like. This is the output that it should kind of look like. So we give it some form of point system at the back where we're saying, this is good, this is bad, this is good, this is bad. And the more you run, the more accurate it gets, actually. And the less models that we run against. So initially it runs against five.
by the time your fifth run is running against two models, by your tenth run, you're running just one model. And we stick to that model. So you don't change your model by your tenth run. So if you're using, let's say, it automatically picks GPT-40, and GPT-40 keeps being the best model for your answer, it will just stick to GPT-40 throughout the lifetime of that prompt that you created, so that you don't have changes and breaking changes as you scale. Unless the model fails, right? So that's why we fall back. So unless the model is down, and then we fall back to another one.
nice something you touched on earlier and i know sort of quite a big piece of the product when it comes to i guess advertising this to developers is the speed can you talk a bit about how does that work let's just talk about small models versus large models maybe specifically first and then then we want to like jigsaw stacks infrastructure and how generally how is that making things so much faster so we started with the idea of gpu poor i mean we don't have a lot of gps right i don't even have h100 physically a lot of ai companies you see today the first thing is like let's buy more gps for training so we came up with the idea of like hey we're gonna be gpu poor as much as possible, we need to work on A100s, A10Gs, any of the smaller GPUs. I mean, at that time, it was not small, but now it's going to be small. We have to kind of be restricted to that scale. That was one of the ideas, or like a methodology that we stick with. The second is deployability. The biggest issue with, I think, LLMs or big providers like OpenAI right now is that...
distribution has been a big blocker for them. They are distributed with Azure or people have to use OpenAI directly. And so you see a bunch of these enterprise AI companies coming out trying to train open source models because you can't self-host OpenAI as models anywhere and being the best in class. And that was one of the biggest blockers currently. So we looked at this problem like we don't want to be in that realm, right? We cannot afford to basically be, we have that as a blocker where enterprises.
to use our OCR model and we're like, oh, we can't self-host because we rely on 30 different proprietary APIs that require like this much work. And that's when the small model idea came in because most enterprises don't have the resources to run large language models at 400B scale. So if we can focus on training the model to be deployable and cheap to run anywhere, it became an easier distribution thing for us from the get-go. It's hard to build for sure, but in the long run, the cost kind of pays off because we own this proprietary model that we can eventually then... go out to the market and be like, we can distribute on your systems easily, no restrictions. You want AWS, you want Azure, you want GCP, you want your own on-house GPU. Eventually, when we get big enough, we can even host on Grok to be even faster. And that's like the kind of opportunity that we have with smaller models. Cost efficiency is a big part of it. Yeah. So just so I kind of read that back, Brok is behind the scenes from an infrastructure perspective or multiple or? For prompt engine, we use a bunch of Grok under the hood as well. Lama Guard is a feature that they have that's pretty interesting that does a lot of prompt guarding and we didn't want to add Lama Guard.
into our platform without grog because it's one of the fastest and we didn't want that bottleneck eventually so we do speak to grog and the goal is like you know if we can get big enough volumes we can also host the cost of hosting on grog is huge you need millions and millions of users to kind of like be using you to even host one small model on grog so we want to obviously reach that scale where we can start hosting our models on infrastructure dedicated for small models okay so let's i guess then talk about just general devx here obviously we've got a very technical listener base and this is precisely who should be using jigsaw stack so what's the kind of likely first kind of what does the product look like to a developer on day zero when they're getting up and running Yeah. Right now, it looks like an NPM installer. So you just honestly NPM install, check on stack, get your API key. That's it. Everything else works. You build the libraries in a way where you don't need the documentation. So as long as you install the library, you should have enough typings that kind of like guide you in what you need to do. So from day zero, every field needs to be a named field. Everything needs to be descriptive. Everything needs to be typed. Even our Python library is fully typed. So that we, as a developer, my best experience is using Stripe or a library like Superbase, where you literally like Stripe. You get your options, customer.subscribe.
We want to be that intuitive, right? You don't need a documentation in most scenarios, but obviously if you need advanced configs, you go there, but you should be able to get started with just library. And that's the kind of the developer experience thought that we had. Like, can the library just be self-sufficient enough that the NPR install, they'll figure it out. The PIP install, they'll figure it out. And that's kind of the design structure that we went with, yeah. I like that you mentioned both Stripe and Superbase. I think they're both great reference points, Stripe especially on the API side and Superbase just for pure, I think, DevX when it comes to, yeah, what that product is. My understanding is the API itself, it's a pretty consistent...
structure across all the services. Is that the way to think about it? Exactly. So we kind of have a system in place where we kind of structure every API to be pretty consistent in the way you call it, in the way you structure your body, JSON, to kind of pass that data over. All the keys, we use the same key across all the APIs, so you don't get confused. Everything is a CRL file store key. So there's no confusion in that sense, yeah. Nice. And I mean, I guess we kind of have to talk about pricing and how you do charge for this. And I think most of these products, we're talking just in AI and Gen AI, especially, you know, it's a usage-based model. Could you just talk a bit about, like, how have you...
determined at the moment anyway like the best balance for like accessibility for developers versus then sustainable business economics that kind of thing like how have you looked at it so far and like how do you see that evolving yeah i think it's good to announce as well so we're changing our pricing right okay so we're recording on 12th of march today so just yeah exactly so we'll be changing it in like a week or two ish the reason is that pricing i think is an ongoing change we have been learning a lot since the time we launched we've removed so many products as well and we've added a lot of new products the reason we've done that is because we kind of like speak to customers with developers and we understand truly what they want when we started the product we're like We built on things what we wanted, and now it's based on what developers wanted the whole time. So we've reached a point where we realized that the pricing that we have doesn't make sense for a lot of the products that we're offering. Big issue is that, for example, we charge right now 0.05 cents per API call. It made sense for things like the AI Scraper, the OCR, because you have a fixed cost that you can scale with, and then obviously you get discount pricing the more you use. And it worked in competition to providers like AWS and GCP. It's a very similar pricing model. You have a fixed price to an API cost.
What happened is that we started releasing products like speech-to-text and text-to-speech. And what happened is that if you're charging 0.05 cents for one hour of transcribing of audio, you're still getting charged the same for five seconds. It didn't make sense to a lot of users at scale, right? And managing discounts manually for each customer didn't make sense. A lot of the users came back to us like, hey, why not just use token-based pricing? I'm like, yeah, why didn't we not just use token-based pricing? Like every LLM provider is using it. Every developer is used to token-based pricing. And if we can just shift to that kind of idea, it gives one the flexibility to us to now charge for more usage in a more minute way. Meaning if you use less, we charge you less, you use more, you base on the output, we'll charge you more accordingly.
Secondly, it lets us explore more technologies because now we can allow you to configure specific APIs to run for a longer period because we're not capped by that 0.05 cost, underlying cost behind it. So now we're shifting to this token-based pricing where we're estimating it to be around $1.40 per million tokens, which is actually pretty good because we're trying to keep ourselves as cheap as possible to most users for scale, right? So 140, I think Claude is at 15 bucks. So 140 for like infra plus, like a specialized model is something that we think it's fair. Now, obviously we're still going to test more. We've been getting a lot of feedback. We haven't got a lot of experiments yet because we've not launched it, but when we launch it, we'll get more feedback to figure it out and we'll still keep adjusting.
pricing to what developers are comfortable with. And I guess both, well, I mean, today, but I guess with this feature pricing model, there'll still be intro free tier of some description or, yeah, yeah. So it'll be like a million free tokens every month. This is sort of not pricing exactly, but it is related. Like I guess context window, I'm trying to get my head around, how does context size play with small models? Because I guess if I think about without you saying anything further, I think, well, context window, small model, surely it's just a really small context window, but what is it? Yeah, it is a small context window, but we don't really rely on the context window as much. It's not all language models. A lot of them are
train models to control infrastructure so like the ai scraper example basically takes in fields right like i need the price i need the description of this place i need the image on the left side of the whatever it's a very small information context input huge output on the output level that's where you see basically the model generates js puppeteer code and gets injected into puppeteer and then the puppeteer outputs a huge context but it doesn't need to go back to the model right and that goes to the user and then the context is so context is not a big problem for us because we are more of an infrasite problem if you're obviously building a chatbot or like some of a chat system or it requires a huge amount of context to be and then yes i think context makes a bit different typically for most chat applications or like human in the loop applications but not so much on like where we actually never had like a really context problem at this point yeah yeah okay that's super interesting so i want to talk about the future of the product as well as currently with the developer community that you have so let's let's start actually with current which is a developer community who's using it i'm aware you guys did like a hackathon maybe a couple weeks ago which looked very interesting so maybe what was kind of some of the results of that and like what is the current kind of community that are using jigsaw stack and how do they talk to each other i think there's two big communities one is the typical startup indie hacker is kind of you know there's people who love the product let's play with it try it out but they are i think for a dev tool like any like super base for sale or any product on the market it's always we face this kind of problem where it's
when you need the product versus when you discover the product right so a lot of times you discover the product but then you don't need it at that point and then you when you need it you forget about the product so kind of having us exist constantly in front of the developer to the point where they need it, and then get reminded of us as a key thing for us. So that's why we target a lot of startups. While they might not need us today, they enjoy the product. They eventually, when they build their startup scales or they build a product that doesn't need Jigsaw Stack, we're the first one to give a try, give a shot, or compare us against GCP and AWS, the competitors that we're going against, and then basically be like, hey, yeah, this is a better product. Let me try it out. Let me go for it. So startups is our key thing. So Series A companies are smallest at this point. We do do one or two enterprises, but enterprises is something that are a bit more challenging for us at a scale. We're happy to do it because we are still a small team. It's like...
three to five of us at this point and as we scale we'll take on more and more larger companies that are series a and bigger but they have special needs that like you know they needed to be deployed only in australia or only in specific parts of the us and stuff like that which we wanted to kind of do but right now it's mostly startups and it's and we get better feedback to be honest right like at this point it's so high like the hackathon because of the hackathon On that day, I wasn't even building. I was building Jaxos. Everybody came to me and they were like, wait, I have this bug over here. Or I didn't even know this field existed over here. Like, for the AI's great point, I'm like, okay, updating the documentation and like fixing this field. So the feedback loop is really good, like in real time, right? When you do stuff like that from the startup community. And that's what I love for, yeah. The startup community both have, I think, quite a very high bar versus some people. And then like quite a low bar at other places. Like, you know, when you look at the product, very high bar for like, this should just work. You know, I should be able to just get running in like 10 seconds. And then a fairly low bar when it comes to like...
oh, maybe this piece of documentation isn't great, but that's okay. Yeah, is that kind of how it feels? Oh, for sure. Depends on where you talk about it. Then when Reddit, the bar is very high. Reddit is anonymous. They're like, this product is shit. And I'm like, oh my God. You speak to the same guy in real life. He's like, oh yeah, I know. I love your products. Sometimes you don't know, but yeah, I think you're right basically, right? Developers are very intuitive. I think the more senior of a developer you speak to or a more developer that's comfortable with your skill, they're very intuitive. So if the product works or they can figure out...
they love to fix things, right? So if they can fix the product for you, they would, right? And like, especially if they can, but if that's why the documents are broken or something as well, it's not big of a problem for most engineers, right? And that's what they used to. And like, so they will go and they'll take screenshots and be like, can you fix this? Can you update this? And even the biggest of companies like...
which Google, Vertex AI doesn't work half the time. So the expectation from a startup is... I have experience of that, just thinking like, no, surely it's not actually Google, just the API doesn't work right now. No, it doesn't. It's like, if Google can do that, like, you know, the expectation from electric source to a startup is like, surprisingly, from companies, it's a lot higher. Like in the US, when a lot of the startups that we meet there, the expectation from a startup is like, we expect you to be way better than GCP, right? Like, I think in Southeast Asia, it's a bit different where they're like, yeah, I can expect you to be worse than GCP because like, you know, you're a small guy, which is good. I kind of like, I like the expectation in the US where the expectation is like, hey, I expect you to be better than GCP and that's why I'm going with you in the first place.
right? Like I'm not going with UCB. So that kind of, you know, downtime and these things are very important to us. And the clarity of like the feedback that we get from a lot of these companies and engineers are very upfront and very clear. And like, you know, they only complain about the things that have real problems, right? Like if it's actually down, they will complain about it. If the docs are wrong, it's not a big issue, right? Or they will just come and screenshot, like, can you fix that? And they sort it all wrong already. So it's a forgiving community when it's the right thing that goes down.
And I guess now just looking at a future and obviously like roadmap and also super early days for you guys. So roadmap is always one of these very difficult things sometimes I think to kind of pin down. But I mean, for example, I saw a post I think you guys put out very recently about sort of how you compare it to say Mistral when it comes to OCR. Because like Mistral has this big splash with how their OCR is like in theory well in a way better than anyone else. And you sort of made some good comparisons of why in many cases I think you argue that you're actually better. So is the future direction sort of let's take these cases that the big guys are doing and try and perfect them? Or are there just like completely other use cases you're adding, thinking of adding?
So we want to focus on two big pillars. The first is data extraction. The second is data transformation. So we're going to stick in this realm. So as long as it falls within this realm, we're competing with any big guy that comes in this split market, right? Mistral was never in this market. They were always in the LLA market. And then one day they dropped an OCR model. We were like, oh, okay, cool. We want to get into the small model kind of like space as well. And that's when it got exciting. So I'm like, let's try it out. And after trying it out, it wasn't as good as it claimed to be based on the title of the article. Well, they literally use the word world's best. I don't like shitting on certain things, but like I love Mistral. I love the first few models that they launched. It was like...
they kind of initiated a lot of the open source scenes like way before the llama and you know and the guys did so i love that for what they did in the open source world but when they did this michael ocr and i was like world's best like it really is just like i re-benchmarked it and it was like very clear far apart like from the world's best and so i just had to put it out there and kind of show like okay like there's a lot of room for growth and i'm happy that they're doing it and it kind of ups the ocr market so let's actually be the world's best and then claim that title right so so we did the benchmark we're like hey yeah you know it took us a lot of time to get our OCR model out. And we were surprised that there's a world's best, especially when Google can, with Gemini, level of resources couldn't be the world's best. I'm surprised they misruled it. So we were kind of like benchmarking and we were like, oh yeah, a lot of room, a lot of room for improvements. I mean, in terms of like future of just the company team, very recent announcement, a couple of days before us recording this, funding has increased, which is awesome. And like how, what is that going to enable?
you to do? And like, how do you see the team going up or not going up? I mean, obviously we're in the golden age of small teams now. So, which I love because I've actually always been a small team person and I was very frustrated through the 2010 to 20 period when you had to keep defending why you had a small team. So how does it look for you guys for the next couple of years? So we raised one and a half million. The goal is to grow the team to like a five-man team, tweaking myself, keep it very lean. And then the goal is to get the product to a solid standpoint. We're in beta still. We want to get ourselves out of beta. We're launching two significant products. The first one is the embedding model. It's a multi-model embedding model. We realized that embedding...
is only type space, which is like, but everybody embeds PDFs, images, and a bunch of different documents. We need an embedding model that can support all these document types natively. So we're launching that, and the image-to-image translation that we spoke about. One new idea that we had in the data extraction space is, I think Microsoft released a segmentation model, where you can segment buttons and different fields in a site. Can we combine that with object detection and other forms of detection into a single model? So segmentation, object detection, and a few things into one. And that's something that we're exploring. So we're going super deep into some of the detection space and the embedding space. So the next, I think, one year is diving way deeper into the technologies that we've built.
improving the quality of each thing rather than scaling into more products. We're kind of like, this is where we are stopping the product roadmap, but now we're just going to go deeper. How can we improve developer experience? How can we make it even more seamless? Can we improve our AI scraper to make it even cheaper and make it faster by updating the engine under the hood? There's so many new property alternative engines that are coming out that's faster to run. Can we scale that and make that faster? So I think the next one is really about the quality of the product, the developer experience and how deep we can go and distribution rather than scaling the kind of like the product roadmap. So the product I shared with you right now, like basically going to be like the last three additions and after that, we're just going deep.
that's a great strategy i think i mean you know for anyone listening and kind of getting going with the product that's nice to know in the sense that what you're using is just going to improve and sort of you've already been through that phase of like shaking out like what bits actually make up the product and what kind of gets people excited and also useful are you going to be hiring we've got a great technical listener base because it's great if you say yes or no because then you don't get flooded with emails or you do just yeah go to jigsawstack.com like slash careers we're always hiring at this point and the significant role we're hiring for right now is a founding full stack ai engineer we only hire a star players We have three questions. One of the questions is like, do you have a side project? That's my benchmark. Like if you, as an engineer, if you don't have a side project you're working on for yourself or for fun, then don't need to apply. Just don't apply. I think that's great. Probably a caveat there is if you're already working on a startup, but then realize this is a better opportunity, like that effectively is your side project, right? Yeah. But yeah, if you're perhaps in a sort of regular role, but itching to kind of get into something more interesting, side project is always kind of looked upon very favorably by people like yourselves. Just a kind of, I guess, closing question generally was, I think you founded this like effectively solo, is that correct? Yeah, I'm a solo founder. It's not that I wanted to be a solo founder. I think being the technicals, because in my previous company.
both my co-founders were non-technical. When I typically go for a non-technical product that I'm building, it's easy to find a lot of co-founders in that space that specialize in a specific space. I think the same way non-technical founders find it challenging to find a technical founder, it's difficult for a technical founder to find another technical founder. It's even more difficult because the issue is that you have a belief system of like how things are built, right? And then you're always kind of like in this realm of like what the way you see things and finding another technical founder is even more challenging. I've tried, couldn't find a perfect fit. And that's why I'm like, let's just find a specific role. And then, you know, eventually those people become.
co-founders, right? And that's why I'm kind of hiring the founding team that you eventually scale, you get equity and your equity grows. And I can give away honestly more equity because I'm a solo founder. So that's a good benefit. I think it's great to call out. I mean, there's just, there's so much out there basically saying like almost don't even try unless you find your co-founder. And I think there's quite a few examples in the last couple of years where I've seen solo founders doing incredibly well. So I just kind of thought it was good to call out.
100%. I'm not really solo. I have a really great team and I don't feel alone in the company. And that's the thing. I think solo founders just have to build their team better. And that's the only challenge. So it's not a pain point. I think it's not a big pain point for me. Yeah, absolutely. And yeah, I mean, you sort of founded it effectively in Singapore, I believe, kind of moving, well, is it west or east? It's kind of equal distance pretty much. Well, let's just say we're going east of the States. Is that right? Yeah. Yeah. So moving to San Francisco, one big reason is because when we launched in Singapore, naturally I'm here, so it's easy to launch here. We put it on Hacker News, we went on Reddit, we put it and we quit. Just majority of our customers and users are from the US at this point.
at least at the initial stage, we want to focus on selling the US customers in that region. Our second biggest market is actually the UK. And so we just think being in that region makes more sense for me to speak to customers, get a better feedback loop, just be in that same energy and like at the forefront of technology in that space, right? Southeast Asia is still a big market, obviously, but we require a lot more capital to tackle Southeast Asia. And that's something that we want to come back down the line. Yeah, for sure. Well, Evan, it's been so great to catch up and to hear all about Jigsaw Stack at this stage in the journey. I'm sure we'll catch up again in time when Jigsaw Stack is probably 10 times the size in only a couple of years or something like that. So yeah, just wishing you guys all the best and we'll be following along. 100%. Thanks for having me on.