If you've ever been to PyCon, you know one of the best parts of the expo hall is Startup Row,
a stretch of booths where early-stage companies built on Python show off what they're creating,
but only attendees get to walk that lane. So let's bring it to everyone. In this episode,
we stroll down Startup Lane together. We kick things off with the organizers, Jason and Shay,
who share the program's origin story going back to Paul Graham and the PSF, plus some surprising
stats, including two unicorns among the alumni. Then we meet five startups, Tetrix, bringing AI
to institutional investing in private markets, ArcGET, security that lives inside your app as an
SDK, Femoral.dev, serverless hosting built for Python web apps, Capitio, an identity and authority
layer for AI agents, and Pixel Table, a multimodal database from Marcel Kroniker, co-creator of Apache
Parquet. See if you can spot the theme running through them all. Let's go for a walk. This is
Episode 551, recorded June 11th, 2026.
Welcome to Talk Python To Me, the number one Python podcast for developers and data scientists.
This is your host, Michael Kennedy.
I'm a PSF fellow who's been coding for over 25 years.
Let's connect on social media.
You'll find me and Talk Python on Mastodon, BlueSky, and X.
The social links are all in your show notes.
You can find over 10 years of past episodes at talkpython.fm.
And if you want to be part of the show, you can join our recording live streams.
That's right.
We live stream the raw uncut version of each episode on YouTube.
Just visit talkpython.fm/youtube to see the schedule of upcoming events.
Be sure to subscribe there and press the bell so you'll get notified anytime we're recording.
What if your AI agents worked like FastAPI microservices,
typed, autonomous, and discovering each other at runtime?
That's the world Agent Field is building.
Join them at talkpython.fm/agentfield.
To kick off this episode, we have the organizers of Startup Bro at PyCon, Jason and Shay.
Welcome to Talk Python To Me.
Great to meet you.
Thanks for having us.
Great to be here.
I think this is a really cool idea. Long ago, way back, I think it was 2023, I did a stroll down startup lane. And the idea was, hey, this startup row is a really cool experience. But only attendees of the conference actually get to walk down the lane, walk down startup row, talk to each company, see what they're building, get that energy. So let's bring it to the podcast listeners, bring it to the world. So here we are. And you two are the organizers, right?
Mm-hmm. That's right.
Well, thank you very much on behalf of everyone.
Quick introduction.
Shay, welcome to the show.
Thank you.
Yeah, tell us about yourself.
So my background's in early stage venture and technology.
I was part of the founding team of a fund called True Ventures.
And then I was there for three funds, seven years.
And then after that, decided I wanted to start a company of my own.
So we were a full stack Python dev shop, and we were building an EdTech SaaS product.
And we had the opportunity to be featured on Startup Row at PyCon in Montreal in 2015.
So that was my introduction to the community.
And I had a fantastic experience.
And then we later got acquired.
And so in order to give back to the community, I started judging with Jason a couple years
later.
He asked me if I would help contribute to the process by being one of the judges that
selected the companies.
And then a couple of years ago, asked me if I would co-organize with him.
So that's how I got involved.
I've loved being part of the community.
I think it's fantastic and used to go to software development meetups in San Francisco to recruit technical talent.
And I always wondered, you know, with my venture investing hat on, why aren't the VCs here?
Because these are the people building incredible technologies.
And so really see the opportunity to feature these great companies that have become part of our corpus of startup for talent.
So you've lived the entire journey, which is awesome. Congratulations.
Thank you.
Jason, welcome.
Hey, good to be here.
So how did I get involved?
It was around 2015 when I was a financial journalist primarily covering startups and technology and venture capital stuff.
When at the time, the then organizer of Startup Road asked me to pinch hit for a friend of mine who was going to be co-hosting or emceeing a pitch event in Chicago.
And unfortunately, my friend wasn't able to participate.
And at the time, the organizer, Startup Pro, asked me, oh, hey, Jason, you do some stuff with media.
You seem like you'd be good on stage.
I'm like, no, that's not true.
And he's just like, but you know some stuff about startups.
And I'm like, yeah, that is true.
And long story short is I got convinced to host this pitch event, and I really fell in love with the Python community.
This was during a time in my career where I was sort of transitioning into doing more like data journalism.
And I got really frustrated with like the limits of what I could do with, you know, Excel, you know.
And this was just at the very beginning of my journey, learning what little Python that I do know.
And so, you know, it's an amazing community.
and very long story short, this is my 10th year of organizing or being a co-organizer of Startup
Row. I sort of became the primary organizer in 2019, and I'm really excited to have Shea board.
I have some statistics to share, but I'm happy to share those later.
But yeah, that's a little bit about my background. Awesome. Very interesting.
So let's, I do want to hear your statistics. I think they're very interesting. And I have a
little hint of what we discussed. So I have a hint of where you're going. But before we get into
that, let's just give everyone a quick, Shay, maybe give everyone a quick overview. What is Startup Row?
Why are companies there? How do they get there? Yeah, it's a great backstory, actually. So in 2011,
Paul Graham of Y Combinator was collaborating with the Python Software Foundation. And with the
impetus of we want to see more startups at PyCon, we want to feature more of these amazing companies
that are starting new technologies and building things from scratch.
We want to give them an opportunity for a spotlight,
but many of them are so early stage they can't afford the price of admission
or the conference ticket.
What can we do to help create an on-ramp for them and then to feature them?
And that's the origin of how it started.
And it's been amazing that we're 15 years in and the company is just fantastic.
As Jason alluded, we've got some great alumni companies as well.
All right. Well, let's hear the stats, Jason.
Okay, so since the program's inception, there's been approximately 170, 175 companies that have come through Startup Pro.
The format of the program has changed a little bit over time.
It used to be the case that there would be eight companies featured, say, on Friday, and then a whole brand new batch of eight companies featured on Saturday, the two different days of the primary expo hall.
That was kind of a crazy and untenable situation for everybody in the long haul.
And so we have now eight companies per batch.
And so if you look at from 2019 through 2025, so that's counted six batches.
You know, we're looking at about eight companies.
Oh, hang on one second.
Was that six batches?
One moment.
I apologize.
Seven batches.
Forgive me.
Seven batches.
We have roughly 60 companies in that pool.
Of those, we have 32 of them are currently active.
11 of them have been acquired.
15 of them are unfortunately no longer with us.
And a couple of them, based on public activity, a little bit difficult to tell where they're at.
But the bottom line is that of this population of companies that have come through recent startup row batches,
You know, we're looking at approximately, you know, 12 to, you know, 15 percent of them having been acquired.
And then also in that group, we have a couple of companies that have achieved two companies that have achieved unicorn status.
So evaluation of a billion dollars or more.
That includes a returning PyCon sponsor, ChainGuard, which is, I think, valued at three and a half or three point eight billion dollars today after their most recent funding round.
And, yeah, it's it's a it's a pretty impressive population of companies that have come through Startup Row.
And it's been a real joy to see, you know, where everybody has gone after their, you know, after their time at PyCon.
That's incredible. I think those are super good numbers compared to just the general population of startups. Maybe we could kind of close it out with your thoughts, Shay, since you have some of the investing side. Those sound like good numbers to you as well?
That's fantastic. And one of the things I enjoy is that it's such a robust community that when a company comes into Startup Bro, they're getting to meet with their ICP, their ideal customer profile. They're getting to hear straight from the mouths of the developers.
They're also fantastic people.
So it's really exciting to help connect them with the right opportunities and to see some of the larger sponsors at PyCon come over and interface with them and learn about what they're developing.
And one of my favorite times at Startup Pro is to see everybody gathered around the computer screen watching the demo and pointing and troubleshooting.
And one of the companies that you've interviewed, they were saying how many uploads they've had of their product even just during the two days that they were featured.
And so you see the excitement straight from the developers.
It doesn't hurt that it's become the lingua franca for all of the large language models and the different evolution of the technology that we're seeing today.
So Jason, I think it's a fantastic opportunity.
And we love being part of helping the founders on their journey.
Well, let's see if we can get some extra work for you all next year.
Maybe you all could give a quick shout out just to how people apply and what the criteria are.
Oh, absolutely.
Everyone's take it.
Oh, sorry.
Oh, sure.
Sure.
Absolutely.
So there are three very basic rules for qualifying to be on Startup Row.
And two of them are somewhat fuzzy.
The one non-negotiable is obviously you got to use Python somewhere in your stack.
The more the better.
There is definitely a slight implicit bias in favor of companies that are building open source projects.
But that is by no means a requirement to be on Startup Row.
In addition to that, in general, companies are younger than sort of two and a half or
three years old.
And that can be measured from the, you know, either from the incorporation date or like
if the team has been working on a project and then did some major pivot like a couple
years ago, you know, that's not necessarily a count against their, you know, their eligibility.
It's just like, you know, we're trying not to feature companies that were founded 10
years ago and are, you know, more justifiably categorized as like robust small software
businesses.
Right.
And then the final one is, you know, in general, roughly 25 people on the team or smaller,
again, with a bias in favor of smaller teams, just in service of there are plenty.
I'm sure that there are plenty, you know, 120 person Series B startups that would love
free booth space on startup pro at PyCon US.
But this really is for much smaller, earlier stage, high growth ventures.
That sounds great.
Final word, Shay, how do people apply?
When do applications open?
Things like that.
Yes, it moves a little bit depending upon our collaboration with the Python Software Foundation.
But usually applications open right around December, beginning of the year, because PyCon,
as you know, is held in May.
And so we like to have plenty of lead time for the companies to apply.
And also we're trying to coordinate better with the speaker talks.
They can do a submission to have a speaker talk as well, but usually around December, early December.
And Jason, we should probably put an email address up so people can start to reach out in advance if they'd like as well.
Yes, we should. I do believe we have startups at python.org or it's startupro at python.org.
But Michael, I'll get back to you and confirm.
Let's do this. Send it to me and I'll put it in the show notes so people have it right there.
That would be great.
Once we put the call out, it's a quick intake application, a few short questions, and then
we have a panel of judges with different backgrounds to evaluate.
And the news usually goes out in January and then tee everything up from there.
Fantastic.
All right.
Shay, Jason, thank you for being on the show.
And thanks for organizing Startup Row.
It's been great.
Thank you, Michael.
Great to meet you.
Yeah.
Yeah, you bet.
Bye-bye.
Cheers.
This portion of Talk Python on Me is brought to you by Agent Field.
What happens when you give hundreds of AI agents a shared code base and let them write code,
review each other's work, and ship to production?
Well, that's exactly what the team behind AgentField AI built.
And the wild part, it's not some proprietary system locked behind a paywall.
It's an open source Python library.
Now, where most agent frameworks have you wiring up DAGs and workflows,
AgentField lets you build AI agents the way you'd build FastAPI microservices.
Think typed Python functions that become autonomous services.
They discover each other at runtime, call each other like APIs, scale independently,
fail independently, and recover on their own.
And here's the thing.
You're not just orchestrating LLM calls.
You can orchestrate entire anonymous tools.
Spin up multiple Claude Code instances, codec sessions, any coding harness you want,
all running as live nodes on the same architecture, collaborating and verifying each other's output.
that's how they build the factory and it's completely free and open source check it out
at talkpython.fm/agentfield that's talkpython.fm/agentfield the link is in your podcast
player show notes thank you to agentfield for supporting the show now let's meet our first
startup tetrix from nanid and grant nanid grant welcome to talk python and me amazing to have you
here thank you for having us michael yeah congratulations on being part of startup row
A few years ago, I did this episode where we did a stroll down startup lane, and I'm very excited to do it again this year.
And there's a theme. We'll see if people can detect the theme throughout this episode.
But it is also evident here, and that's great.
So let's just do a quick round of introductions before we dive into Tetrix, your company, and how you got on Startup Row and stuff.
Nanit, go first.
Sure, happy to. So I'm Nanit. I'm the co-founder and chief technology officer of Tetrix.
I've been a huge nerd about tech ever since I was a child and transformed that into my degree, then eventually a career.
And now I get to work with some of the smartest people building some of the coolest things in financial markets.
Very cool. It's such an incredible time to be a builder. So amazing. Grant. Hello.
Yeah. Hi. So I'm Grant. I'm the founding engineer at Tetrix.
Background in finance and technology. Former investment banker turned software engineer.
So really excited to, was really excited to join Tetrix and build what we have.
Well, I have a really good friend who has worked in basically as a lawyer and in banking and so on.
And he also does tech now.
We love to exchange stories.
It's a different kind of world, huh?
Very.
I think it's a fun one though.
And, you know, let's talk about your project that you've been working on, Tetrix.
So this is what you were presenting on Startup Row.
I'll tell it to the audience.
What do you got?
Absolutely.
So Tetrix is an AI investment platform for institutional investors investing in private
markets.
And I know that's a mouthful for people who aren't in this space.
So let me break it down a little bit.
So AI investment platform for institutional investors.
So our customers tend to be institutional investors like endowments, foundations, family
offices, pension funds.
Think of it as the pool of investors with the largest amounts of capital in the world.
And when you have that much capital, you're not just invested in public markets, which
is stuff like stocks, bonds, things that people are generally familiar with. But you also invest
in private markets, which is venture capital, private equity, private credit, private infrastructure,
and those asset classes. And what Tetrix does is it makes the management of your investments in
private markets much easier by solving three main pain points. Pain point one is the pain of
monitoring and collecting documents from multiple different sources on the internet. Pain point
number two is taking all of that unstructured data, structuring it and normalizing it,
And then solving pain point three, which is the lack of analytics and insights that currently
exist in the market by bridging that with our data sets and our extractions to make sure
that institutional investors can make more confident investment decisions.
And the platform has really taken off since we launched it.
And the ROI is very evident, whether it's compression of time from 45 days to one day
to insights, whether it is the thousands of hours manually being saved or the 10x deeper
insights that customers are generating from the platform.
Okay.
Well, that sounds super interesting.
I did need to, when I first spoke to you, get a little bit of education on what limited partners exactly means in investing.
If I think about where AI has leverage, people talk about, oh, the AI bubble.
Maybe like my male client doesn't necessarily need AI and that kind of just gets in the way.
But there are areas where it applies so well.
I think coding and data science is probably number one.
But I've always felt that investing has this special lever for AI that you could really get a lot out of.
And I haven't done nothing with it.
I don't know why.
I feel like, I guess because I don't have the experience,
but Grant, you've been in a banker.
So you know the actual day-to-day problems, right?
Yeah, exactly.
I mean, one of the, like, I mean, as a banker,
like doing what we do, like docking processing,
like that was all manual effort of like literally typing in like values
into Excel from like PDF reports, those types of things.
And being able to kind of like streamline that really manual process
is like really fascinating.
Because there were so many hours spent late at night doing this very annoying manual process.
And now that you can kind of do that unstructured to structured transition with LLMs is really exciting.
It's super exciting.
And people always say, oh, man, I always wanted to have some kind of thing help me out.
But I wanted to help me with the drudgery.
I didn't want it to write music and write code.
I wanted to do the boring stuff and I wanted to do the exciting stuff.
But it sounds like you're kind of leveraging it for the boring stuff here.
Exactly.
Exactly. And even not just for customer specific use cases, when you look and peer behind the
curtain at Tetrix internally, whether we're on the engineering side, the business side,
everyone is leveraging what's being shipped out, whether it's connecting to MCP servers to make
their workflows more efficient, whether it is using cloud routines to automate some of the tasks.
We are always thinking about how can we execute faster internally and how can we keep delivering
value to our customers using the AI as a tool rather than just kind of AI wash everything and
say we are an AI native company just for the sake of it.
I mean, that's where the VC is, but just kidding.
Sort of, sort of.
But how do you guys go about making sure that the AI stays on track?
You know, one, I actually, I did use AI for this investment thing that I'm doing.
And it's like a retirement planner, which is fine, you know, but it's not invested in like
the same sense that you all are.
And the AI like gives you recommendations on how your retirement plan is going.
And I get the sense, I don't know for sure.
I haven't used enough.
I get the sense they're using a cheap model to get fast results, which makes me sad.
Like if they were using Opus or GPD5 Pro, you could get such good answers.
But it's really, really quick and responding just makes me real nervous that the answers are super shallow.
So how do you, I mean, it's important the answers and the details you give to people.
They're making really large decisions.
It's not like, oh, I'll buy $1,000 of this stock.
You know, I'll buy thousands of shares of this stock type of thing, given your clientele.
So how do you make sure the AI is on rails?
No, that's an excellent question.
And to your point in finance, like trust is the name of the currency.
And for our customers, it is essential that we are at 100% accuracy with every data point
that we report because the decisions made are so consequential.
To answer your question, there's quite a bit of discipline that we have within the Tetrix
engineering processes to make sure that we are able to get more deterministic nature
of outputs from something that's inherently probabilistic.
And part of those, without disclosing too much of the secret sauce, but some top things are A,
we invested a lot upfront in building our AI and evaluation harnesses. The good news is that the
fact that we need 100% data accuracy means that we have very, very good data sets that are already
annotated, have a human in the loop in terms of making sure it's 100%. And when we run experiments
against those harnesses and those evals, it allows us to move really quickly and also figure out
very quickly if something is breaking or not. So that was number one, because you can't solve what
you don't know. Number two was most of our team has a lot of financial background, whether it is
Grant, obviously, as an ex-investment banker, my co-founder or others. And what we have done is take
that institutional knowledge of finance and encode it into a set of over 250 financial rules that are
checking the outputs generated by the LLMs to make sure that things actually make sense from a
financial perspective, whether it's within a document or when you look at things from a time
series perspective. And number three is we have also built a lot of feedback loops so that whenever
there's a human review or there's an erroneous data point spotted, we actually learn from that
behavior and make sure that the subsequent extractions keep getting better and better.
So with some of these things, we have been able to really get very high accuracy. And in private
markets, I would argue we have the highest accuracy out of the box where our average accuracy is 96%.
And that number keeps ticking upwards as we continue investing in this part of the platform.
cool. So why Startup Row? How'd you end up there? Yeah, so we applied for Startup Row to, so we
wanted to be more integrated into the Python community and also to expand our team. So we
applied given that PyCon's the largest event conference for Python developers and our whole
backend is built in Python. We wanted to kind of go there for a recruiting perspective, get the best
and brightest talent and also see what other people, other companies and, you know, individuals
are working on, whether it be open source projects or, you know, companies that we use
on a day to day basis.
Yeah.
So basically, and also to tell people about what we're doing and kind of get the word
out about Tetrix.
Yeah, cool.
So you're looking for possibly hiring some Python folks?
Yep.
Across the stack, we're looking to definitely scale up our engineering team.
so yeah, I mean, front end, full stack back end, but you know, from a, an AML,
but from a coding perspective, like definitely at least a lot of their backend data pipeline,
that kind of thing, fully in Python.
Well, I was talking to someone else.
I won't call them out explicitly just now, but they had a really interesting insight
saying that, you know, AI is going to change our jobs, obviously.
I mean, that's not a huge revelation, but, but that it's probably going to shrink really
large companies, because there's kind of a lot of support that maybe the AIs can do, but it's also
going to expand out the existence of small companies, what small companies can do and so on.
And it kind of sounds like you're a bit of an embodiment of that. Yeah, I think that's a fair
analysis. I mean, we are a small but mighty team. We're growing, adding headcount as needed,
but AI is obviously supercharging productivity internally as well. So what a person can deliver
in a unit time has for sure increased
and we want to keep leveraging those things
to make sure that's true.
But at the same time,
there's so much demand for the product at the moment
that capacity still is the constraint
and hence why we're very excited to bring on more folks
who have Python expertise into our community
and into our team and work with them.
That sounds really good.
That sounds really positive.
Like things are going well for you.
I talked to Jason, the organizer of Startup Row
and pointed out how many of the companies
are either still going, got acquired
or went public or whatever.
So there's a good track record there.
So how did your experience at Startup Row go?
Was it worth going?
Did you meet people who might be investors or partners?
Did you find people who might build some of these roles?
Was it worth going?
Yeah, definitely.
I mean, it was definitely a really great experience.
I mean, we got to basically talk with a lot of people from different backgrounds.
Yeah, I found, I mean, definitely a lot of promising candidates.
And also it's very just cool to talk about our company to people who are like kind of like very large established financial services companies and tell them about what we're doing.
They kind of get the business problem.
But it's also really cool to see that we're in kind of the same like we're in Startup Row, but like we're talking to the same people and kind of being involved in the Python community as some of these really large established players.
Yeah, when you all describe what you're doing, I'm like, there's something with a long sales cycle. People don't go to your site and just put in the credit card.
Very true.
The laugh of, you have no idea how hard this is to sell to enterprise, right?
Just the timeframe from first contact to like, yeah, we'll do it is I'm sure really, really large. I've been on that site a little bit and it's kind of mind blowing.
All right, a couple of things to wrap things up here.
Give us a look inside,
like a tech architectural look
of what you're all building.
You know, it's got some Python stuff going on,
but what kind of tech is at play
without giving away secret sauce?
Yeah, so generally like our whole backend is Python.
So we use FastAPI for all our, you know, HTTP services,
use Pydantic for models and data validation,
use a lot of like, you know,
when we use AI, we're usually calling or doing things from a Python client for all of our data
pipelines. Yeah. And I mean, we obviously use like other technologies, but, you know, I mean,
be it like, you know, pandas or, you know, NumPy for like kind of more of the analytic side and then
different kinds of packages for doing OCR and data extraction and all that stuff is basically Python.
Fun. It's a cool tech stack. It's really neat to work with these things these days. It's a lot of nice tools. So what's on the roadmap? You are host startup row. You've had a lot of conversations. Where are you leading? Maybe did also did some of these conversations influence you a bit on what you should focus on?
That's a good question. So, well, we have some exciting fundraising announcements coming soon. And as part of that, we obviously are going to spend a lot of time doubling down on the product and delivering the best customer experience possible. So in terms of some things that we're excited about, and I'll put the business hat on and then the tech nerd hat on. But on the business hat side, we're working on some very interesting new features. So if you look at Tetrix, you can kind of think of it as a three layered cake. There's the data capability layer, there is the workflows layer, and then there's the inside.
layer that we deliver to customers. The data layer, we've been spending a lot of time since
the start of the company. And I think we're in a really, really good position there.
And we really want to start double clicking on the workflow and the insights there. So a lot of our
time is being spent for use cases specific to our customer on those two layers, whether it is
being able to diligence, net new opportunities faster, whether it's being able to get flexible
outputs in terms of investor memos and some of those things. So we'll be doubling down on those
things. On the tech side, where we're spending a lot of time on the roadmap is scaling and
optimization. As we grow as a company, the amount of data points we are seeing is way larger than
we have in the past. And that obviously puts pressure on the systems itself, but is a very
fun and interesting technical problem of how do you end up scaling that data. AI is moving super
quickly. So all of us have the pulse on what's going on. And we're always thinking of ways to
kind of leverage that if it makes sense within our product. So those are some of the many,
many, many highlights that we have on the roadmap right now, but hopefully gives a good teaser of
how we think through the product and how we think throughout on the tech side.
Cool. That sounds very great. Very nice plans there. So final thought, as we wrap up our time
together, what advice would you have for people who maybe are thinking to start a company or have
just started or maybe pre-revenue or something along those lines who want to be on startup row?
I guess we each can take this one. I'm happy to start us off. I think general advice for a startup,
don't be a solution in search of a problem.
It should be the flipped way around.
So put in all the effort upfront
in terms of really understanding your customers,
the willingness to pay,
what value are you providing
relative to what's out there?
What's your unique point of view?
Those things.
So that's the general word of advice there.
And I think for startup role specifically,
the advice is be very intentional
of why you're showing up to PyCon.
Everyone's time is precious, including yours.
So make sure there is a true objective there.
And one thing I didn't realize actually going in
and wish I had known earlier,
Lightning talks fill up really fast.
So more tactically, make sure you sign up for lightning talks ahead of time.
So that's my piece of advice generally and with regards to PyCon.
Excellent, Grant.
Yeah, so for me, I was at a startup prior to Tetrix, which did not succeed.
And being part of Tetrix, which is doing really well.
I think the key thing is having really concrete problems that you can solve for your customers
and being able to, you know,
be able to have a product that really alleviates
a pain point that people are willing to pay money for
versus like, this isn't like nice data to have,
nice thing to do,
but versus something that's like,
wow, this really like revolutionizes the way I do my job
or anything like that.
And the fact that we've been able to, you know,
you know, really scale up and gain like
these really high profile customers
and we're kind of like transforming their whole experience
just means that we're solving a really important problem.
And that's kind of like, you know,
what I've seen at, you know, at Tetrix versus my prior company.
And I'd say for startups coming to Startup Row,
I mean, I think just be really like curious
and open to different people and like, you know,
see what, really be interested in what people are working on.
You know, maybe someone comes, talks to you,
they have no idea what you're doing,
but you can at least like go and explain
like how your company's working,
how you're using Python,
kind of connect from an engineering perspective.
because a lot of those like engineering problems
are kind of the same.
I mean, it's all, you know, data and users
and, you know, dealing with those types of problems.
So just trying to educate,
but also take in as much as you can.
Cool.
Well, let me just riff,
just a moment before we close it out here.
I've always said that it's,
I know a lot of people are getting into tech
or getting into programming.
They're like, I want to be a software developer
and I'm choosing APIs
or I'm choosing, you know, data science or something.
And that's great.
But I think the real secret sauce of being super successful is having some specialty like investment banking and some programming skill.
And if you're quite good at both and you intersect them, you're all of a sudden extremely powerful in a very, very small space, right?
Like taking your knowledge of banking and turning it into this product with programming and AI skills puts it into a really rare space, which I think that's a really good way to lever up your career.
as people are thinking like, oh, it's hard to get a job at a big tech company.
It's like, well, maybe you don't check just chase just straight down the line of I'm just
going to be a web developer, but some kind of intersection with your specialty or your
passion.
Yeah, exactly.
And one of the great things about startup is like you're really close to the business
problem and you see kind of like software and it's more targeted how you're going to
solve like actual problems that your users are going to are facing and you're getting
the feedback live and it's really rewarding environment.
And also you get to learn a ton because you're basically working across the stack on every
problem that you're getting.
And it's really an awesome way to learn programming.
Yeah, that's awesome.
I love small companies.
Now, Ned, you got the final comment for the show.
Let's wrap up the segment.
It's just the thing that we were saying reminded me of back in the day, there was this analogy
of being a T-shaped developer where you cut across the stack and are deep in one thing
technology-wise.
I think now it's almost like you have two T's to what you say.
You have like your technology T, but you also have your domain expertise T.
And that's kind of the next metamorphosis, I guess, of how the engineering role is going to play out.
But my final word is just thank you again to the Python community.
Thank you to you, Michael, for having us.
And we're really excited as a company at Tetrix here to be deepening our partnerships.
And if anyone is looking for roles or wants to join an exciting startup, Tetrix is always on the lookout for the best and the brightest.
And we'd love to continue the conversation as we continue to scale.
Awesome. Well, congratulations.
you guys for your success so far and wishing you more in the future talk to you later thank you so
much michael talk to you thanks michael next up we have david from arcjet david welcome to talk
python to me awesome to have you here for this startup row segment yeah thanks for having me
it's gonna be fun it was nice to meet you at long beach i enjoyed the conference a lot how was it for
you yeah it was good and the python community is great so always good to be there in person it's
not my first one. So it's always good. It's a little rejuvenating, at least for me, to
actually connect with the humans on the other side of the docs and projects and so on.
Yeah, absolutely. Yeah, well, let's just start with who you are. Do a quick introduction for
the listeners. Yeah, I'm David Mitton. I'm the founder and CEO of Artjet, which is a runtime
application security startup. I also run a DevTools newsletter called Console.dev, where I review
interesting developer tools.
35,000 subscribers have been doing that for almost six years now.
But the day job is helping developers secure their applications.
Very cool.
So I'll be sure to put your newsletter in the show notes.
People can check it out.
But security, you sure it's not just a fad?
Yeah, everything is secure.
No problems.
We've solved security.
You can all go home.
Yeah, exactly.
We have so many tools and we have so much more awareness, but we also have a lot more
clever people trying to do bad things, right?
Like just look at all the supply chain issues we're running into.
Right. Supply chain is a real problem.
And it's been ignored for a very long time.
There's some really interesting tools that are coming up around that.
Artjet sits in your application once you deploy into production.
So we protect against attacks coming in, automation.
We help you enforce budget controls, deal with prompt injection.
But the supply chain is just as important.
I kind of split it pre-prod and prod.
And we're probably on to year end production.
And then pre-prod is all the code scanning,
dependency management, all those kinds of things.
Yeah.
Some of the worst attacks have actually been
through this whole supply chain side.
You probably remember long ago
when the internet first came into existence,
some of these systems didn't have passwords.
It's just, what's your username?
Oh, okay.
Hi, welcome back, Dr. Falcon or whatever.
And it seems so naive.
Like, how could that be?
But I think, you know, pip install something or npm install, it's almost, it's just inviting
other people's code that you don't know to run on your computer without checks, at least
traditionally, which is insane.
So I don't want to go down that rat hole, but it's just, you know, the thought of that
analogy there is like a little stark, I think.
But let's talk about ArcGIS.
So it is security that runs inside your code.
Tell us, I know you gave a little bit of a hint there, but tell us a little bit more about
it.
developers have this really bad reputation for not caring about security and that was front of mind
when i started the company because like you said there are so many security tools it's just they're
not built for developers they're outside of your code they're outside of your editor they don't have
any connection to what's going on inside your code base and so developers would often just delegate
that to a third-party service or a different team and just like with devops where developers take
responsibility for the applications that they're building, I think we can apply similar principles
to security. Whereas if you give developers the right tools and the right principles,
they can just think of security as another feature that they have to think about and build.
And so that's what Artjet is. It's an SDK. You drop it into your application dependencies.
We support Python, JavaScript, TypeScript, and Go. And then it gives you these building blocks to
solve problems and the problem framing is critical because developers when they have to think about
security often do it once as a problem they're not buying a waft they're not trying to buy code
scanning static analysis tools they don't search for those things they search for i'm getting spam
signups or someone's abusing my application and i need to apply budget controls these are specific
developer-focused problems.
And that's where we try and help developers.
We give them building blocks for bot detection,
for sign-up spam protection, for prompt injection.
And more recently, we're creating these in a way
that means you can just get your coding agent
to solve it for you.
That's what you've got on the screen there.
And you just install our skill,
and then you ask your coding agent,
set a bar jet, and it will go through,
examine your code, figure out what endpoints,
what routes, what tool calls need protection, and then install OutJet and help you solve the
security problem. That is really neat. I love how it knows, basically bootstraps itself onto the
system by teaching the AI agents how to do things. I'm really starting to notice people deeply
thinking about how to support AI agents that work alongside developers for their projects. I just
had the great tables guys from Positon, and they've got a whole section on agents and skills and
stuff so and CLI so that if you want to create documentation it's not just you create it but
here's the tools that the agents can use to work this to help you create it as well and it sounds
like you got something real similar we started with developer experience because the insight
I had was that the best developer tool this is from from reviewing thousands of tools with console.dev
but the best developer tools have the best developer experience so that means good documentation
I mean, it means proper comments that your editor can surface as the IntelliSense type
pop-ups that show up in your editor to give you hints by what you should implement,
creating examples.
And we started in 2023 before coding agents really became as dominant as they are now.
But what we created by accident was this idea of agent experience, because good developer
experience is very similar to what you need to do to have good agent experience and so today that
means we have skills you can install we've got an mcp server so you can query your data or your agent
can query your data and to help you understand what you need to do we've got a cli and we make
it super easy for you to just point your coding agent at our docs or our lms.txt and then it will
figure out what needs to be done.
Like if you scroll up a little bit, the CTA that we have on the homepage, the
first one is start with a prompt and you can go to the code if you want, but
install the skill and then you tell your agent what to do.
And where developers would often get stuck is you've done that initial
installation or then what?
Because that's in your code, you have all the context of who the user is and
you can log rather than blocking.
And when you deploy, your agent can follow along, can follow the logs.
It can connect to Archer.
It can pull all the data out.
And then it can make suggestions to change the rules to avoid false positives and then
commit them for you.
And so what you get is this security partner that works with the Archer building blocks
and helps you solve these security problems.
I love it.
That's a really great onboarding experience.
I feel like there's this split of a lot of people having great experiences with AI agents
and a lot of people not having them.
And I know there's a lot going on there, but a lot of people not having great experiences,
I think there's just steps they're missing or techniques they're missing, or they're choosing a really, really free, simple model.
But things like this, like you just automatically run a single command to install the skills.
And now AI is already better with this.
It's really, really cool that you've thought through it.
Obviously, having the AI work within your system.
So when I'm using your SDK, is it actually doing AI at runtime or is AI sort of around the more static side?
We use AI for the prompt injection detection side of the product.
And that happens when you build in that particular building block into your code.
But we have other components.
We do PII detection, so we can detect email addresses, credit card numbers.
And that happens entirely locally.
We actually ship a WebAssembly sandbox with the SDK, which runs in process in your environment.
And so when someone submits their credit card number by accident into your support form,
we do that analysis entirely locally and it never leaves your environment.
But to do something like prompt injection detection,
that's where we run a load of specialized models on our cloud.
And so the call goes out to us and then we're running AI behind the scenes.
The difference is just the kind of thing you want to protect against.
Like if you're doing a form submission, then you want us to respond within,
we set an SLA of 20 milliseconds to respond to those.
So you would never notice.
And if it's inside the WebAssembly sandbox,
it's less than a millisecond.
But if you're going to an LLM,
then it may take a couple of seconds to get a response.
And that's normal as expected.
So we have a little bit of leeway to do our own analysis.
Typically, that's around 200 milliseconds.
Yeah, if you add half a second to someone else's LLM call,
it probably, you couldn't tell the difference.
It could just be, oh, well,
the LLM's a little busy right now, right?
Yeah, very cool.
Okay, so why start this company? Why start ArcJet?
I started it because I felt that the developer tooling for security just wasn't there.
And we had gone through in the previous few years, kind of 2020 onwards, this revolution,
certainly in the JavaScript ecosystem. And then it started going over into
Python and into the other ecosystems as well, that you would get these amazing tools,
You get amazing cloud platforms.
You get amazing CLIs and tools for developers to write code.
But it was five or 10 years behind in security.
And I thought we could bring this new approach, the developer experience to security in your code.
Something that's actually built for developers to try and solve problems.
And I thought we could build out a platform company to solve all these different problems.
But developers need these building blocks.
And so that's why we've kind of split the product up into these different areas.
So you can come to us for one thing, like prompt injection detection,
but you probably also want rate limiting to implement budget controls for your AI tool.
You want bot protection to stop automation attacks against your application.
You want PAI detection.
So all of these things start to compose together.
You can use them individually or you can bring them into a multi-rule security policy.
But that's the reason for creating this.
Seems like a great idea to me.
So Startup Pro, how'd you end up there?
Yeah, I was following the Icon blog for a while
because I knew we were going to do a Python SDK
and wanted to start getting into the community.
Python's actually the first programming language
and I really learned and I've been writing it since 2008, 2009.
So back in the Python 2 era.
But we started out.
The two to three wars.
You're a veteran of the two to three wars.
Yeah, I know.
Luckily, I kind of stopped writing Python for a bit with my last startup.
And then when I came back to writing code, it had already gone on to the 3, version 3.
So I kind of skipped that pain.
But we started with JavaScript and we just had a JavaScript SDK
because all the new applications were being built using JavaScript and TypeScript.
As AI started to come onto the scene properly
kind of end of 2024 into 2025,
Python really started to shine again
because it's been native in the data community,
the data science community for a long time.
And it's where all the AI work is happening.
And it started to be used for the AI backend APIs again.
And we just built our own backend.
I'm using the Open Inference Protocol
and that allows us to run different models
but have an abstracted layer internally
because our actual core infrastructure is written in Go.
That's what I moved to from Python to Go.
But we've decided we were going to release the Python SDK,
which came out at the beginning of this year.
And that was just in time for the startup row application
and to attend PyCon
and start getting it in the hands of Python developers.
Nice.
Is that a little bit like Open Router and those other things,
this middle layer?
It's similar, yeah.
The challenge with the models is they all require different things.
They have different inputs.
And if you're going to run multiple models, which is what we do,
we kind of run the prompt injection detection in parallel
across multiple models and then compare the results.
And for our backend to have a consistent API
where we get the result out, we want to get the token count,
we want to monitor the latency,
we created a thin layer that uses the open inference protocol,
which is what our Go code connects to.
And then that abstracts away the differences of the different models.
And that makes it a lot easier to just build our internal client server architecture.
Makes sense.
So how did Startup Row go?
Did you make some good connections?
Did you feel like it was worth going?
Yeah, it was great.
And it allowed us to get in front of the community with the support of the PyCon organizers.
It was interesting comparing to other conferences because to date, we've been mainly at JavaScript conferences.
And the type of questions that we get really shows the understanding of building AI workflows, building AI APIs, building the data models and the data workflows behind the front end applications, which are still typically built in JavaScript.
And just the questions are very different.
And you could utilize a different type of engineer at PyCon than you do a JavaScript conference.
Yeah, there's some really clever people there.
I always feel like I'm talking to some really smart people in the room when I'm interacting with the PyCon attendees.
So you talked a bit about the tech going on behind the scenes.
It's interesting that you have Go, I think, there.
It really seems like that's server-side type of programming first is what Go is for.
I think people think Go Rust is kind of similar, but Rust is a little more lower-level operating system type of thinking,
I think, whereas Go is all about async and programming.
What are your thoughts? I know you're not doing it, so there's no reason to switch over.
What are your thoughts about using some of the modern Python API things for your backend?
We use FastAPI and we use an SGI app that's hosted on Modul for our AI inference.
Modul gives us the GPUs and the hosting environment auto scales.
And then our applications are just deployed in containers.
The Go API, the Python SDK that our customers use is Go because it's a gRPC API.
And Go has the best libraries available for gRPC because gRPC is written by Google and Go is written by Google.
So they have the best APIs.
I mean, yeah, they were built to go hand in hand.
I feel like gRPC never really spread beyond Go.
I mean, there's some options in Python to use it and some other languages, but it's kind of like,
It still feels proof of concept to me.
I don't know.
I've looked at gRPC as well.
I'm like, that'd be pretty neat, but no, just do JSON or something.
Yeah, we did it because of the performance.
So we talked a little bit about the latency.
And if we're sitting in your request path, we want to respond as quickly as we possibly can.
Like ignoring the prompt injection detection, which adds a couple of hundred milliseconds.
When we're doing bot detection, when we're doing rate limiting, we want to give you a response within just a couple of milliseconds.
And so when you install our Python SDK, it opens an HTTP2 socket that maintains persistent connection with our edge network.
And that removes some of the latency because you don't have to establish a connection every time.
But then we're making RPC calls using gRPC to minimize the latency because the wire protocol is binary.
So it doesn't have to do the heavy work that you do when you're parsing JSON.
and that just makes it a lot more performant and means that when the communication is happening we
can we have backwards compatibility with the protocol layer it just gives us a lot of these
nice properties and that allow us to have a stable but perform an api yeah it makes a lot of sense
i'd probably use msgspec these days if i was really really worried about packet i think gRPC is
also great but like if i was had to fit it into the python space i'd probably go message spec
I think that's probably the tightest, most binary packing you can get these days.
Yeah, definitely.
There are some interesting options now, but we support multiple languages.
So we started with JavaScript.
There's some really good generators for gRPC in JavaScript.
And we've just done a Go SDK as well, and we're going to go to other languages.
So we looked at a few different options, and this was 2023, so it's a few years now.
You had a lot of time to think about it.
no one was going outside anymore.
What a weird time.
So give us, I want to maybe just get your perspective here
since you've lived on both sides of these fences.
How is JavaScript, TypeScript security
different than Python right now?
That is a good question.
I think PyPI hasn't had the same problems as npm has.
And it's probably a factor of its popularity
with where all the attention is.
That's going to change
because these package registries are really set up
almost as volunteer organizations.
And certainly PyPI is run by the Python Foundation.
So that is a kind of formal connection there.
But they don't get the funding of a megacorp
that should be able to invest huge amounts in security.
Of course, npm is run by a megacorp.
It's run by GitHub, which is Microsoft.
And so they should have the resources to really improve security.
But that just hasn't...
Still, they're struggling under all the attacks.
They're struggling.
They just haven't allocated the resources it really deserves.
And this is just a problem with the architecture
because they were built in an era
when this just wasn't an attack factor.
It was just so much trust around open source.
It's like, it's built for the good.
They put it out there for you to use.
It has a license, just install it.
Well, maybe that's not the only problem.
Yeah, that's right.
It's just they provide a very basic service.
It's basically just hosting your code in a certain way,
but that's been abused.
And it's multiple orders of magnitude increase in traffic.
And that just means you're going to get bad actors
and they're going to exploit it.
Yeah.
I honestly think that with all the agentic AI
helping people write little bits of code here and there
and stuff like the security supply chain thing
that we're talking about,
there's going to be a lot more vendoring.
And if you only need one or two functions out of a library,
maybe you could just have Cloud write it
and you don't have to depend on anything and worry about it.
yeah it's we'll see where it goes in the next five years agreed yeah that's why google's
always run things they always vendor all their dependencies and now i think if it's just a basic
dependency that's not really doing that much you can get your coding agent to do it for you
i one of the things that i always talk to our customers about is that well you can write your
own frame limiting library you can do that pretty easily and use redis but can you build your own
bot detection and deal with all the kind of the arms race of keeping up with automation that's
where we think we add value and i think that's the way we're going to see what dependencies is most
of them you're going to write yourself or get your ai to do it but there's going to be a few key
things that really you shouldn't be doing yourself like crypto cryptography not cryptocurrency
that's going to be the that's going to be the questions like what is the crypto equivalent
yep 100 if you see people doing 100 from scratch their own crypto that's pretty much a
very big one, a red flag. So speaking of, you know, what people are going to be doing,
what's the roadmap? Let's close it out with the roadmap for ArcGET. Where are things going from
what you have now? We're going to add more language support. And it's not just a case of
code genning a library because we have the WebAssembly component in there that does a lot of
the security analysis in your environment. And that requires a bit of engineering work for each
platform. In JavaScript, WebAssembly is native within Node, within the runtime, so we have to
write the bindings, but it's relatively straightforward. In Python, we use WASM time,
which is an open source runtime for Python. And in Go, we use one called WASERO, but different
ecosystems have different packages because often WebAssembly is not natively built into the runtime.
And so that's where a lot of the work goes, is making sure that WebAssembly works in a way that is performant and native.
So we're going to add more language support.
That's the main thing.
Okay.
Yeah, that's, I mean, got a solid foundation.
Now you just want to make it available to all the different users and developers of different platforms.
You know, it would be pretty interesting.
In Python, we've got the CFFI and the C bindings and all these different interop things and Rust through PyO3.
It'd be kind of interesting to just have a native execution of Wasm in the runtime without
some kind of adaptive layer type of thing.
I think that would be cool.
Definitely, because I want to have absolutely nothing to do with C in a security focused
application.
I can imagine that.
Yeah, definitely.
It should be built into the runtime, but then we had the problem of minimum Python versions
and all those kinds of things.
And I think Python 3 people do typically stay more up to date, but it's still a problem when
you require people to be on the very latest version of the runtime.
Yeah, 100%.
A lot of people just take what comes with Ubuntu or something, which is usually a year behind.
All right, David, I appreciate you taking this time to chat with us.
Congratulations on ArcJet and good luck for the future.
Great.
Thanks a lot.
Yeah.
Bye.
Our next startup is femoral.dev.
And we're going to be talking to Chinmaya.
Chinmaya, welcome to Talk Python.
Excellent to have you here.
Hey, super nice to be here.
Fun times hanging out in PyCon, meeting up on Startup Row.
That was a really cool setup there.
Yeah, it was really good.
It was a pretty awesome opportunity to be there.
So glad we made that happen.
I can imagine.
I was talking to one of the organizers and the success rate of startups on Startup Row
is really high.
Hoping to follow suit.
I hope for it.
Exactly.
Let's keep it rolling, right?
Well, let's actually begin by having you do a quick introduction for the listeners.
Sure.
Yeah.
I'm Chinmaya.
I'm the founder of Femeral.
We're like a hosting platform for Python-based web apps.
And yeah, just excited to be here.
Awesome.
I think hosting's been around forever, right?
Like cPanel land and all that weird stuff.
But it seems like there's a lot of opportunity to create better opportunities, better developer
user experiences, and also cost, right?
Yeah, that's kind of our angle, right?
is like, obviously you can go and spin up a server.
Pretty much every company under the sun offers that service.
But, you know, we really want to focus on the developer experience,
making it as seamless as possible to actually get your code
hosted into a place where it's live
and without having to, you know, deal with the manual steps
and extra problem surface area that come with,
you know, potentially managing your own hosting.
And like you mentioned, the cost, that's also a factor for us
because, you know, especially when you have persistently provisioned compute, you really
have to size and scale your servers such that they don't, you know, break your wallet, break
your bank account.
And so you're kind of dealing with two problems, right?
It's like, is my server or set of servers actually going to be able to handle all of this traffic?
And at the same time, am I going to be able to pay for all of this?
Yeah, that's both the promise and the potential downfall of the cloud is it's easy to set up
a few things.
they won't cost very much unless they take off and then maybe they do.
Yeah.
And then, you know, you're spending all this dev time, you know, trying to manage all that
infra on top of that.
So, you know, if you equate, you know, potentially your own developer time or your team's developer
time to money, you know, that that's another cost that you have to think about.
What about AI and specifically vibe coding?
I'm not a huge fan of vibe coding as a concept, although it's super fun to just come up with
a crazy idea and send the agent off and go, I wonder what it does.
Right.
But as a form of engineering, I'm not a huge fan of it, but I do think that we're in an emerging world where there's many people who have programmed in a sense and they have an app and then they're just completely like, well, how do I get it on the internet?
You know, because they're not really developers, right?
And there's like, I don't Linux, I don't DevOps, but I still need it on the internet.
How do I go about that?
Right?
What do you think?
Yeah, I mean, that's, you know, a massive cohort that's, you know, kind of emerging into the new
space of builders, right? And, you know, they want to host their stuff in a place where it's live,
and they don't have to, you know, deal with the extra, you know, headache of figuring out,
like you mentioned, what is all this Linux stuff? They kind of just want to be like, hey, I vibe
coded this Flask app, this Django app, this FastAPI app, and it's really cool. And I share with all
my friends, how do I do that? Right? Where do I even start? Like, what is a server?
These types of questions are really a big blocker, right?
And that we do serve those people as well, quite well.
Yeah, I don't want to position you initially as only serving VibeCoders.
It just, it seems to me like that's a whole nother area of people who really could be
served from a simplified deployment experience.
But there's others, you know, I'm thinking data science, honestly.
There's a ton of data scientists who have built something amazing, but they're not really
DevOps software engineer side.
They come from more from the science side and they've done really cool work, but it's a big step to go from I've got my notebooks running to now I have a FastAPI app to now I have it on Linux.
Yeah, no, there's a ton of like beginner cohorts, I would say, that, you know, are served really well.
For us, we're like mainly focused on, I would say, two main cohorts of people that we see as our ICP.
One is like smaller development and startup teams, right, that have a Python stack.
And, you know, they want to spend most of their time in the business logic and actually
serving their customers' needs and, you know, focusing on their customer feedback rather
than managing their internal hosting solutions.
So they, you know, wouldn't have to, you know, hire someone to do that or spend their dev
time, you know, on those tasks.
And then the other cohort are, you know, agencies and consultants, kind of by the same token,
but they're served a little differently by one of our core features,
which we kind of haven't talked about yet, which is the managed cloud.
Yeah, tell us.
Let's take a step back and maybe position Femoral around.
On one hand, we have infrastructure to the service, EC2, DigitalOcean, Hetzner, VPCs, whatever.
And on the other, maybe you just upload some code somewhere.
Where do you all live?
I think I may have missed a couple words in there because of internet,
But I am going to say we fall kind of in the platform as a service side of things where you want a place to host your apps and you just want to be able to throw them up there without having to deal with these servers manually.
Yeah, exactly.
You got the gist of it.
So basically, it's sort of a continuous deployment type thing.
Create a certain branch, like a production branch or whatever.
Connect GitHub to it.
Push that branch.
Off you go.
Like merge a PR and it's live, right?
Yeah, pretty much. And then all of your code, without having to dockerize or containerize,
because of that build pipeline we built, will get built and will then deploy it onto our managed
cloud, which uses our serverless orchestrator to scale up and scale down and manage the amount of
instances slash containers slash VMs that are running your code relative to the amount of
traffic that's coming and the amount of resources that your code base is using at any given moment
will be properly provisioned to match that traffic.
So that's kind of like what we do in an end-to-end sense.
Code uploaded, we build, we deploy, then we scale.
So those are all the things we take care of.
Yeah, awesome.
I see it says now in early access.
How do I get early access?
Yeah, you just click that button that says get started
and you sign up.
Yeah, there's no, really, there's no gating here.
Yeah, got it.
I have talked to some folks who are like,
yeah, not yet, but you can apply and hopefully, so we'll see.
Yeah, we're wide open.
We would love for anyone who has something they'd like to deploy to come check it out.
Sweet.
Startup Row.
What do you think?
How'd you get there?
Why do you put the time and energy into that?
Yeah, Startup Row, it's pretty awesome.
You know, I was in contact with some of the organizers and, you know, I don't think I really
had a strong sense of what Startup Row would be like before I actually got there.
given that it was also my first PyCon at the same time.
So there's a lot of new happening.
But I would say I did it, you know,
to just kind of get more involved in the community, right?
Like as the company were, you know, made for Python dev.
So naturally I want to be, you know, involved in the community.
And then once we got there, it was pretty spectacular, you know,
got to meet and talk to like so many developers
and people with different problems.
And, you know, people would come up and say,
oh my God, this is something that I really need right now.
And then you'd have people that come up and be like,
this is so foreign to me.
I don't even understand why I would need this.
So there's like, you just get the whole spectrum
and it gives you a really good perspective.
That's cool.
I'm glad you had a good experience.
I don't go to PyCon every single year,
but when I do, I always really enjoy being there.
It's great to just be with people in the community
doing really smart and interesting things.
Yeah, no, I learned a lot more about the community
than I knew before I got there.
Yeah. I think it's also, as a startup, it must be interesting to talk to people and go,
I don't think I need you. What is this? Why do I need this? Because either it helps you focus in
on your ideal customer and say you're actually outside of that slice of the world, or position
your messaging a little bit, right? Like one of the big stories of startups is talk to customers,
talk to customers, like so much easier said than done though. Yeah, no, definitely. You're right
about that. I would say we were able to validate our ICP because the most interest we got was from
smaller startup teams and from agencies slash freelancers or consultants that were, you know,
dealing with clients and had all these staging environments that they had to manage and all this
extra infra. So like kind of validated that in a sense, but, you know, I guess at the same time
invalidated outside of our ICP simultaneously because of those conversations I talked about
earlier. I hadn't really thought about the agency side, but a lot of what happens with the agency is
somebody comes in and builds something really nice and they get it working and then they hand it off
to somebody who's presumably not quite as familiar with the tech
because otherwise they might have just built it themselves.
So the concept of, look, you just pushed to this branch.
Yeah.
That's got to go over well as a handoff.
Right. It's great for a handoff.
And it's also great for managing, you know,
like mock-ups and staging environments, right?
Like say you have, you know, a number of clients
and you send them a mock-up or two or a live demo every week.
And then you have to manage kind of this extra staging environment
for every single one of these clients.
it becomes a lot more infrastructure work for you as a company compared to like, say,
you're just a startup and you just have one product and, you know, you need one staging
environment for that one product. Right. So like for agencies, this kind of infowork can kind of
increase pretty rapidly as the clients increase per client almost. Yeah. Right. Interesting. And
then the scaling, right. Between each client. Right. So there's like, you know, I could get into it,
but we only have so much time. Indeed. So how did you sort of told me how your experience was,
but as a startup, how was startup row for you?
Yeah, I mean, it was great.
We, you know, we've made some really good connections
for potential partners going forward, potential customers.
So I would say it really helped grow the business
and gave us, you know, like, I guess I already said this,
but gave us perspective on like what certain,
you know, personas perceive of the product,
you know, given their context and their background.
I found it very interesting to just walk around the expo floor
and kind of just get a sense of what have people come to promote, right?
You get one time a year to come talk about something and what is their,
what does their banner say?
Who decided to come?
Who decided not to come?
And yeah, it's really, it's a neat experience.
Definitely.
Tech, how much do you want to talk about tech behind Femoral?
I think it'd be interesting, but I don't want to make you give away secrets.
So tell us what you're comfortable sharing.
Yeah, it's fun.
So I guess I can kind of talk about the functional experience of what the tech enables, which is that, you know, we built this build pipeline.
And essentially what we're doing, in a sense, is, you know, at a high level, going through your code base and figuring out like, okay, what are the tools you're using?
What are the libraries you're using?
What do we need to package?
What do we need to build?
And, you know, like that's quite straightforward, right?
You're just kind of parsing code.
It's largely a solved problem.
But then, you know, I guess the more technically interesting side of things is the like serverless orchestration that we've written in the managed cloud.
And so that's kind of based off of, you know, these like fast starting VMs that we use and some kind of, you know, way to take advantage of, you know, really fast cold starts with those fast starting VMs.
Right. So like, you know, when someone does have something deployed serverlessly and it is scaled to zero, well, when they hit it, they don't want to be sitting there for a minute.
right waiting for some instance to spin up right so like a really interesting cost level right
because if you want to keep one running so it's not a cold start but that that that costs money
but if you want to turn it off maybe it's well i don't want to wait 30 seconds for the first request
right right and that's like really uh what we wanted to avoid and what generally happens with
persistent compute so that's like one of the reasons that we as a company decided to build
on serverless compute um in order to like you know drive this experience where you can have all these
things deploy and they've all scaled to zero, but you're not, you know, waiting on a cold start when
you do actually want to use something. And that's kind of powered by these fast starting VMs that
we've kind of built everything on top of. Okay. What can I host there? Look at your website. It
sounds like the standard Python stack sort of thing. Yeah. It's like, I mean, that's kind of
like just the biggest subset of the set of things we can deploy on Ephemeral. Mostly it's anything
written in python exposed with an api and that you wouldn't need gpu compute for because right now we
don't have for gpu compute for many reasons that that's gpu is really interesting it's as soon as
you go down that path it's like well you could start at a thousand dollars and go up from there
rather than ten you know it's like yeah it's tough to offer a reasonable price point with gpus yeah
i'm sure that it is um so one thing i see the web frameworks and they all look real common of
Of course, if you can do all those three, then you can do others, I imagine.
What's the story for data access?
Databases, Postgres, SQLite, Mongo, others?
Yeah, so I guess this kind of feeds into our roadmap,
which is we're now working on building serverless Postgres,
like managed serverless Postgres, to add right into Femoral.
So you deploy your serverless web app,
and right next to it, you deploy your serverless Postgres.
They talk to each other.
It's all in the same platform.
Everything's managed under the same billing.
So it's really straightforward.
So yeah, right now, if you were to deploy in Femoral,
your database would live outside of our compute.
But we are very soon bringing that
into the scope of what Femoral does.
Got it.
Do I get to pick my cloud?
Do I say EC2 or like, sorry, AWS or Azure
or DigitalOcean or whatever?
Do I choose that then pick up a managed database
in that location?
Or how do I relate those two things?
Yeah, so you can choose to locate your database.
like when our database managed progress is offered, you can choose to locate that in whichever region,
basically any AWS region. Although there are obviously other hyperscalers that we could offer
that in right now. And in terms of the actual web app compute itself, that is not necessarily
provisioned into a specific region. But we are working on how we might communicate that to the
user. Sounds good. And I guess anything else on the roadmap that you want to touch on, or is that
pretty much covered the database? Yeah. I mean, basically, right. You have the stateless compute,
and then obviously you need some states somewhere, right? So that's all we're working on, right,
is the Postgres. People want, obviously, Redis, some kind of key value. So managed Redis will
probably come with Postgres. Yeah. Shinmaya, congrats on starting Femoral and best of luck
to you guys and nice to meet you at PyCon. Thanks for coming on the show. Yeah, for sure. Nice
meeting you too. See you later. Now we meet Capiccio in Beyond, its co-founder. Hey, Beyond,
welcome to Talk Python To Me. Yeah, thank you so much, Michael. Really great to be on the show.
Yeah, it's fabulous to have you be part of our startup row segment, stroll down startup lane,
if you will. I think it's such a neat idea that PyCon, the PyCon organizers, Jason and Shea and
everyone else put that together. And so it's just a neat look into what's up and coming in the Python
space. So we're going to talk about Capicio. Capicio. Yeah. Capicio. I love it. This is your
business. And we're going to dive into why you want Startup Row and all those things. But before we do,
quick introduction. Who are you? Yeah, sure. Thank you. So my name is Beyond Denote. I am the founder
of Capicio, we refer to ourselves as the authority layer for AI agents. So identity policy, basically
to be able to secure agentic environments so that they're ready for production and your
SecOps teams aren't freaking out when you're trying to deploy agents to prod.
It's really tricky, right? We've got this non-deterministic thing running, but it's supposed
to be operating in a professional or legally structured environment, right?
Yeah.
It's a massive challenge.
It's blocking a lot of POCs right in its tracks at the moment, or even some organizations
from not even considering AI solutions.
So we're trying to bridge that gap and solve that problem.
You know, I'm reminded of some stat that was probably just made up or whatever, or very
vague, like 97% of all AI projects fail.
And I have no idea what that even means.
Does that mean like they tried to add AI to an email client and they just, it couldn't
be added?
Like, no, my email client just has a very bad representation of AI in it.
Yeah, I have no idea.
Yeah, no, no.
I've seen that stat as well.
I think the source was some MIT paper that ended up maybe not being quite as well researched.
So I don't know what the real stat is.
Maybe we're somewhere close, but yeah.
Yeah, I think it's a much higher level of success.
but things like what you all are building are sort of key to that success, right?
Yeah, absolutely. It's a whole new ecosystem. I mean, if we go back to the early 2000s,
we invented this thing called the internet and we had all these great ideas, but there was a lot
of infrastructure still missing to be able to realize that. And at the time we didn't really
know what infrastructure we really needed yet. With the whole agentic era, I think we've hit a reset
button on a lot of that except we're a lot more technologically mature so i think we teams know
what they need and what they're missing and we're in this build race to to be able to close those
gaps interesting i do think it's just absolutely the wild wild west is not the right term but it's
just an unknown we don't know what we need we don't even necessarily to some degree know what
we don't know for some of these products but it's changing fast i was sort of thinking about that
that one when i threw out when your response to that that stat i threw out is like how much of
that is based on 2024 ai you know what i mean right it moves so fast i mean even six months ago and
you're looking at a different beast you know it's uh it's incredible the iteration pace is so fast
yeah so why'd you start capuchio yes uh good question so um i obviously had been following
the ai space um you know jumping on everything that that i could to be able to learn more and get
into the space.
But I wanted to do something meaningful.
I wanted something infrastructure level.
And then when Google released the first iteration
of the A2A protocol, the agent to agent protocol,
I think it was somewhere around March last year, March 2025,
a few light bulbs started going off.
Because here we were creating a new standard for agents
not to communicate with MCP servers or human agent.
This was agent to agent communication, which we knew
was coming, but the concept blew my mind.
And then looking at DeepMind, Google DeepMind also
released a few papers on intelligent delegation,
agent to agent delegation.
So looking at that, from where we were,
we're just using basically LLMs and chatbots
to a layer where we had agents self-orchestrating
and trying to do that at scale.
That's where, like I explained, early 2000s internet,
we're missing a lot of infrastructure.
And for now, being able to see that realization
for that vision, there's a lot of infrastructure missing.
So that's where I started building,
particularly around the trust layer,
the authority layer,
trying to make sure that agents can communicate
securely, safely together,
and that we can facilitate that
with all the missing layers that we have right now.
Well, it's definitely a challenging problem, right?
We used to write tests or have security scanners, but now, what are some of the new challenges,
I guess, that you see out there that are different than prior stages?
Yeah, good question.
So one of the challenges has to do with identity.
When I started working on the problem, I was focused more on setting guardrails for AI
agents, helping them to communicate together, being able to learn more about each other,
But being able to grant every agent an identity was very important.
Right now, it seems like the current trend is that we're trying to expand the known models around IAM into agentic identity, which is sort of a band-aid right now.
But one of the biggest restrictions is that those are usually within a singular domain.
And cross-domain open web communication, being able to extend that identity concept to really the future that we have with agentic AI on the open web, that becomes a big challenge.
And then along with that, of course, we have what we're referring to as the trust layer.
Just like in human society, we have people we interact with.
And the first thing we even do before we buy a new pair of shoes or a restaurant is we check reviews, you know, on the merchant, on the actual product.
And that mechanism doesn't really exist for agents right now.
So in a way, there's some of those primitives that are missing to be able to really scale that Agentech future up to full speed.
Going to be weird, right?
Yeah, absolutely.
All these things, you'll have to just drop in and check on your team of agents and see how things are going.
You know what?
I can easily see a product manager or some kind of manager agent that you go and work with.
And then it's like, look, how's the whole thing going?
How's the team looking?
And then you scope it out.
You all go work on this.
Get back to me later.
It's going to be weird.
Yeah, we're definitely heading to that future.
I mean, we've maybe seen it in movies before, and it seemed like so far off, you know, but we're all definitely going to have our personal agent that just kind of knows what's going on.
And I don't think it's as far off as what a lot of us are imagining.
No, I don't either. It's going to be odd.
Okay, so Startup Pro, that's where we met.
And while you all were at PyCon, why apply to Startup Pro?
How'd you get there?
Yeah, no, thanks.
Good question.
So I have to be honest here because like a lot of folks who are now using Python and fluent in Python, I sort of backed into the Python community because around the rise of AI, obviously Python, I mean, we can refer to it as the native language for AI pretty much, right?
So started using a lot of Python each and every day.
And then this product that we built obviously has the SDK.
It has an MCP plugin for MCP server harnesses as well.
And then one day I got pinged by Jason.
You know, Jason and Shay organizing Startup Row.
And he gets pinged and he's like, hey, man, have you heard about Startup Row on PyCon?
I think you should really apply.
And I was like, wow, okay.
Checked it out.
learn about PyCon I'd never been before and Startup Row and it just seemed like a great
opportunity so I put the application in but like a lot of things you put in the application like
whatever you know let's see what comes of it and yeah it was a little while later got pinged to say
congratulations so that's how we landed on Startup Row at PyCon and man what a what a gift
what a privilege it really was a it was an awesome experience. Was that your first PyCon attendance?
It was. It was my first PyCon. I've been to a lot of other conferences. Even my partner who was with me at the event, he was just saying how he's worked so many other conferences and the vibe was just so different.
You know, when you're talking to people at PyCon, everybody was chill.
You were talking builder.
It was builder to builder conversations.
Hey, you know, what are you working on?
How are you solving this problem?
And there were just a lot of real conversations.
The vibe was great.
I really enjoyed it.
Yeah, I've been to a lot of different technology conferences as well.
And it is certainly unique.
And I mean that in a good way.
Yeah, yeah, no, absolutely.
So one of the things I think is really critical for startups is getting feedback,
talking to potential or active customers. And the advice is, well, you really got to talk to
customers. It's so hard to do. But on Startup Pro, you get to kind of iterate on that over and over.
Did you get some good feedback? Yeah, absolutely. We weren't sure how many...
This was sort of a big validation test for us because we were curious about the timing of the
market. Is the market ready to have this conversation? And it was interesting from
developers point of view most to be honest were like oh yeah we got to do something about this we
haven't kind of got there yet um but then from from the folks who were working inside larger
enterprises or the ones who have very advanced solutions they were already at the point where
they they totally got it like wow okay this is awesome we need to check this out um so i mean
we're following up now we got a quite a few design partner opportunities which is the point that we're
we're at right now we're looking to work with teams who are experiencing this problem
And, you know, where they can start running our product and find where we need to extend it to make it work for them.
What about the tech?
Are you giving us a peek inside what core technologies you all are using?
Yeah, sure.
Absolutely.
So because it's an infrastructure project and there's cryptographic verification of identities, a lot of handshakes like that going on.
We've actually built the core of it in Go.
It's a Golang, you know, library.
And then we have all the wrappers and all the stuff that would benefit from native latency in whatever target SDK language.
So Python being the main one, that's the only one we have right now.
So basically, what ends up happening, the flow is you can use our SDK, one line of code.
We literally, that's why we had it on our banner at our booth.
one line of code to be able to connect, register an identity for that agent for an MCP server.
That's then cryptographically verified because the private key is stored right on the agent,
right on the server. And then with that identifier, you can now be able to create policy
around the tools and around the agent. What tools is it allowed to invoke? What are blocked?
what group policy, what organizational policy belongs
to this agent or server.
And the neat part in how we designed it
is those are all policies that are compiled into OPA bundles
and are actually cached right to the agent or right to the server.
So to be able to respond to requests is super fast.
It's a sub 10 millisecond because usually when we use security,
we think, oh, well, there goes my latency.
So that was a problem we wanted to solve.
But that in essence is as far as we've gotten in our roadmap right now, we are working on a full public RFC stack.
So our next two RFCs, we're working on the intent layer, which is a whole other fun conversation.
But we're determined to try and crack that as well.
Yeah, yeah. Very cool.
You're not the only startup on Startup Row building the core server side components with Go.
Yes. And that's what we found out.
You know, when we were coming to PyCon, thinking Python community, we were like, okay, don't talk about Go.
This is Python.
Don't say anything.
And then we got some questions like you just asked, you know, were they really pressed?
And they were like, okay, no, that makes sense.
We get it.
That's like, you're like this product or that product, that product that uses a similar pattern, you know?
So, yeah, it wasn't an unusual way to implement it.
Python has a really interesting performance story and relationship with other native build
technologies or native languages.
Like, for example, Python itself runs on CPython, which is primarily implemented in C, not Python.
A lot of the ways that Python is made fast these days is through Rust.
So when you end up at a performance critical section, it's like there's a layer of Python
and then it's Rust, right?
Like my web server, the application server for my website and my course website, all the
things.
It's built in Rust and then it just delegates out to Python, out to Flask, basically.
So I think Python people are more than other technologies used to.
So there's this core of something and then this sort of mix of choose the right thing at the right place.
Yeah, yeah, no, absolutely.
And Rust was a consideration for me.
I came from a C background and Go just really intrigued me.
So we ended up building it and Go in and it's been a good result.
But yeah, I mean, especially when you're doing things like cryptographic verification and you're doing a lot of stuff over again, you wanting to scale to support many different languages, it does make sense to choose a core and then build around that.
But we're constantly tweaking, trying to make it still a really native feel for whatever target platforming, including Python, so that you can use all your customary tools, have a similar experience in your IDE, and now be able to have a way also that whatever agent you're building with, that they understand the structure and the semantics as well.
One more question before I let you go.
Oh, I imagine there's also a lot of Docker in there, right?
Yeah, absolutely.
So that was part of our stack as well.
One of the main reasons we introduced Docker was because a lot of enterprises, when setting up a tool like this, they'll test it on your cloud instance and be like, oh, yeah, that's great.
But can we put this in our private cloud?
Can we make it air-gapped?
I mean, I'm hearing a lot of stories about air-gapped AI solutions and whether they actually have a future or not.
But either way, we implemented around Docker so that it's an easy pull and set up to be able to run it.
I do think that there's, it maybe won't be the most common way, but I think there's probably some juice in the air-gapped AI.
Because with the air-gapped AI, you're going to need your own local models.
But, you know, for example, a PyCon and an NVIDIA plus Anaconda combo, they had their little AI cubes, you know, their sparks doing a really cool live AI demo.
And if you were a big organization, you needed, you really needed privacy.
I could see buying a 10 GPU cluster and just setting that up and make it go locally.
Yeah, it was interesting how many devs we spoke to who are working in highly sensitive environments.
There was even one developer who works with the voice and data control recorders for airplanes.
Obviously, situations like that, they very hesitantly introduce AI.
And if they do, it has to absolutely be very air gapped and sandboxed.
So, yeah, like you said, there's some applications where that is still a requirement, even though for most of us who have been on the cloud for however long feel it's a bygone era, but it really is not.
Yeah. And if I do, I'm not a believer of, oh, the AI bubble is going to pop any day now. But I do think if the pricing changes, all of a sudden, maybe buying a $5,000 machine is the economical choice in the long term. So in which case, that also comes back to that.
Yeah, yeah. And that's an interesting concept too, because obviously what we're paying today, even though we may bulk at it, it is heavily subsidized. We all know that. So either the subsidies run out and hopefully compute has a lot cheaper so that we can keep running or, you know, we have to make some tough choices about what we want to invest in and what projects are worth it. Or like you say, investing in our own hardware to run our own local LLMs.
Yeah, we don't have time to go super down this, but I do think that this extreme load on compute and kind of the subsidizing as well is a forcing function for creating much more efficient compute and forcing the models to execute more efficiently.
And I can certainly see a way where we just innovate our way through to where the actual price falls back to close to what we're paying.
As a data point, the latest NVIDIA H200, I don't know what it's called, H200 or whatever, is 10 times more efficient at difference than the one before.
By what, right?
So you do that a few times, all of a sudden, there's not a bubble.
It's back to normal.
Absolutely.
I mean, we've seen it before in many iterations, right?
Like the need facilitates innovation.
And that's probably where we're going to be now.
And we're facing, I mean, the concept of world models and other stuff happening to quantum computing, which I don't know what everybody says, five years, 10 years, whoever.
But I mean, all that is going to change the game.
So we'll see how it all comes together.
Beyond, thanks for sharing your thoughts.
Congrats on Capitio.
Thank you.
Appreciate that, Michael.
Yeah, thank you so much.
Bye-bye.
Take care.
Our final startup is Pixel Table, started by Marcel.
Marcel, welcome to Talk Python To Me.
Nice to see you.
Michael, thank you for having me.
Great to have you on the show.
Very cool that you all were part of Startup Row, and I'm excited to hear about Pixel Table,
your new company that you're getting going, which is exciting.
Before we dive into all that, though, you've got quite a history in the Python space.
Tell people who you are and what you've been up to.
Yeah, happy to.
So my background is really in database internals.
I did that at grad school a long time ago.
I worked at a bunch of database startups in the early 2000s.
I was at Google from '03 to '10, also working on scalable data infrastructure.
And toward the tail end again on a new internal database system, what we called hybrid transactional
analytic processing called F1.
And after leaving Google, I joined Cloudera and started a project there called Apache Impala,
or later it became an Apache project, a scale-out SQL engine.
And as part of that, I also co-created the Parquet file format
because there was no good open source columnar format at the time.
So this was basically the motivation for creating Parquet
as basically an open source implementation of Column.io from Google's Dremel.
And so, yeah, so that's really my background.
And I got interested in the, I want to say the ML space and computer vision by coincidence when I was an EIR at a venture firm and met a computer vision person there.
So this was early 22.
And I ended up then talking to a whole bunch of computer vision engineers and managers of engineering teams.
And they're obviously all used Python.
And all of that happens in the Python ecosystem.
And that was kind of the motivation for creating Pixel Table.
back then as a, I want to say, a unified view of data and storage and also the transformations
that you need when you're doing computer vision work, in particular model data set curation,
training, and so forth. So that's kind of the origin story of Pixel Table. And I'm happy to
talk about what it is and how it has evolved since then.
Yeah, that's very cool about all the database work that you've done in Parquet.
And it's really clear how that's led you to Pixel Table.
Yeah, it's I think, you know, people are still saving a bunch of CSVs and having huge disk usage because of all that and slow parsing.
And they should look at Parquet, right?
Yeah, I mean, Parquet has, you know, obviously since then become a real industry standard and is also the core of, you know, other industry standards such as Iceberg, etc.
So it's gratifying to see that that had an industry impact.
Yeah, I'm sure that it was.
All right.
So you talked about Pixel Table sort of being inspired by both database work and talking to all these vision folks.
What exactly is it?
It's like a database for images?
Well, it's not.
The name is a little misleading.
It is, at its core, it's an OLTP database system.
So think Postgres, basically something that you can use to power a web app.
You can do single row inserts and so forth.
It is multi-user.
It is transactional.
But now it's specifically meant for multimodal AI or multimodal applications and AI applications in particular.
And so it has additional column types that represent multimodal data.
So you have column types, document, video, audio, image, and array.
Oh, that's cool.
Basically, you can now create a table and put videos in there.
And you would put the videos in there as URLs.
And then Pixel Table would know when you need to do something with a video to actually transparently download it and so forth.
So that's one thing.
And then another specific aspect is that you can now also have computed columns in your table.
And so in the AI world, when you're working with multimodal data, a lot of the work is really transformations and kind of data plumbing.
And so this is kind of what you now can express inside the data model.
And the pixel table runtime will then basically, you can basically express a complex workflow as a number of computed columns.
It's basically a graph, a computational graph.
And it could be things like, let's say, take a video.
You have a table with videos.
You want to get transcripts.
First, you need to extract the audio.
So the audio extraction would be a computed column with the output type audio.
And it uses a UDF called Extract Audio, which uses FFmpeg or libAV.
So we're using standard Python ecosystem functionality for processing this data.
But you can now string it together without having to think about all the data plumbing.
And the whole thing is still transactional.
So you extract the audio as a computed column.
And then you could invoke a transcription model to get the transcript out as an example, which would be another computed column.
So you can build up these very complex graphs.
And then you must have some kind of backend that holds the audio and holds the transcript and then links to it or kind of like you talked about in the video.
So what we do is all basically media data is external and file based.
So if you show up with, you know, let's say a petabyte of videos, we're not expecting you to upload that.
That would be extremely inefficient.
So we're simply referencing it.
The same is true for audio files.
The same is true for computed columns.
You can actually even put a destination attribute on a computed column and tell it to put the media data into a bucket, as an example.
But then we put the structured data into Postgres, and we also use PG vector, but we have our own transaction system and our own type system on top of it.
And so when you do an insert into a pixel table table, it figures out the complete plan, like what goes into Postgres, what needs to happen in Python directly.
We have a runtime system and an execution system that is now able to take this computational graph and optimize it and do parallelization and asynchronous execution and stuff like that.
This is incredibly interesting. The more you're telling me about it, I think this is a really clever idea. The way it kind of turns the database into this workflow engine that just hides all the messiness of, oh, I just need the audio of this thing. So we got the audio column based on, you know, like computer column. And that's, I can see that just saving so much work, so much queue, asynchronous programming and all kinds of things.
Yeah, exactly. And that's really the motivation and the application area, which is basically multimodal data processing, right? Including very complex systems that are fairly easy to now model as basically a sequence of tables and views. So, you know, for a podcaster like you, this might actually be very advantageous.
Yeah, absolutely. I do transcripts and get the audio from videos and all sorts of stuff all the time. It certainly connects with me. So two things I want to talk about on your offering here, kind of the business model and just some features before we move on to startup row. One, let's go with a smaller one first.
I see that you have skills for working with Pixel Table and that you can install the skills with npm or other ways.
You also have startup with uv, like a startup template type thing.
I think there's some really interesting trends for people, including skills and other AI enablers or accelerators in their documentation or in their projects.
That's really neat.
the fact that you can just get the skill so your agent can just jump right in. What's your thinking
there? Yeah, exactly. I mean, this is sort of the way people are writing applications today,
right? You kind of expect to use AI to generate most of the code. And so, you know, Pixel Table
comes with a skill. And we actually think that Pixel Table is very agent-friendly and very AI
coding-friendly because it gives you a semantic model that basically gives you type safety and
also type safety of your data at rest. So it gives you a lot of guardrails and it allows you to
express these complex workflows with relatively little code. So there is less room for the AI
to drive the thing off a cliff, right? You're not going to, even with a very complex pipeline or a
very complex workflow, it's typically no more than a few hundred lines of code because all of the
data plumbers abstracted through the data model.
And so you don't end up, you end up with something
that is actually maintainable
and where the AI has a far higher success rate
of putting something together that actually works.
Then if you have to wire it all up from a bunch of components
and you end up with like 10,000 lines of code
that if you go back to it a month later
and try to change something,
it's gonna quickly get out of hand, et cetera.
So this is really, we really see this
as enabling technology for creating these applications
quickly and efficiently and also safely with AI.
I think it's a great idea.
And so many people talk about AI hallucinations
and AI just creating a bunch of slop and junk.
And I feel a lot of that is because it's not
guided and constrained.
You talked about the guardrails.
And instead of just saying, well, it's like Postgres,
just so make me a database.
You know what I mean?
And it doesn't know about all these really cool features.
the skill comes on, it's like, oh, yeah, you need transcripts, you need audio.
It really can get a much better outcome.
Okay, so the other business thing before we jump into Startup Row is I see two things in your nav.
I see open source and I see pricing.
What's the business model and what's open source and what's pricing?
Yeah, yeah.
How does this work?
So Pixel Table is available as a locally pip installable package, and that is fully open source.
You can just, like I said, pip install it, run it locally.
And we are working on a cloud service where-
so like I said, Pixel Table is a database at its core.
When you install it locally, all the tables are local.
There's also a piece of serving infrastructure.
So you can very quickly, from a table definition,
actually come up, bring up a REST endpoint,
and basically serve the logic and create basically CRUD
applications with it.
But that's all on your local machine.
Or if you want to run it in the cloud,
You have to host it yourself.
And we're soon going to be able to offer a basically cloud hosted tables, basically a cloud service that allow you to do all of that in the cloud, kind of like you think of an RDS or, you know, a snowflake or something like that.
But now for multimodal AI applications.
So that's amazing.
Yeah, exactly.
I think that's a really good solid model.
You know, like a lot of people use these tools, but then they're just not DevOps folks or they don't want to run servers.
You know, they just like, you guys just handle that for us, right?
And that's a perfect synergy without misaligned incentives and stuff.
Let's talk Startup Row.
Why do you guys, why do you apply to it?
Why do you go to this?
Yeah, obviously, you know, PyCon, a very large conference,
draws a, you know, a technical and very interested audience.
And so, and we're obviously part of the Python ecosystem, right?
It was sort of Pixel Table is fully in Python.
And so this was a great opportunity for us to basically, you know, meet a bunch of folks.
And we had a very large number of interesting conversations where people basically came by and said, hey, what is Pixel Table?
And then very often the response was, oh, this is really interesting.
I know either I am working on something related or I know a colleague of mine who was just trying to solve a similar problem, etc.
So there were a lot of really interesting conversations that started that way.
Yeah, that's great.
I, you always hear that people say, oh, you should talk to customers as you're getting
your company up and running and people who are using your product and so on.
And it's one thing to put up a website.
It's another to get people engaged enough to spend some time talking with you.
And especially having that first experience, you know, people who look at your site and
don't make sense of it, just leave.
They don't take the time to talk to you.
But at the booth, people come by and they, they maybe have no idea and you can get these
first impressions.
And so did you learn some interesting stuff talking to people at the show?
Yeah, I mean, there's actually a large number of people who are building applications like this and sort of struggling to put it together.
So there's a fair amount of interest in multimodal AI.
And then also, as I mentioned, everybody's using AI for coding today.
So being AI-friendly, coding agent-friendly is also very important.
Yeah, of course.
So how'd StartupRow go?
You happy you went there?
it's worth your time and yeah yeah absolutely absolutely we had a good uh two days i was there
for two days and so yeah we had a lot of uh good conversations and not all of them i've had the
chance to follow up on yet but uh we will we will do that as well so yeah we're we're hoping we're
hoping it'll um it'll it'll help our business yeah i have a bunch of partnership follow-ups and other
things i want to reach out to people i met at pycon a couple weeks ago and i'm still just digging
backlog of email and work that I got from being away for a week. So it takes some time.
It does.
It does. So tell us about the tech behind this. You mentioned Postgres already. So I guess it's
built kind of on top of Postgres, but tell us about some of the tech that makes Pixel Table go.
Yeah, exactly. So Postgres is a component of the underlying stack. Like I said, we use Postgres
for structured storage and for transactional updates to structured storage or structured data.
And then obviously, because we're dealing with a lot of media data, we also need to maintain files.
There is an execution engine, which basically given a query or an update, like an insert, insert, update, delete, creates a plan, an execution plan.
So it looks very much like a database system on the inside.
So there is a catalog that records the metadata persistently.
We also put that into Postgres and then an execution system that creates a plan for any, like I said, query update statement and then runs through the plan.
And part of it is, like I said, our own asynchronous execution engine.
And then we have a whole bunch of integrations with external API providers like Anthropic, OpenAI, and then also integrations with things like the pill package.
So, like I said, image is a column type and you can now run all the pill image transformations on your image data simply via basically putting that into a query or a computed column.
Right. So you don't have to. And again, the output then is stored back in the right place.
So you don't have to think about intermediate data and where it all lands or how you find it again and so forth.
So we're really tying together an execution system with the storage system and doing it all transactionally.
So it's a full multi-user database and with transactional, you know, isolation, atomicity, semantics and so forth.
Sounds awesome. So where's things going? How long has this been around to start, I guess?
When did you make it public?
We incorporated in April of 24.
Yeah.
So a little over two years.
And we're about to launch the, like I said, service for these cloud hosted tables.
So basically taking a local pixel table.
And then we're also right from the very beginning, it's been very important for us to give you
basically a hybrid experience.
And so it was always the plan that the local SDK would be there.
and there would be a cloud service to complement it.
It was never the idea that there would only be a cloud service, right?
So a lot of, especially data scientists like to work locally,
but we also see that as an advantage now with agentic coding
that agents AI likes to iterate quickly
and doing that locally is quick by definition, right?
You avoid server round trips and all that stuff.
So we're really happy that that's how the setup works.
So, but yeah, so the next step, like I said, in the next few months, we'll have the cloud service up and running.
Oh, excellent.
If somebody is using Postgres today and they think, oh, some of these extra features, like a document column type or image column type or whatever, sounds really great.
What's the process from going from like a regular Postgres setup to yours?
Like, could we use SQLAlchemy to talk to Pixel Table, or do we need a special driver to speak to it?
Yeah, so Pixel Table does not speak SQL.
So, and Pixel Table is also not a, it's a separate database system.
Really, we use Postgres under the covers, but it's not a Postgres layer or anything like that or a plugin.
So you would need to ingest your data from Postgres into Pixel Table.
Right. Kind of a whole two data models in memory at once for a moment and do a migration and then
then just swap or something like that. Yeah, exactly. And then, like I said,
it's not a, we don't have SQL support. It's not meant for analytic applications really. And so
you would be using the pixel table SDK for, you know, to both express the table structure and then
also create your, like I said, there is a very simple way of creating services given table
definitions. Yeah, excellent. Okay, so let's close out this segment by having you just speak to people
who this sounds interesting to. What should they do to get started? Yeah, I mean, my advice is
look in the docs, go to the GitHub page, look through the readme, have install it. We have a,
you know, a quick start guide, and then there's a whole bunch of tutorials. And one of them is
probably going to reflect something that you're interested in, such as, let's say, creating an
index of audio transcripts of your videos, as an example, right? That's something you can actually
do in probably half an hour. And then play around with it. Okay, excellent. Marcel, thank you for
being on the show. And Pixel Table looks like a really cool product. Congratulations. Michael,
thank you for having me again. You bet. Bye-bye. This has been another episode of Talk Python to
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
What if your AI agents worked like FastAPI microservices,
typed, autonomous, and discovering each other at runtime?
That's the world Agent Field is building.
Join them at talkpython.fm/agentfield.
If you or your team needs to learn Python,
we have over 270 hours of beginner and advanced courses
on topics ranging from complete beginners to async code,
Flask, Django, HTMX, and even LLMs.
Best of all, there's no subscription in sight.
Browse the catalog at talkpython.fm.
And if you're not already subscribed to the show on your favorite podcast player,
what are you waiting for?
Just search for Python in your podcast player.
We should be right at the top.
If you enjoyed that geeky rap song, you can download the full track.
The link is actually in your podcast blur show notes.
This is your host, Michael Kennedy.
Thank you so much for listening.
I really appreciate it.
I'll see you next time.
I'm out.