Running a Company with AI: One Founder, Eight Repos, Zero Employees

I run an agtech company called Agrinovo. We make IoT hardware and cloud software for farms. Sensors, controllers, a monitoring platform, a mobile app. Real hardware, deployed in the field across multiple countries. Real customers paying real money.

I have no employees. No co-founder. No engineering team. No marketing department. No office manager. Just me and an AI that knows my entire codebase by heart.

A year ago, this company would have required at minimum a firmware engineer, a backend developer, a frontend developer, someone doing DevOps, and maybe a part-time marketer. Today it requires one person who’s willing to work differently than anyone told him to.

---

The stack nobody believes

When I tell other founders what I maintain, they assume I’m either lying or that the product is a toy. Here’s what’s actually running:

Device firmware in C++ on ESP32 microcontrollers. A Node.js backend handling REST APIs, MQTT telemetry ingestion, auth, permissions, device management, and reporting. A React web dashboard. A React Native mobile app. An internal CRM/ERP system. A business operations layer with three AI-powered Telegram bots. A marketing website. Product datasheets. Eight repositories. All actively developed. All in production.

Most solo technical founders pick a lane. You’re a SaaS person or a hardware person. I do both. I design the physical hardware. The circuit boards, the enclosures, the sensor connectors. I write the firmware that runs on the microcontrollers. And then I write the entire software stack that the hardware talks to. When something goes wrong in the field, it could be a firmware bug, a backend issue, a wiring problem, or literal water damage. I need to be able to diagnose all four, and I usually need to do it remotely because the device is sitting on a farm hundreds of kilometers away. That combination, atoms and bits in one person, is what makes people think I’m lying when I describe what I do.

I don’t maintain these the way a single developer “maintains” a side project, keeping the lights on, fixing critical bugs, ignoring everything else. I’m actively building major features across the full stack. Right now I’m building an entire farm management system with a large fish hatchery as a co-development partner. Batch lifecycle from spawning to harvest. Split and merge operations for moving fish between containers. Feeding schedules, water quality monitoring, inventory, financials, multi-language worker interfaces. I won this contract against an established competitor. They had a team. I had a better product conversation and a faster iteration cycle.

How AI pair programming actually feels

Here’s what nobody tells you about pair programming with AI every day for a year: it stops feeling like a tool pretty fast.

I don’t prompt-engineer. I don’t carefully craft instructions. I open a session and say something like “the pH sensor on device X is returning zero bytes, the lux sensors died two days before it, look at the RS485 bus code.” And the AI already knows that all RS485 sensors share one physical port, that duplicate Modbus addresses cause bus collisions that return exactly zero bytes (not garbled data, nothing, because the differential signals cancel), and that this specific device runs three sensors in always-awake mode. It knows because we’ve been through this before, and it remembers.

I maintain a set of memory files that persist across sessions. Not chat history. Structured institutional knowledge. What decisions we made and why. What patterns each repo follows. What mistakes bit us. What the customer actually needs versus what sounds cool. When I start a new session, the AI doesn’t start from zero. It starts from context. And context is everything.

Adding a new sensor type? That change touches firmware, backend, web frontend, potentially the mobile app, potentially the datasheets. Five repos. The AI holds the implementation details of all five while I hold the intent. I know what I want to build. It knows where every wire connects. When I change a data format in the firmware, it flags that the backend ingestion handler expects the old shape. When I add a field to an API response, it reminds me the web dashboard destructures that response in three different components. No human teammate could hold all of that simultaneously across eight repos. I certainly can’t.

But here’s the thing that matters: the AI amplifies whatever you bring to the session. Bring a clear spec, get a focused implementation. Bring a vague idea and hope for the best, get an impressive-looking prototype that falls apart the moment you try to use it for real.

I know because I’ve done both.

The graveyard: what happens when you vibe-code a business

About a year ago I tried to build an internal CRM. I didn’t have a clear plan. I figured I’d let the AI generate a frontend and I’d steer it into shape as we go. Vibe coding, people call it now.

It went nowhere. I abandoned it.

Months later I started over. This time with a proper data layer, a production database, clear API boundaries, and a focused scope. The replacement is now live in production, handling all customer data, products, inventory, and CRM features. It works because I knew what I wanted before I started building it.

The failed version taught me the most important thing about working with AI: it doesn’t save you from yourself. Before AI, a half-baked idea would sit in a planning document and die quietly. Now, a half-baked idea becomes 2,000 lines of code in an afternoon, and by the time you realize the foundation is wrong, you’re emotionally invested. I spent an entire session not long ago deleting database models I’d built months earlier. Models that were never used, never needed, born from “could be cool to have” energy rather than an actual customer requirement. Every one of them was generated with AI. Every one of them was my fault.

The discipline tax of working with AI is real. You can build faster than you can think, and that’s dangerous if you let it happen.

Running business operations with AI agents

I built three AI agents that run parts of my business through Telegram. Katie handles business operations: CRM lookups, opportunity management, customer communications, invoicing coordination. Jackson manages inventory. Mason does financial analysis, parses bank statements, reconciles transactions.

These agents talk to the production database. They interact with real financial APIs. They send real messages to real people. Their mistakes cost real time and real money.

And they made mistakes. Early on, Katie invented a deal value when I hadn’t specified one. Just made up a number. She created duplicate records because she didn’t check if something already existed before creating it. Once, when she couldn’t figure out how to delete a record, she marked the opportunity as “closed-lost” instead of just asking me. Wrong currency on deals with international customers.

Each failure became a rule. Never make up numbers, ask. Always check before creating. Take minimal actions only. If you don’t have the right tool, stop and ask, don’t improvise with the wrong one. Be currency-aware by default.

Running AI agents in production taught me that the deployment isn’t the hard part. The behavioral constraints are. You don’t ship code without tests. You don’t deploy agents without guardrails. And the guardrails only come from failure. You can’t anticipate every way an agent will surprise you. You have to let it surprise you, then make sure it never does that specific thing again.

2 AM debugging in a fish pond

The firmware side is where “solo founder” stops being romantic and starts being just you, alone, at night, staring at serial logs.

Our devices run on battery power with deep sleep cycles and cellular connectivity. When a device goes dark on a customer’s farm, there’s no night shift to dispatch. There’s me.

I once spent days tracing a progressive sensor failure on a device running at a customer’s farm. Two lux sensors failed first. Readings converging in a pattern that looked like they’d been physically pulled from the water. Two days later the pH sensor went. Then the entire RS485 bus went dead. Zero bytes from everything.

I was certain it was a firmware bug. I went through every code path. The AI held the entire sensor architecture in context while I narrowed down possibilities: which GPIO pins share buses, which Modbus registers are adjacent, which firmware version was running, whether any recent OTA update could have caused a regression. We ruled out firmware. The pattern pointed to progressive corrosion in the field wiring. Water ingress killing sensors one by one as it crept along the cable.

Not glamorous. Not a tweet-worthy AI success story. Just the reality of shipping hardware: sometimes the bug is water in a wire, and the only way to know is to eliminate everything else first.

We did find and fix a real firmware issue during that investigation, though. A fallback mechanism that tried alternative sensor addresses during failures, which under certain conditions could cause cross-sensor collisions on the bus. The kind of subtle bug you only find when you’re already deep in the code for another reason.

SEO as the entire business

Agrinovo has never spent a dollar on advertising. Every single customer found us through Google.

I built a CLI tool that connects to Google Search Console, analyzes our rankings and click-through rates, and helps me make data-driven decisions about content. The marketing website is bilingual. Full English and Hebrew versions of every product page, kept semantically aligned. Writing technical content in two languages, optimized for search intent in both, is the kind of work that would normally require a content team. I do it in a session.

But I’m terrified of my own SEO rankings in a way that’s probably not healthy. There is nothing that scares me more than accidentally damaging the website’s search performance. One careless content change can undo months of ranking progress. I review every change to the site manually. The AI proposes, I approve. No exceptions.

That fear is rational, though. Organic search is the only growth channel. If it breaks, the pipeline breaks.

Omniot is dead, long live Agrinovo

Halfway through all of this, I renamed the company. Omniot became Agrinovo. Not a minor thing. It meant updating the brand across the marketing site, product documentation, customer-facing materials, datasheets, email signatures, legal documents, and every place the old name appeared in code comments and config files. Most companies hire a branding agency and a project manager for a rebrand. I did it in sessions with the AI over a few weeks, while simultaneously shipping features and supporting customers who didn’t know or care that the name was changing.

The rebrand wasn’t vanity. The old name didn’t communicate what we actually do. Agrinovo says agriculture and innovation in two syllables. It positions the company where it needs to be. But doing a rebrand solo, while keeping everything else running, while making sure SEO rankings transfer cleanly to the new domain. That’s the kind of thing that makes you question your life choices at 1 AM while updating a datasheet header for the fourth time.

Four languages, five time zones

Here’s something people don’t expect about an Israeli agtech company: my world operates in Hebrew, English, Arabic, and Thai.

The marketing site is fully bilingual. English and Hebrew, every page, kept in sync. The platform UI supports Arabic and full right-to-left layout because that’s what part of the workforce speaks. The farm management system I’m building now needs worker interfaces in Thai, Hebrew, and English, because the hatchery employs Thai workers alongside Israeli staff. Customer inquiries come in from the UK, Cambodia, China, and across the Middle East. I’ve had weeks where I wrote marketing copy in English, fixed an RTL layout bug in Arabic, answered a customer email in Hebrew, and specced a UI that needs to work for someone who reads none of those languages.

No localization team. No translators on retainer. Just me, the AI, and the reality that agriculture is a global industry even when your company is run from a desk in Israel.

What I actually think about at night

It’s not the code. The code is the easy part now.

It’s the loneliness.

I carry two phones with two WhatsApp numbers. One is “me,” the founder. The other is the company’s support line. Both are me. When a customer messages support, I answer as if there’s a team behind the number. When they escalate to “the founder,” I switch phones. Same person, different pocket. Nobody asks who “we” is because the performance is convincing enough. But performing a company by yourself, day after day, is exhausting in a way that has nothing to do with the code.

I don’t have anyone to argue architecture decisions with over coffee. When I realize at midnight that sensor data I’ve been collecting for months has a provenance problem because of a design choice I made casually, there’s no CTO to share that sinking feeling with. The AI will tell me it’s bad if I ask honestly. But it won’t catch me in the hallway and say “hey, have you thought about how this is going to bite us in six months?” That kind of ambient peripheral vision is a human thing. I don’t have it.

And then there are the wins. You close a contract against a competitor who has a full team. You ship a feature that works perfectly on the first deploy. A customer sends a message saying the product saved them hours every week. And you just… close the laptop. There’s no team Slack channel lighting up. No one to high-five. The AI will say “that’s great” if you tell it, but it doesn’t know what it cost you to get there. The good moments are just as solitary as the bad ones.

Every morning I wake up and choose between a firmware bug, a feature deadline, an SEO opportunity, an invoice that needs sending, and a customer email that’s been sitting for a day too long. There’s no one to delegate to. The AI helps me execute any of those tasks faster. But the decision of which one matters most today, that weight is entirely mine, every single day, with no one to absorb any of it.

And the speed creates its own trap. AI makes you feel productive. Commits are flowing, features are shipping, the dashboard looks great. But productivity and progress aren’t the same thing. I stop myself periodically and ask: am I building what needs to be built, or am I building what’s easy and satisfying to build? The AI will happily help me do either. The discipline to choose correctly is entirely mine.

My worst anti-pattern, and I know it now, is starting things without finishing them. I’m an idea person by nature. Before AI, that meant a folder of half-written specs. Now it means abandoned code, partially built features, database tables that serve no purpose. AI turbocharges your strengths and your weaknesses equally. My strength is product vision. My weakness is wandering off before the last 20% is done. I’ve had to build systems to keep myself honest. Structured specs before any code, committed deadlines with real customers, and an AI collaborator that I’ve explicitly instructed to push back when I’m starting something new instead of finishing something old.

The traits a solo AI-first founder actually needs

None of this is natural talent. These are survival adaptations. Things I had to develop because without a team, there’s no safety net for self-delusion.

Brutal self-honesty. I called my own database models “garbage” during a cleanup session. Out loud, to an AI, at midnight. Models I’d spent real time building. They were never used, never needed, born from excitement rather than customer demand. If you can’t look at your own work and say “this is bad and I need to delete it,” you will drown in your own output. A team has code reviews and architecture meetings to catch bad ideas. Solo, you have to be your own harshest critic, and you have to actually act on it. Not just acknowledge the problem and move on.

Knowing when to stop building. This is the hardest one. I have a parked folder full of fully written specs that I’m deliberately not executing. Features that would be genuinely useful. Integrations that customers would like. I wrote the specs, validated the ideas, and then told myself: not now. Because the contract has a deadline, and shipping that on time matters more than having twelve half-finished features. Ideas are cheap. Finishing is expensive. I park aggressively.

Protectiveness over what already works. I don’t touch production systems that are running fine just because I had a clever idea for how they could be better. I have a produce tracking module that runs once a year during harvest season. It looks dead eleven months out of twelve. I leave it alone. I have SEO rankings that took months to build. I don’t experiment with them. The instinct to improve things is strong, especially when you have an AI that can implement any change in twenty minutes. Learning to resist that instinct, to protect earned progress, is a skill I developed out of fear, not wisdom.

Thinking in customer outcomes, not features. When I won that contract against an established competitor, it wasn’t because I had better technology. It was because I listened to what they actually do every day and designed around their workflow instead of around my assumptions. Every feature I build starts with “what does the person on the farm actually need at 6 AM?” not “what would be architecturally elegant?”

I didn’t develop these traits because I’m disciplined by nature. I developed them because the alternative was bankruptcy.

Why I still haven’t hired

I could. I choose not to, not because solo is inherently better, but because hiring solves one problem and creates ten others. Recruiting, onboarding, managing, aligning, communicating context, reviewing work, maintaining culture. For a company at my stage, those costs are real and they’d slow me down.

The moment I’m dropping balls that matter, the moment customer deadlines slip or quality degrades because the surface area genuinely exceeds what one person plus AI can handle, I’ll hire. But that moment hasn’t come yet. And every month, the AI gets better, and the threshold moves further out.

I’m not making a philosophical argument. I’m making a practical one. Right now, today, in 2026, one person with the right tools and the right discipline can build and operate a real technology company that would have required a team of eight two years ago. That’s not a prediction. That’s my Tuesday.