0 to 80 in 30 minutes

You’ve seen the tweets. You’ve probably liked a few of them. “Built a full SaaS product in 30 minutes with Claude.” “Went from idea to working app in a single lunch break.” Screenshots of beautiful dashboards, working login flows, API integrations, the lot. All built while their coffee was still warm.

And the wild thing is, it’s not even a lie. I’ve done it myself. I can sit down with an AI coding tool and have something that looks and feels like a product in genuinely stupid amounts of time. Screens, navigation, data flowing, buttons doing things. The kind of output that would have taken a small team weeks to produce two years ago, materialising in minutes.

But here’s what nobody tweets about. The 30 hours after the 30 minutes. The part where you try to actually use the thing. The part where it meets real people, real data, real edge cases, and real operational complexity. That’s where the story changes completely.

I’ve been building with AI tools at Reboxed for a while now, and the pattern is so consistent I could set my watch by it. The first 80% is breathtakingly fast. The last 20% is where all the time goes. And that ratio isn’t 80/20 in terms of effort. It’s more like 30 minutes for the first 80%, and 30 hours for the remaining 20%.

The merchant portal

Let me give you a specific example because abstractions are boring.

We’re building a merchant portal at Reboxed. This is a platform where our trade partners - the businesses that supply us with phones - can manage their inventory, track shipments, view payments, see grading results, and handle all the admin that comes with being part of our supply chain. It’s a proper product with multiple user types, permissions, data views, workflows, the works.

I spun up the frontend in a day. Less than a day, if I’m being honest about actual hours at the keyboard. The screens looked great. Dashboard with key metrics. Inventory views with filters and sorting. Shipment tracking with status indicators. Payment history with downloadable invoices. Navigation, responsive layout, sensible component structure. If I’d recorded my screen and posted it as a time-lapse, you’d think I was some kind of wizard.

And I felt like one. That first rush of AI-assisted building is genuinely intoxicating. You’re describing what you want, it’s appearing in front of you, and the feedback loop is so tight it feels like you’ve got superpowers.

Then I tried to wire it in.

Where the hours live

The frontend was a shell. A very pretty, very convincing shell. But a shell. And the moment I started connecting it to reality, the clock started running in a very different way.

First, authentication. Not “a login screen” - actual authentication. Role-based access control so a merchant can only see their own inventory, not anyone else’s. Token management. Session handling. Password resets that actually work and don’t create security holes. The AI gave me a solid starting point in about ten minutes. Getting it production-ready and properly secure took the better part of a day.

Then, the data layer. The prototype was pulling from mock data, nicely structured JSON that behaved exactly how you’d expect. Real data from our API doesn’t behave like that. Some fields are sometimes null. Date formats are inconsistent across different endpoints. Pagination works differently depending on which service you’re hitting. A phone might have been graded three times because the first two attempts hit an edge case in our diagnostics flow. The prototype didn’t know about any of that. It just showed a beautiful table and assumed the world was clean.

It isn’t. It never is.

Then, state management. What happens when a merchant is looking at a shipment and the status updates while they’re on the page? What happens when they apply three filters and then navigate away and come back - do the filters persist? What happens when their session expires mid-way through a bulk action? What happens on a flaky mobile connection when an API call times out? The prototype’s answer to all of these questions was “I hadn’t thought about that.” Which is fair enough, because I hadn’t asked it to.

Then, error handling. Not “show a red banner that says something went wrong” - real error handling. What does the user see when the payments service is down but inventory is fine? How do you communicate a partial failure state? What happens when a CSV export contains 50,000 rows and the browser starts choking? What do you show a brand new merchant who has no data yet - an empty state that’s helpful rather than confusing?

Each of these things is individually small. A few hours here, half a day there. But they accumulate. And they accumulate in a way that is completely invisible from the outside.

The demo gap

This is what I’ve started calling the “demo gap” - the distance between something that demos well and something that works well. AI has made the demo gap wider than it’s ever been.

In the old world, building a demo was hard. It took real time and real effort, which meant that by the time you had something to show, you’d already encountered and solved at least some of the real-world problems. The prototype and the product weren’t that far apart because both were expensive to build.

Now, the prototype is practically free. You can conjure a demo out of thin air. Which is amazing for exploration and idea validation. But it also means you can fool yourself into thinking you’re further along than you are. The gap between “this looks done” and “this is done” has never been bigger.

I’ve caught myself doing it. Showing the merchant portal frontend to the team, everyone nodding and saying it looks great, and me having this uncomfortable feeling in my stomach because I know that what they’re looking at represents maybe 20% of the actual work. The shiny frontend is the tip of the iceberg. Below the waterline sits auth, data integrity, error handling, performance, accessibility, edge cases, and about fifty things I haven’t thought of yet that’ll surface the moment a real merchant in a real warehouse starts actually using this thing.

It’s not a bug, it’s the job

I want to be clear - I’m not complaining about this. This is the job. This has always been the job. Software is detail work, and the details are where quality lives.

What’s changed is the distribution of effort. Building used to be slow at every stage. Now it’s explosively fast at the beginning and then… normal speed for everything else. The boring middle hasn’t gotten any faster. It’s just that the exciting beginning has gotten so fast it makes the boring middle feel slower by comparison.

And that creates a psychological trap for founders and builders. When you’ve experienced the thrill of going from zero to something in 30 minutes, spending three hours on error handling feels like you’ve hit a wall. It hasn’t. You’re just doing the work that was always there. It just didn’t used to feel this slow because everything was slow.

I think this is genuinely dangerous for people who are new to building products. If your only experience of software development is the AI-assisted honeymoon period, you have a deeply skewed understanding of what building actually involves. You think the hard part is creating screens and writing logic. It’s not. The hard part is making things work when the real world shows up and starts being unreasonable.

What the 30 hours actually look like

For the merchant portal, here’s roughly how the time broke down after the initial prototype:

Proper authentication and permissions took about eight hours. Not because the code was complicated, but because getting the security model right required thinking carefully about who can see what and why, and then testing every combination to make sure it actually held up.

Data layer work - connecting to real APIs, handling inconsistencies, building proper error boundaries, getting pagination and caching right - was another ten to twelve hours. Most of that was spent dealing with the gap between how the data should look and how it actually looks.

State management, offline handling, loading states, and UI polish ate about six hours. This is the stuff that makes the difference between “I guess it works” and “this feels good to use.” It’s invisible when it’s done well and infuriating when it’s not.

Edge cases, empty states, error messages, validation, and general hardening probably took another five to six hours. And honestly, I know there’s more to find. There always is.

So that’s 30-odd hours of work on top of the initial prototype. And I’d argue every single one of those hours was more important than the first 30 minutes, because those hours are the difference between a demo and a product.

The honest pitch for AI

None of this is a criticism of AI tools. I use them constantly and they’ve made me significantly more productive. But the productivity gain isn’t where people think it is.

The real gain isn’t “I can build an app in 30 minutes.” The real gain is “I can explore ten ideas in the time it used to take me to explore one.” The speed of the prototyping phase means I can try things, throw them away, and try again without it feeling expensive. That’s transformative for product design and discovery.

The other real gain is during the 30-hour phase itself. AI doesn’t make the detail work disappear, but it does make it faster. Debugging is quicker. Boilerplate code that used to take an hour takes five minutes. When I hit a weird edge case, I can describe it and get a suggested approach almost instantly. The boring middle is still boring, but it’s maybe 40% shorter than it would have been without AI. That’s a genuine and meaningful improvement.

But you have to be honest about it. The pitch isn’t “build a product in 30 minutes.” The pitch is “build a product in 30 hours instead of 60.” That’s incredible. It’s just not as sexy on Twitter.

For the founders reading this

If you’re building something right now with AI tools, here’s my actual advice.

Enjoy the 30 minutes. It’s a rush, and it’s a genuine glimpse of where software development is heading. Revel in it. But the moment you start thinking “I’m basically done” - stop. You’re not done. You’re 20% done, and the 80% ahead of you is where your product will actually be defined.

Budget your time honestly. If the prototype took 30 minutes, the real build will take 30 hours minimum. Probably more. If you can’t afford those hours, you can’t afford to ship it. And shipping a prototype as a product is how you end up with angry users and a reputation for things that don’t quite work.

The detail is the product. Nobody remembers how fast you built something. They remember whether it worked when they needed it to. Whether the error message made sense. Whether their data was safe. Whether the thing did what it promised when conditions weren’t perfect. That’s not the 30-minute work. That’s the 30-hour work.

And honestly? The 30-hour work is where the craft lives. It’s where you prove you actually understand your users and your operation. Anyone can build a pretty screen now. The builders who’ll win are the ones who do the boring, meticulous, unglamorous work of making it real.

The prototype is the promise. The product is the proof.