Who Is Mendoza and Why Is Everyone Talking About Him Now
Mendoza launched a logistics software company out of a shared warehouse space in Buenos Aires roughly eight years ago. It was one of many startups that popped up during the regional tech boom, and honestly, most of them failed within the first three years. What happened with his company is not dramatically different from the ones that didn't survive, but the survival itself is worth looking at because it challenges a few assumptions about how these companies are supposed to scale. The core product was a middleware layer for freight forwarding. Nothing flashy. It connected legacy ERP systems in South American ports to modern API-driven inventory platforms. Most engineers would look at that problem and build something complicated. Mendoza built something deliberately simple. That decision shaped everything that followed. I worked alongside a few engineers who were early hires there. What I noticed was not some visionary master plan. It was a series of unglamorous choices made under real constraints. The team had about twelve people total when they raised their seed round. They could not afford to hire senior infrastructure engineers. So they stopped trying to build custom orchestration tools and instead glued together open-source components — Kubernetes on bare metal, Terraform for provisioning, and a self-hosted monitoring stack. It is not what you see on conference slides. It worked. Deployment times averaged around forty-five minutes for a full environment refresh. Not fast, but stable enough that incidents stayed below two per quarter.
One counter-intuitive thing that people miss: Mendoza refused to hire a sales team until the company had seventeen paying customers. He did direct outreach himself. He set up meetings. He learned what customers were actually trying to do before anyone else on the payroll understood the product well enough to pitch it. The reason this matters is that most startups hire sales too early, which means the product gets shaped by what salespeople think will close deals rather than what the technical architecture actually supports. Mendoza's customer base in year two was concentrated in three countries. Three. That let him focus integrations on the specific customs and tax compliance APIs used in those markets instead of building a generic worldwide solution. Generic worldwide solutions are expensive to maintain and slow to deliver value. Here is an edge case I ran into that nobody writes about in these profiles. Around the fifteenth customer, we hit a hard limit with our multi-tenant data isolation approach. We were using a single PostgreSQL instance with row-level security policies. It handled fine until a major logistics operator required audit trails that spanned six months of transaction history across multiple tenants. The RLS queries started degrading to the point where response times climbed past three seconds on heavy report loads. I spent about a week benchmarking alternatives and ended up splitting that particular client onto a separate schema within the same database cluster, which kept costs down while isolating the performance hit. Moving to a fully separate database per tenant would have solved it cleanly but increased monthly infrastructure spend by roughly sixty percent. The schema split was ugly but functional, and we documented the workaround so the next engineer would not spend a week on the same problem. Another insight that beginners usually get wrong: Mendoza's company did not chase venture-scale growth metrics for the first five years. Revenue growth was around thirty percent year over year, which looks modest if you are comparing it to companies that double annually. But the gross margin settled at about seventy-two percent, and the churn rate stayed below five percent annually. That combination meant the company was profitable on an EBITDA basis by year four. Profitable companies make different decisions than cash-burning ones. They do not take rounds at inflated valuations. They do not lay off people when growth stalls. They compound quietly.
There are clear downsides to this approach, and I am not going to pretend they do not exist. The slow growth model means fewer eyes on the product. Fewer users testing edge cases. Fewer feature requests coming through. It also means Mendoza had less capital to invest in hiring top-tier security engineers, so the company relied heavily on third-party penetration testing firms twice a year rather than maintaining an in-house security team. That is a real vulnerability. If you are operating in logistics where clients handle sensitive supply chain data, a single breach could damage relationships built over years. The company has addressed this more recently by moving toward SOC 2 Type II compliance and adding a dedicated security contractor, but it took until year six to get there. Marketing was another blind spot. Mendoza did not build a content engine. There are no podcasts, no viral LinkedIn posts, no keynote speeches at major conferences. The company grew almost entirely through referrals and long sales cycles with mid-market logistics operators. That is a fragile growth model in a downturn. When credit tightened in certain regions, those mid-market buyers delayed purchases, and the referral pipeline slowed considerably. The company survived because the revenue base was diversified enough and margins were healthy, but it was still uncomfortable. I would recommend any founder studying this path to build at least a lightweight inbound mechanism — a technical blog, a GitHub presence, something — even if it is just one article per month. It acts as a hedge. The product roadmap is another area where the Mendoza approach shows its limits. Because the company avoided over-hiring, feature development moved at a pace that frustrated some early customers who wanted niche capabilities. The trade-off was stability and reliability, which most customers valued once they were past the initial integration phase. But it created a tension that never fully resolved. Newer competitors with larger teams ship features faster, even if those features come with more bugs. That is the fundamental choice: velocity versus durability. Mendoza chose durability, and the market rewarded him for it, but only because his market segment — established logistics firms — prioritized uptime over novelty.
Get the Full Details
If you want to replicate any part of this, the hardest element to copy is not the technology. It is the founder's temperament. Mendoza is patient in a way that frustrates investors and accelerates employees alike. He makes decisions based on three-to-five-year horizons in an industry obsessed with quarterly results. That does not work for everyone. If you are running a company where speed to market is the primary competitive advantage, this model will slow you down. It is not universally applicable. It is a specific strategy for a specific type of business in a specific market segment. What is useful to extract from the story is the discipline around unit economics. Every hire was justified by revenue per employee exceeding a threshold that Mendoza set himself. The company tracked that metric religiously. When it dipped below a certain level, hiring froze until the ratio improved. Most startups ignore this because raising the next round feels easier than tightening the belt. Mendoza's willingness to stay small forced the engineering team to build efficient systems rather than throwing computing power and headcount at problems. That efficiency carried through to the product, which remained lightweight enough to deploy on modest infrastructure without sacrificing functionality. The pricing strategy is also worth examining. The company moved away from per-seat licensing early on and adopted a usage-based model tied to shipment volume processed. This aligned the company's revenue directly with customer success. When a customer shipped more, Mendoza's company made more. It sounded generous, but it also meant the company had a strong incentive to help customers optimize their operations rather than lock them into expensive contracts. Customers who felt they were being nickel-and-dimed churned quickly, and the usage-based model surfaced that friction faster than any traditional contract would have. The net result was a customer base that was more committed and less likely to leave for a cheaper competitor, because the cost structure adapted to their actual usage patterns.
I do not have access to Mendoza's personal financial details or internal board discussions, and I am not going to speculate about those. What I can say is that the operational patterns I observed and experienced first-hand are unusually coherent for a company of its size. Coherence like that does not happen by accident. It happens because someone with authority makes unpopular decisions and sticks to them. That is the real story here, not any dramatic breakthrough or industry-disrupting innovation. Just a lot of boring, correct choices made consistently over several years.
