Three weeks ago this event manager calls me. She's standing in some convention center hallway and I can hear all these people talking in the background, you know that echo you get in those big spaces? And she's like, our app just crashed, we've got 1,800 people trying to check in, my developer is literally on the phone with ChatGPT right now trying to figure out what's wrong with the database.
And I'm thinking, oh no, here we go again.
So look, I run Eventify. We've been doing this for 13 years, we handle events with 100k+ people showing up at the same time. And I'm not anti-AI or anything - our team uses all these tools. GitHub Copilot, Cursor, Claude, whatever. But there's this thing that keeps happening where people think "oh I can just prompt ChatGPT and build an event app" and then... it doesn't work out great.
I've seen this maybe five or six times now just in the last year or so. Same pattern every time.
How It Usually Starts
Usually someone on the team has been playing around with these AI coding tools. They built something - maybe a landing page, maybe some internal tool - and it worked pretty well. Didn't take that long. So they're thinking, why are we paying however much for this event platform when I could just build one?
And from the outside, I get why it seems simple. You look at an event app and it's like... registration, check-in, agenda, some QR codes. How complicated can that be, right?
The Thing About Testing vs Real Events
So they build something. Takes longer than they thought - instead of a few weeks it's more like 3 or 4 months - but they get it working. Test it with the team in the office, 10 people scanning QR codes, checking in, everything looks good.
Then they try it at a small event. Maybe 150 people. And it mostly works but there are these weird issues. QR codes won't scan near the windows. Check-ins are slower than they should be. Someone's badge photo didn't upload. The whole thing looks kind of broken on iPads.
But they figure it's version 1, they'll fix it. Developer takes screenshots of the errors, pastes them into ChatGPT, makes some changes. Seems better.
Then they use it at an actual event. Like 1,500 people.
8:42 in the morning, everything's fine. A few early people, check-in's working okay.
8:47, the doors open for real. 200 people walk in. Then 400. Then 800. All at once.
8:51, the app just stops. Check-in screens are frozen. QR scanner won't even focus. People are just standing there holding their phones and nothing's happening.
8:54, they're on the phone with the developer who's frantically looking at error messages. "Database connection timeout" keeps showing up. They copy it into ChatGPT. The suggestions don't help because ChatGPT doesn't know they're using MariaDB 10.6 with whatever specific setup they have. It probably suggests increasing max_connections which actually makes things worse because now you just have more connections timing out.
By like 9:08 they give up and do manual check-in with paper lists. 1,500 people, back to basics, everyone's annoyed. The exhibitors missed the whole first hour when people actually show up. Client's furious.
You know that smell in convention centers? That weird mix of bad coffee and whatever they use to clean the carpets? That's what I remember from when we had our first big crash back in 2016. I was just standing in this hallway staring at my phone watching errors come in, and all I could hear was like 500 people shuffling their feet and muttering and checking their watches.
The Load Problem
Most apps don't work like events. Normal apps, people log in throughout the day. Traffic builds up gradually. You can scale into it.
Events are different. The doors open at 8:30 and then between 8:35 and 9:00, everyone shows up. Like actually everyone.
Your app probably handled 100 people fine during testing. Maybe even 200 people when they trickled in over an hour. But 1,500 people in 15 minutes? That's when you find out about all the stuff you didn't think about.
Like, everyone's trying to write their check-in status to the database at the exact same time. MariaDB (or Postgres or whatever) starts queueing these writes. Then they start timing out. Then everything just locks up.
We had this happen in 2017. Took us about three weeks to figure out the right combination of connection pooling and transaction isolation levels and async write queues. And we had people who knew what they were doing. ChatGPT would have probably suggested the wrong things because it doesn't really understand event-specific load patterns.
And the QR code thing - nobody tells you that phone cameras work differently in bright light versus dim venues. We spent like two months in 2018 just getting QR scanning to work reliably across different lighting, different phone models, different types of badge paper. It's not just "scan a QR code." It's "scan a QR code on this slightly glossy paper under these LED lights while someone's hand is shaking a bit because there's 50 people behind them in line."
Dubai Was Pretty Bad
We had this event in Dubai in 2019. Nice venue, four-star, they kept saying they had the best WiFi in the Middle East. It completely fell over by 10 AM when everyone connected. And our app at the time was built cloud-first, so when the WiFi died the app basically became useless.
But the actual technical problem was messier than that. We had like 500 devices running local SQLite databases, and they were all trying to sync when the WiFi came back on. Half of them had recorded check-ins for the same people but at slightly different times. So which version is the right one? We hadn't really thought about that. The app just kind of picked randomly. We ended up with duplicate check-ins, missing check-ins, totally wrong data.
We ended up rebuilding the whole sync system using CRDTs after that. Conflict-free replicated data types. Took six months. Our senior backend engineer - he'd worked at Google before this - said it was one of the harder technical problems he'd worked on. And you're definitely not going to prompt your way through that.
When People Leave
So let's say after about a year the app is working reasonably well. You've fixed most of the big issues. The developer who built it understands how everything works.
Then like 14 months in they get an offer from some startup. Better salary, more interesting work, they're kind of tired of event apps. They leave.
You hire someone new and they open up the codebase and they're like... what is this?
Because what happens with AI-generated code after 6 months of patches is you end up with this weird mix. Half of it uses async/await, half uses callbacks. Some functions are TypeScript, some are JavaScript. The database stuff randomly switches between ORM and raw SQL. No consistent error handling patterns. The comments are useless - they say stuff like "This function handles user check-in" but they don't explain why it's written this specific way or what edge cases it's dealing with.
Your new developer spends like a month just trying to understand what's going on. Then they tell you it would probably be faster to rebuild the whole thing from scratch.
This happens pretty much every time companies come to us after trying to build their own thing. "We spent $150K and 18 months and we can't even maintain what we built."
The Money Part
So everyone focuses on the development cost. "$80K to build, that's way cheaper than $15K a year for a platform!" Except that math doesn't really work out.
You need actual people on your team. You can't really get away with just one full-stack developer. You need someone who knows iOS (because iPhone users expect things to feel native), someone who knows Android (it's a completely different platform), a backend engineer who understands these specific event concurrency patterns, DevOps person (deployment and monitoring and scaling isn't something you can just do part-time), QA engineer (mobile testing is really specialized), and a designer who actually knows mobile patterns.
In the US that's something like $130K for the iOS person, $130K for Android, maybe $150K for the backend engineer (you need someone senior), $140K for DevOps, $110K for QA, $100K for the designer. So you're at $760K a year just in salaries. And that's being kind of conservative. In SF or NY you'd probably add 30-40% to those numbers.
And you don't just need them for the build. You need them ongoing because iOS and Android release updates every few months that break stuff. Your app needs to keep working.
So over three years you're looking at maybe $2.3 million in salary costs. Then there's recruiting fees (assume like $60K total), infrastructure (probably $15K/month so $540K over three years), compliance and security audits (SOC 2 is like $20-50K to get started then $15-40K per year to maintain, ISO 27001 is another $15-60K, penetration testing is $10-20K annually), bug bounty programs ($5-10K/year), legal reviews for privacy compliance ($10-30K), insurance ($5-15K/year), and probably 15-20% contingency for stuff you didn't think about.
All in you're looking at something like $3.8 to $4.6 million over three years. Not $80K.
Meanwhile using a platform like ours? I don't want to do hard sales here but realistically you're probably looking at low-to-mid five figures total over three years. Like less than 2-3% of what building would cost. You'd have to keep paying that subscription for like 20-30 years before you'd match the cost of building it once.
The Reputation Cost
But honestly the money part isn't even the worst part. The worst part is what happens when it breaks at a real event.
It's 8:47 AM. Your biggest client's annual conference. 2,000 attendees. Major sponsors. Press coverage. Everything you've worked toward for the past year.
The app crashes.
By 9:15 the check-in lines are backed up for 90 minutes. Exhibitors are standing around in empty booths during what should be peak traffic. Attendees are posting on LinkedIn about the tech disaster. Your client's getting texts from their board members who are stuck in line. The press is covering the logistics failure instead of the actual event.
Your relationship with that client is basically done. That's probably $200K+ in lifetime value gone. And they're going to tell every event planner they know what happened. You can't use them as a reference anymore. That case study you were planning? Dead. Your team is completely demoralized.
Then you've got the ripple effects. Maybe three enterprise deals fall through because the prospects heard about it. Your next couple clients are nervous and asking a ton of questions about reliability. Your team's exhausted from dealing with the crisis. You spend like 6 months trying to repair your reputation.
I saw this happen to a competitor in 2023. They never really recovered from it. Shut down maybe 18 months later.
The Pattern
So here's what I keep seeing. Event manager is using some platform, everything works fine, no tech issues. But when stuff works smoothly it's kind of invisible, right? They don't see all the complexity underneath. They start thinking "this seems pretty easy, why am I paying for this?"
So they decide to build something themselves. They hire some developers, or use their in-house team, or find an offshore company that promises they can do everything for $40K.
The build takes twice as long as they thought. "It'll take 3 months" turns into 6 months. Features keep getting pushed back. The developer keeps saying things are more complex than they expected.
They finally launch. Small events go okay. Larger events have problems. High-stakes events turn into disasters.
Then there's the big crash. Major client, important event, something breaks catastrophically. The reputation damage takes months to fix.
And they come back to using a platform. Usually the conversation is like "can we talk about pricing? We tried building our own thing. That's not happening again."
That's when they finally see what was happening in the background the whole time. All these edge cases we've dealt with, the concurrency optimization that took us like 18 months, the compliance work that was 2 years and $150K, the offline sync stuff that needed really specific expertise, the 24/7 support during events. They thought it looked easy because we made it look easy.
When Building Actually Makes Sense
I'm not saying you should never build something. There are cases where it makes sense, they're just rarer than people think.
Like if you're a tech company that happens to run events - think Salesforce doing Dreamforce - then software is literally your core business. You've got the team, the expertise, the budget, the time. That's different.
Or if you're running 100+ events a year and you've got requirements that are so specific that no platform can really handle them. And I mean genuinely unique technical stuff, not just "we want the buttons to be a different color."
If you've got $500K+ in budget and you're okay with 18+ months to get it right, and you're also okay with both of those numbers probably doubling. And you've actually built platforms like this before so you know what you're getting into.
If you've got a senior engineering person who's specifically done this exact type of thing before. Not just "we have some good developers." Someone who's built and scaled event platforms.
And if you can commit to spending $200K+ every year on ongoing maintenance and you've got a plan for what happens when key people leave.
But if you're thinking about building because AI tools make it seem fast and cheap, or because everything's working smoothly right now so you're wondering what you're paying for, or you're frustrated about one missing feature, or you want it done in less than a year... those are probably not great reasons.
What We Usually Tell People
Try a platform for 18-24 months. Run actual events on it. Write down everything you wish was different. Really specific stuff based on what you're actually experiencing.
Then after that period, sit down and evaluate. By then you'll know what features actually matter versus what just sounded cool in theory. You'll know if your needs are genuinely unique or if they're just preferences. You'll know if you have the revenue to justify spending multiple millions on this. You'll understand what the real pain points are instead of what you imagined they might be.
Most people who do this end up realizing the platform handles like 85-90% of what they need, and the 10% they want custom probably isn't worth $4 million.
Some people realize their needs really are that unique and custom makes sense. And by then they know exactly what they need to build instead of guessing.
The Real Question
It's not really "can we build this?" It's more like "do we want to be in the software business or the event business?"
Because you can't really be excellent at both. Every hour your team spends debugging mobile apps or dealing with infrastructure or whatever is an hour they're not spending on the thing you're actually good at, which is probably creating amazing events.
What You're Actually Paying For
When you pay for a platform you're not really just paying for software. You're paying for like 13 years of edge cases we've run into and figured out how to handle. The QR scanning in bright sunlight thing. The offline sync conflicts. The concurrency optimization. All the compliance stuff.
You're paying for infrastructure that automatically scales to 100K+ people without you having to think about it. And we've actually tested it at that scale during real events, not just in theory.
You're paying for it to be someone else's problem when things break at 3 AM. Because things do break sometimes, that's just how software works. But it's our team dealing with it instead of yours.
You're paying for peace of mind that when 2,000 people walk through those doors at 8:47 in the morning, the app is going to work.
Look
I'm not really trying to sell you specifically on our platform here. If you want to talk to us, great. If you'd rather use a competitor, that's fine too.
What I'm trying to do is save you from the phone call I got three weeks ago. Someone standing in a hallway with a bunch of frustrated people around them asking if I can somehow fix their app remotely in 20 minutes.
I can't do that. Nobody can. The problems you'd be trying to solve aren't the kind of thing you can fix with better prompts. They're architecture stuff, scaling stuff, edge cases you only find out about when 1,500 people show up at the same time.
You could spend $4 million and a couple years learning all this stuff the hard way. Or you could learn from people who already went through it.
Up to you.
.png)
.jpg)
