Welcome to our Featured Founder series, where you’ll meet startup founders from Tampa-St. Petersburg who are building and scaling their ventures to solve some of the world’s greatest challenges. We interviewed Andrew Montalenti of PX, a daily developer tool that helps backend engineers go from working code on a laptop to deployed code in a freshly-built cloud cluster — all within seconds.

Please provide a brief one-liner about your company.

PX is a daily developer tool that helps backend engineers go from working code on a laptop to deployed code in a freshly-built cloud cluster — all within seconds.
Developers can learn more from my deep-dive launch blog post, from the PX website, or from the developer quick start guide.

What were you doing previously, and what inspired you to launch your company?

Prior to PX, I was the founding CTO of Parse.ly. PX stems from my experience as a startup CTO who eventually ran large distributed systems on Amazon Web Services and Google Cloud Platform.

PX is cloud independent, programming language agnostic, and open source friendly. PX is, in short, the tool that I always wished my teams could have. The launch blog post covers some of the history and inspiration.

What pain point is your company solving? What gets you excited to go to work every day?

When I was a CTO at Parse.ly, I was working on an enterprise SaaS web analytics product for large media companies and high-traffic websites. Thus, I led a 30+ person engineering team, which included frontend developers/designers, cloud DevOps + InfraOps engineers, backend analytics engineers, and machine learning engineers.

We solved an important problem – providing real-time web content analytics – for our enterprise SaaS users.

But under the hood, what really allowed the company to grow and scale was how efficient we were with cloud resources – mainly AWS. And to what degree we were able to wield our cloud resources and our open source software stack to solve customer problems. I wrote a little bit about this in my blog post, “Shipping the Second System.”

As part of working on the Parse.ly problem for over a decade with talented engineers as colleagues, I started to become more attuned to the problems of my own fellow professional software developers. And I realized software companies and tech startups could solve many core problems of software developers, as well!

For example, we faced cloud observability problems, and solved those with tooling like Datadog (now a public company). We faced cloud provisioning problems, and solved that with tooling like Terraform (developed by Hashicorp, now owned by IBM). We faced cluster analytics problems, and solved those with tooling like PySpark and Spark (developed by Databricks, now one of the largest private tech companies). And, of course, many problems were solved directly by our public cloud providers, like Amazon Web Services (e.g. Amazon S3 for reliable data storage) and Google Cloud Platform (e.g. Google BigQuery for rapid petabyte-scale SQL analytics over data).

However, something I noticed is that more and more of my backend engineers’ time was spent on complexity spirals created by the public clouds themselves. Thus, it was in backend engineering where we had the most specialization, gatekeeping, and friction in shipping new releases everyday. I noticed that the teams that moved quickest were those that could get into a solid “build – debug – test – ship” loop with their software, and often that wasn’t the case on the backend team.

Once my startup was acquired by a larger tech company, Automattic, the creators of WordPress.com, with a staff of 1,500+, I came to realize that this wasn’t unique to my startup. Companies large and small – startups, mid-market tech companies, and F1000 companies – were all struggling with complexity spirals in backend engineering, especially related to the gap between working code on a developer’s laptop and a deployed and working system in cloud clusters.

Once I left Automattic in 2023 – I wrote a reflection on the Automattic acquisition here – I started thinking about solving this issue at the root.

That led to some whitepapers and research in 2023-2024, and a working prototype in 2025. I joined Embarc in February 2024, and that corresponded with the period of solo work (Feb ‘24 to Feb ‘25) that got my prototype over the hump from napkin idea to demo’able and working.

Then in July ‘25 I hired a former colleague, Nelson Monserrate, to take my prototype and turn it into a real product, which we now refer to as the “PX command-line interface,” or “the PX CLI.” This is the developer tool covered in our quick start guide.

And then in October ‘25, I hired a former colleague, Cody Hiar, who has been working on the early versions of our PX Dashboard, our paid SaaS offering for developers, which provides real-time debugging, cluster visibility, and cost controls. This rounds out the developer experience described on the PX website.

Finally, in December, we came out of stealth and made PX available publicly.

It’s enjoyable to work on a pain point that I personally felt and that my fellow engineers in my own industry immediately identify with in their own work. It’s fun to “be your own user” and apply my “startup founder brain” to my own industry of software development and cloud engineering.

Name the biggest challenge you faced in the process of launching the company. How did you overcome it?

Since this is startup #2 for me, there were several challenges at the early stage.

The biggest one: I was “retraining my brain” to think like an early-stage startup founder again.

The last time I did that was when Parse.ly was itself a pre-seed company, way back in 2009-2010. The entire work of software, SaaS, cloud, and open source has obviously completely changed, many times over, since then.

Since I was CTO of Parse.ly from 2010-2021, all the changes in the industry were incorporated into my own work in a “stage-appropriate” way. For example, by the time we were acquired in 2021, I was a “lead of leads” – I was leading engineering managers and product managers who were themselves managing engineers, since our engineering team was 30+ people. We had a multi-million dollar cloud budget, 500+ enterprise customers, a 24×7 on-call rotation, and my co-founder, Sachin, himself led a 40+ sales & marketing & finance/ops team with many moving parts. We also had a board we regularly reported to that included our lead investors.

That sort of structure is the complete opposite of an early-stage startup. If you contrast it to, say, February 2024, where I was literally just working, alone, on a software prototype, with no investors, no users, no colleagues.

Some of the things I did to get back into the startup mindset included: virtually attending YCombinator Startup School; re-reading Founders at Work; meeting weekly on Fridays over Zoom with a good friend who was also a programmer so I could show him my early builds of my prototype and get real feedback; showing progress periodically to folks inside Embarc Collective to get their feedback.

That culminated in a presentation I gave at Embarc in October 2024, at their “Tech Jam,” where I showed an early version of PX to a room full of engineers and CTOs, and I realized I was on the right track. Co-motivation and peer feedback is powerful.

Where do you see your company headed next?

We only just came out of stealth last week and we’re still processing feedback from people who are taking a look at PX and participating in the private beta. I’m also getting some great outreach from folks on LinkedIn who I either used to work with or met in all my travels in the tech industry, especially due to my deep roots in the Python community.

I suspect that’ll continue for a few months as we iterate on real user feedback.

We have a lot of exciting plans I’ll share in the future, but for now, we’re just excited to learn from users!

Give us a tactical piece of advice that you’d share with another founder just starting out.

A few years back, I wrote a blog post called “Why Startups Die.” I still re-read it from time to time and I think the advice I gave back then is still very valuable to a first-time founder just starting out with their business. So I’d suggest checking that post out!

Here’s the concluding quote: “To survive, you must continue moving forward. I don’t think startups win because they have smarter staff, better ideas, or a clearer understanding of market trends. Surely, those things help, but they aren’t the main thing. The way to win is to keep playing.”

Why Florida?

I have been a leader of fully distributed engineering teams since long before the Covid-19 pandemic.

I gave a talk about our fully distributed engineering team at Parse.ly at a conference in NYC for startup CTOs, which was called “CTO Summit,” in December, 2018. The slides can be found here.

For Parse.ly’s lifetime, I led the team from Astoria, Queens, NY; Charlottesville, VA (I was based in central Virginia for 8 years!); and Long Island City, Queens, NY.

In Parse.ly’s post-acquisition period, I moved down to Tampa, FL with my wife and dog and worked remotely for Automattic, who were, themselves, a fully distributed team since long before the pandemic.

So I’ve basically worked remotely – and hired engineers remotely – my entire career. I plan to continue the practice.

My colleagues at PX may be based in different geographies and timezones than me, but we coordinate online over GitHub, Notion, Google Meet, and other collaboration tools.

I’ve been based in Tampa, FL since 2021. The fully distributed team model truly has scaled impressively and become more pervasive over time.

And Tampa has continued to impress me with its deep sense of community, its small-but-burgeoning tech scene, and its growing tech startup ecosystem. And it’s also a great city to take your mind off tech from time to time. For example, I like to get out on the bay with friends who are into sailing and I enjoy taking hikes in nearby parks with my dogs. This sort of thing is needed to get the wider perspective that comes from giving your brain an occasional break from your startup problem.

From the standpoint of developing an early-stage startup, the most important thing I’ve learned about myself over time is that I need face-to-face serendipitous collision points with other founders and engineers to spark my own internal creative kindling. Tampa – and especially the startup hub of Embarc Collective – does that for me in spades. So I’m excited to continue to build PX while staying based here in Tampa