I run a software company with 30 engineers. I built this app with AI and none of them.

I run a software company. We have around 30 engineers, designers, and QA people. We build products — some for clients, some our own. B2B tools, internal platforms, that kind of thing. It's been going for over a decade.

When AI coding tools got to the point where you could describe a feature in plain English and get working code back — not autocomplete, actual working features — I couldn't stop thinking about two things.

One was practical: our clients are going to start asking why they need a team of five when this exists. We need to figure that out before they do.

The other was personal. I haven't written production code in years. I run the company, I make product decisions, I review architecture — but I don't ship code. Could I build a real app with just an AI? Not a prototype. A real thing, in the App Store, with actual users.

I wanted to know. So I tried.

The idea

I needed something I actually wanted. Not a to-do app, not a SaaS dashboard — something I'd use every day.

Here's my thing: I'm obsessed with football. Not watching-on-TV obsessed. Going-to-matches obsessed. I travel for games. I collect stadiums the way some people collect countries — it is called groundhopping, and it is more addictive than it sounds. I've been to grounds across Europe — big cathedrals and tiny non-league fields with 200 people and a burger van.

For years, I tracked it all in Apple Notes. A messy list: "Anfield, March 2019. Craven Cottage, August 2021." No stats, no map, no way to see the full picture.

There are apps for this. I tried them. One charges you a subscription to log matches you already paid to attend. Another looks like it was designed in 2012 and never updated. A third has 90,000 stadiums in its database — most of which don't exist.

So the project chose itself: a football match tracker. Log every match you've been to. Map every stadium on a world map. Track your stats. Think Strava, but for football fans. I called it Footbeen.

Week 1: "This might actually work"

I started with Claude. Not a team of AI tools — just one. I described what I wanted in plain language, the way I'd brief a senior developer.

The first day was weird. By evening, I had a working app with authentication, a database schema, and a home screen with a map. Ugly as hell, but it ran.

By the end of week one, I had:

User accounts with Google and Apple sign-in
A Supabase database with leagues, clubs, stadiums, and matches
A searchable match catalogue (pull data from an API, let users find any match since 2010)
A map that lights up stadiums you've visited
Basic stats: matches attended, stadiums visited, countries

In a normal project at my company, week one is when we're still arguing about the database schema in Confluence. I'm not even exaggerating — I checked our Jira history.

Week 2-3: The ugly middle

This is where the honeymoon ended.

AI is brilliant at generating code. It's terrible at making decisions. Every time I gave a vague prompt — "make the add-match flow better" — I got technically correct code that was productionally wrong. Features that worked but felt off. Screens that had every element but no soul.

Here's what I figured out the painful way: AI is a 10x executor with zero product sense.

It doesn't know that a modal should close and return you to the tab you were on, not dump you on the home screen. It doesn't know that showing a skeleton loader for 8 seconds is worse than showing an error after 3. It doesn't know that fans care about win rate but not about "average goals per match to two decimal places."

I had to catch every single one of these, work out why it felt wrong, and re-prompt until it didn't. You don't need to know how to code. You need to know what good looks like.

Other things that went wrong:

The "works on my machine" problem. AI-generated code worked in development but crashed in production. A background sync that was fine with 10 matches would OOM with 500.
State management chaos. The AI would add a useState after an early return in a React component. React silently breaks. No error, no crash — the button just stops working. I spent an entire day on this before figuring out the pattern.
The database grew teeth. Started with 4 tables. Now it's 30+. Every time I added a feature, the data model got more complex, and the AI would sometimes write queries that were technically correct but would take 40 seconds on the real dataset. Technically correct is the worst kind of correct when your user is staring at a spinner.

Week 4-5: It gets good

After a few weeks of figuring out how to prompt properly — be specific, set constraints, always read what it gives you before accepting — things clicked. And then the speed got ridiculous.

One Thursday, I decided I wanted a "Travel Planner" feature: pick a city and dates, see every upcoming match within 100km. In my company, this would be a 2-week sprint: spec, design, frontend, backend, QA, deploy.

I shipped it in a day. Fully working, with a search UI, geolocation queries, match cards, and mobile-responsive design. Deployed to production before dinner. My wife asked what I did at work today. "Built a travel planner." "The whole thing?" "The whole thing."

That's when it stopped feeling like an experiment.

Here's what the velocity looked like:

What	Traditional estimate	AI + me
Match logging with search	2 weeks	3 days
Interactive stadium map (Mapbox)	1 week	1 day
Travel Planner tool	2 weeks	1 day
SEO website with 650+ pages	1 month	4 days
Multilingual landing pages (7 languages)	2 weeks	3 hours
CI/CD pipeline + 600 tests	1 week	2 days

I want to be clear: these aren't proof-of-concept demos. This is production code serving real users, with error handling, edge cases, monitoring, and all the boring plumbing that separates a demo from a product.

The numbers (8 weeks in)

As of today:

25,000+ stadiums in the database
1,300+ leagues across 200+ countries
1,000,000+ fixtures going back to 2010
iOS + Android + Web — all from one codebase
650+ SEO pages — club pages, stadium pages, league pages, country hubs, blog
7 language versions of the landing page
600+ automated tests in CI
Sentry monitoring, crash-free rate >99%
$0 spent on developers, designers, or QA

The app is called Footbeen. It's free — everything that competitors charge for, you get for nothing. That's the upside of building with AI and no team: when your costs are near zero, you can afford to be generous. I built it to solve my own problem. Maybe I've solved yours too.

footbeen.com

The honest part

I don't want this to read like an AI hype piece. It isn't one. There were nights — plural — where the app was crashing on every launch after an update, and I had no idea why, and I couldn't just walk over to a developer's desk and say "hey, can you look at this." It was just me and a chat window. At 2am, after four hours of going in circles with the same bug, you start questioning the whole experiment.

AI can't tell you what to build. It will build whatever you describe, brilliantly, whether it's a good idea or not. It's the most agreeable colleague you've ever had — and that's a problem. A good senior dev says "that's a bad idea." AI says "sure, here's the code."

It generates UIs that work but don't feel right. It writes queries that are technically correct but take 40 seconds on real data. It confidently produces code that passes every test and then breaks in production on a slow connection. You spend just as much time catching its mistakes as you save by not writing code yourself.

The difference is: those are the right problems to have. I'd rather spend my time on "does this feel right?" than on "how do I centre this div?"

What this means for my company

I built a production app in 8 weeks with zero headcount. It has more features and better test coverage than most projects my full team delivers. I don't know what to do with that information yet.

We've always built two kinds of things: client projects and our own products. Our own stuff has always been B2B — tools, platforms, enterprise things. Footbeen is the first consumer product I've personally driven, and it happened by accident. The experiment grew legs.

Our clients are already asking: "If AI can do this, why do I need a team of five?" They should be asking that. We're experimenting with a new model: one senior person who deeply knows the domain, plus AI. Instead of five people who kind of know the domain and write code by committee.

Writing CRUD endpoints isn't a career anymore. But knowing what to build, and more importantly what not to build — that's worth more than ever.

The part I didn't expect: this side project took over my brain. I use it every matchday now. I'm adding features because I want them as a fan, not because a roadmap told me to. One of the early users logged 200 stadiums in his first week — turns out he'd been keeping a list in a spreadsheet for years, just like I was doing in Notes. I haven't felt this connected to a product in a long time.

So

I started this to answer a question about my company. I ended up with a product I actually care about, a hobby that now has an app, and a pretty different view of what software teams should look like in 2026.

If you run a company and you're wondering what AI means for your team — try building something with it. Not a demo. Something real, something you'd use yourself. You'll learn more in a week than from any conference talk.

And if you're someone who knows a lot about something — football, cooking, cycling, birdwatching, whatever — and you've always wished there was a better app for it: the gap between "I wish" and "it exists" just got very small.

I've got a match this weekend. And for the first time, I won't be logging it in Apple Notes.

Footbeen is free on iOS and Android. If you've ever kept a list of stadiums you've visited — in a notes app, a spreadsheet, or your head — give it a try. I'd genuinely love to hear what you think.

Stack for the curious: React Native (Expo), Supabase (Postgres + Auth), Mapbox, React Query, Vercel + EAS. Questions about the AI workflow or the product — [email protected].