Too Early: I Built Food Delivery in 2006, and Timing Beat Me

The warning I wish I had heard in 2006

A startup is too early when the idea is right but the technology that would make it work does not exist yet. When that is true, being early is the same as being wrong. The market cannot tell the difference between a founder who is a decade ahead and a founder who is simply mistaken, because both of them fail to ship something people can actually use. That is the lesson I paid for, and this is the story behind it.

In 2006 I founded RuDeliver.com, an on-demand food delivery service for the Rutgers University community in New Brunswick, New Jersey. We delivered late-night food to hungry college students from 9pm to 3am, from places like White Castle, Pizza Hut, Qdoba, and TGI Fridays, for a flat five dollars a run. If that sounds familiar, it should. It is the same idea that DoorDash, Uber Eats, Grubhub, and Postmates turned into a multi-billion-dollar category a decade later. We had the demand. We had the concept. We were serving real orders to real students at the exact hours nobody else would deliver.

We did not have the one thing that mattered, which was the technology stack that makes on-demand delivery function. There were no smartphones in students' pockets. There was no app store to ship an ordering app into. There was no gig-driver network to tap for supply, no mapping API wired into a phone's GPS to route a driver, no one-tap payment to take money without cash changing hands. We built a real business on top of a hole where the infrastructure was supposed to be, and we filled that hole with phone calls, our own ordering site, cash, paper, and human hustle. It worked, in the grinding, hand-built way that a thing held together by hand can work. It never became the category winner, and it was never going to, because the ground it needed to stand on had not been poured yet.

So this is a cautionary tale about timing. Not about ideas, and not about effort. We had both. It is about the most underrated question in all of startups, the one investors ask and founders skip: why now? Why is this the right moment for this thing to exist, and if the honest answer is "it isn't, but I want it to be," you are about to spend years and money teaching a market a lesson that the next company will get paid for. Being first is a story people love to tell. Being first before the world is ready is a story that ends with someone else's logo on the category you invented.

The thesis I want you to hold me to for the rest of this piece is simple. Being early is indistinguishable from being wrong when the enabling infrastructure is missing. You will do the R&D, you will educate the customer, you will prove the demand, and then a company with the technological tailwind at its back will arrive on time and win the thing you started. I lived it. Here is exactly how it happened, and how you can tell if you are about to do the same.

2006: a delivery idea born at Rutgers

I founded RuDeliver.com in 2006, while the world around Rutgers still ran on flip phones and printed menus. The name did double duty. RU is Rutgers University, the way everyone in New Brunswick refers to the school, and it is also a play on "are you," as in "RU hungry?" The tagline said the rest: RU Deliver, We Deliver. It was the kind of name you can shout across a dorm room and everyone gets it.

The idea did not come from a spreadsheet or a market-sizing exercise. It came from being a student in a college town at midnight with nowhere to get food. New Brunswick sits in Middlesex County, a dense pocket of central New Jersey with tens of thousands of students packed into a few square miles. Those students kept hours that no restaurant kept. They studied late, they went out late, they got hungry late, and by the time they wanted food, everything that delivered had closed and everything that was open would not come to them. There was a gap in the day, a window between about 9pm and 3am, where demand was enormous and supply was zero. I decided to be the supply.

The premise was almost embarrassingly simple. If a student wanted a crave case from White Castle at 1am and could not get it, and I could go get it and bring it to them for a small fee, that was a business. Not a clever business, not a defensible one on paper, but a real one that solved a real problem for people who felt it every single night. Nobody was arguing about the demand. You could stand outside a residence hall at midnight and watch it walk past you.

What I did not appreciate at the time, and what this whole story is about, is that having obvious demand is only one leg of a stool. I had the demand and I had the will. I was missing the thing that turns a good idea into a scalable company, which is the layer of technology underneath it that lets one person coordinate thousands of orders without drowning. In 2006 that layer did not exist for anyone, not for me and not for the giants who would win later, because they had not been founded yet. I was standing in the right spot on the map about ten years before the roads were built to reach it.

I want to be honest about scale from the first paragraph, because the value of this story is the lesson and not a vanity number. RuDeliver was not a hobby. It was an ambitious operation that reached across Middlesex County, ran a late-night student service and a daytime lunch business at the same time, onboarded more than fifty restaurants, and put tens of drivers on the road. It aimed big. It never became a household name or the category winner, and it folded, because the fixed-cost economics could not hold without the gig-labor model and the smartphone-era tools that did not exist yet. I am not going to invent a revenue figure, an order count, or a funding round, because I do not need to, and I am not going to shrink the thing into a cute side project either, because that is not what it was. The point is not how big RuDeliver got. The point is that it was right, and right at the wrong time is a very specific and very expensive kind of wrong.

What we actually built: late-night food, run by hand

RuDeliver was a late-night food delivery service, and every part of it was designed around the hours other people had given up on. We ran from 9pm to 3am. Those six hours were the entire business, because those were the hours when a hungry student had no other option. During the day, restaurants delivered for themselves and there was nothing for us to do. After dark, we were the only game in town.

We delivered from local spots and chains around New Brunswick: White Castle, Pizza Hut, Qdoba, TGI Fridays, and more. The menu was not ours. We were the layer between the student and the restaurant, the people willing to drive to the counter, wait, pay, and carry the bag back to a dorm or an apartment. The pricing was deliberately dead simple so a student could understand it in one breath. Five dollars per delivery. A household could order up to three meals on a single run, and if you wanted more than three, the extra meals cost more. We also carried drinks, which we offered at discounted rates because a soda is easy to add to a bag and students always wanted one.

The part that dates the whole enterprise comes next. Orders reached us two ways: through our own custom online ordering site, which was unusual for 2006, and by phone, which is how most of them still came in. A student placed an order online or called it in, told us what they wanted and from where, gave us the address, and we wrote it down and went and got it. There was no app, because there was no such thing as a consumer food-ordering app you could put in someone's hand in 2006. There was no real-time dispatch wired to that site, because that software did not exist for a business our size. Our web page reached a student sitting at a desktop in a dorm, not a hungry student holding a phone on the walk home, because the device that could load it and pay on it had not shipped yet. So most orders still arrived by voice, and behind them sat a phone, a person answering it, a notepad, and a car doing the coordinating a computer does now.

On the customer side, payment worked the way it worked before a phone in your pocket could take money: cash on delivery. The driver showed up, handed over the food, and collected the bill in dollars at the door. That meant every driver was also carrying a float, making change in a stairwell at 2am, and reconciling a pocket full of cash at the end of a shift. It worked, but every step of it was manual, and every manual step is a place where a business leaks time and money.

When I lay it out like this, the shape of the problem is obvious in hindsight. The idea was modern. The execution had to be old-fashioned, because the tools to execute it the modern way had not been invented. We were running an on-demand marketplace with a telephone, a legal pad, and a website nobody could yet carry in their pocket. The gap between what we were trying to do and what we had to do it with is the entire story, and it is a gap you could not close in 2006 no matter how smart or hardworking you were. You can see it plainly in what a single order required.

Who we really delivered to: students, residents, and J&J at lunch

The late-night student story is the one people remember, and it is true, but it is not the whole business. RuDeliver did not only feed Rutgers students at 1am. We delivered to residents all over Middlesex County, New Jersey, and during the day we ran lunch to workplaces: university staff, offices, and large employers like Johnson & Johnson, whose headquarters sit right in New Brunswick. The company had two faces. One was the late-night student service that gave us our name. The other was a daytime lunch operation feeding people who were at work and could not leave to get food.

Broadening past students was the obvious move, because the same gap existed everywhere, just at different hours. A student was stuck in a dorm at midnight with no food. An office worker was stuck at a desk at noon with a thirty-minute window and no time to drive anywhere. A resident across the county wanted dinner brought to their door and had no service that would do it. Same problem, different clock. We tried to serve all of it, which meant our day started earlier and our reach stretched well beyond the campus that the RU in our name pointed to.

The corporate lunch runs were, in some ways, the better customer. An office of people at Johnson & Johnson ordering lunch is a predictable, repeatable block of orders at a set time, which is exactly the kind of demand a delivery operation wants. Late-night student orders were spiky and chaotic, clustered around bar close and study crunches. Daytime corporate orders were steadier. If the infrastructure had existed to serve both efficiently, the mix would have been healthy. It did not, and serving two very different demand curves with one hand-run operation only multiplied the coordination problem I keep coming back to.

I mention all of this because the popular version of the story flattens RuDeliver into a cute college side project, and it was more than that. We were trying to build a general on-demand delivery company for an entire county, with a college late-night service as the flagship and corporate and residential daytime delivery underneath it. The ambition was closer to what the category eventually became than the students-only framing suggests. And the reason it could not be realized was the same reason at noon as it was at midnight: the tools to coordinate that many orders across that much geography did not exist yet.

How we made money: a $5 fee and discounts I negotiated by hand

The delivery fee was five dollars. That number is on the archived site and it was deliberately small, because a big fee kills impulse orders and the whole business ran on impulse. Five dollars alone does not build a company, though, and it was never meant to. The real margin came from the restaurants, and I negotiated it in person, one restaurant at a time.

The money came from two places at once. For every restaurant we onboarded, I personally negotiated a discount off their menu, usually in the range of thirty to forty percent. The customer paid the full menu price plus the five-dollar delivery fee. We paid the restaurant the discounted price. The spread between the full price the customer paid and the discounted price we paid the restaurant was our margin, on top of the fee. So a fifteen-dollar order might cost us ten or eleven dollars at the counter, and the difference, plus the five-dollar fee, was what the company lived on.

Negotiating those discounts was a real job and I did it myself, restaurant by restaurant, explaining that we would bring them incremental orders they would not otherwise get, from customers they could not otherwise reach, during hours they were not otherwise busy. Some restaurants understood immediately. Some needed convincing. Thirty to forty percent is a serious discount to ask of a food business with thin margins, and getting to yes took patience and a clear pitch about volume they would not have to work for.

The problem was not the model on paper. The problem was that even a healthy spread on every order could not cover what sat underneath it. The margin from the discount and the fee had to pay for drivers who were on the clock all night, an office to run from, insulated bags and supplies, and the phone team taking and placing orders. When your revenue per order is a fee plus a spread, and your cost per hour is fixed no matter how many orders come in, the math only works at a volume we could not reach by hand. The margin model was sound. The cost structure underneath it, forced on us by the era, was the thing that broke.

How we ran orders: a phone team, a company card, and an early ordering site

Behind the five-dollar fee was a machine made mostly of people and telephones. A phone support team took the customer's order. Then that same team turned around and placed the pickup order with the restaurant, by telephone, so the food would be ready when the driver arrived. Two calls for every order: one to take it, one to place it. Software does both of those instantly today and charges nothing to do it. We did them with a headset and a person who had to be polite and accurate at midnight and at noon.

Payment at the restaurant ran on a company card. The driver arrived, paid the restaurant with our card, and carried the food out. For a handful of trusted partners we set up Net 7 terms, meaning we settled the bill within seven days instead of at the counter, which helped our cash flow on the restaurants that trusted us enough to extend it. Most did not, so most of the time a driver was paying with the company card at pickup, which is its own small operational headache: cards, limits, receipts, reconciliation, all by hand.

The part I am still a little proud of is that we built our own custom online ordering platform, a website where a customer could place an order and have it delivered by our own fleet. Online ordering itself was not brand new. Menu aggregators like CampusFood and AllMenus already let you browse menus and place orders in some markets. What was unusual was building our own ordering front end and welding it to our own last-mile delivery operation, the browse-it, order-it, we-bring-it loop that food-ordering apps later made universal. Most people in 2006 still assumed food came by calling a restaurant directly, so putting our own site in front of them was ahead of the local curve. Building it early is one more example of the same pattern that defines this whole story: we were ahead of time on the technology as well as the idea, doing by hand what would later be a mature, off-the-shelf layer.

Being early on the ordering site did not save us, for the same reason being early on everything else did not save us. A web ordering page in that era reached people sitting at a desktop computer, not a hungry student holding a phone, because the phone that could load that page and pay on it was still years away. We built the front end of the future and then watched most of our actual orders still come in by voice, because the device that would have made the site the main channel did not exist in our customers' pockets yet.

Filling the menu: CampusFood, AllMenus, and 50-plus restaurants

A delivery service is only as good as the list of places it can bring you food from, and filling that list was one of the first hard problems I had to solve. I established the delivery partnerships myself. The breakthrough was partnering with the menu aggregators of the day. We partnered with CampusFood.com and with Dot Menu, which was owned by AllMenus at the time, and AllMenus was later acquired by Grubhub. That single set of partnerships brought over fifty restaurants onto our platform at once, instead of me signing them one storefront at a time forever.

That is worth sitting with for a second, because it shows how tangled up in the eventual winners this operation already was. AllMenus, the company behind the menu data we plugged into, ended up inside Grubhub, which became one of the giants of the category we were early in. We were partnering, in 2006, with the ancestors of the companies that would go on to win. The plumbing of the future was already being laid, and we were connected to it, just years too soon to benefit from where it was heading.

We also partnered with ScarletMenus, a rival menu brand that came along later, named for the scarlet that Rutgers runs on. Between the aggregators and the direct relationships, the menu got real. Fifty-plus restaurants is a genuine selection, enough that a customer could reasonably expect to find something they wanted at most hours. Getting the supply of restaurants was not the thing that killed us. We solved that problem, through partnerships and hustle, reasonably well.

The lesson buried in the partnerships is the same lesson as everywhere else in this story. The menu data existed. The aggregators existed. Even a version of the online ordering idea existed, at CampusFood and inside AllMenus. What did not exist was the layer that turns a big menu into a scalable on-demand delivery business: the phones in customers' hands, the gig drivers, the routing, the payments. We could assemble a great list of restaurants in 2006. We could not assemble the delivery machine around it, because half the parts had not been manufactured yet.

The demand was real: why the idea was right

I want to spend a section on the demand, because this is what makes the story a cautionary tale instead of a story about a bad idea. Bad ideas fail because nobody wants them. RuDeliver was the opposite. People wanted it badly, visibly, every night. The idea was right. That is precisely what made being early so dangerous, because strong demand convinces you that the rest will follow, and it does not always follow on your timeline.

Think about who the customer was. A college student is the perfect early customer for food delivery. They are up late, they have irregular schedules, they are often without a car or without the will to drive after a long night, and they treat convenience as worth paying for in a way that a budget-conscious family might not. They are clustered together in dense housing, which shortens every delivery. And they talk. Word of mouth in a college town moves faster than any ad. When something works, the whole floor knows by the weekend.

Now think about the timing of the demand. Between 9pm and 3am, the supply of food delivery in New Brunswick was effectively zero. The pizza places that delivered during dinner had closed their delivery windows. The 24-hour spots made you come to them. A student at 1am had a craving, a phone, and no way to get what they wanted without getting dressed and driving. We stepped into a vacuum. There is no better place to start a business than a vacuum, because you are not fighting a competitor, you are meeting a need that nothing else is meeting.

The demand was so real that the entire category eventually proved it at global scale. Everything DoorDash and Uber Eats later built was a bet that people would pay a fee to have restaurant food brought to them on demand. That bet was correct. We were making the same bet in 2006, across Middlesex County, years before the tools to serve it at scale existed. We were right about the single most important thing a startup has to be right about, which is that customers want the thing and will pay for it.

So if the demand was real and the idea was right, why is this a warning and not a triumph? Because demand is necessary and not sufficient. Demand tells you the destination exists. It does not tell you the road exists. We could see the customers clearly, we could serve them, and we still could not build a company that scaled past the reach of our own hands, because the machinery that turns proven demand into a growing marketplace was not available to us. The demand was the easy part. The demand was never the problem. The problem was everything underneath it, and that is where the rest of this story lives.

The proof: an April 2007 snapshot still exists

This is not a story I reconstructed from memory and rounded up. You can still see RuDeliver.com for yourself. The Internet Archive captured the site, and the earliest snapshot is from April 10, 2007. Go look at the April 2007 snapshot and you will find the real thing: RU Deliver, We Deliver, a late-night food delivery service for the Rutgers community, with the hours and the model exactly as I have described them.

Note the dates carefully, because they matter to the argument. I founded RuDeliver in 2006. The first Wayback Machine capture is from April 2007. The site predates its own first archive, which is normal for the era, because the Archive did not capture every small site the moment it went live. So the public record you can inspect today starts in April 2007, and the business it documents started the year before. When I tell you this was a 2006 idea, the archive is the receipt.

I point people to this snapshot for a reason beyond proving I am not making it up. Look at what the page is, and then look at what it is missing, and you are looking at the entire thesis of this article rendered in HTML. There is a phone number to call. There is a description of the service and the hours. There are the restaurants. There is a flat delivery price. What there is not, because it could not exist yet, is an app to download, a live map tracking your driver, or a way to pay from a phone. We had our own ordering site in that era, which put us ahead of the local curve, but a web page then reached a desktop, not a device in a student's pocket, so a large share of orders still came in by voice. It is a photograph of an idea that arrived before its tools.

I find it genuinely moving to look at, years later, in the way that old photographs are moving. There is a version of me in that markup who believed the effort would be enough, who thought that if the demand was real and we worked hard the rest would sort itself out. That version of me was wrong in a specific and instructive way. He was not wrong about the customer. He was wrong about the calendar.

So before you read the rest of this, open the snapshot in another tab. See the voice-heavy, cash-at-the-door, poster-shaped business for what it was. Then read on, because everything that follows is an explanation of the empty spaces on that page: the app that was not there, the map that was not there, the payment that was not there, and the network of drivers that was not there. Those empty spaces are not failures of imagination or effort. They are the shape of a technology stack that the world had not built yet.

The gap: what delivery needed that did not exist

The cleanest way I know to explain what went wrong has nothing to do with our effort. Modern on-demand food delivery is not one invention. It is a stack of six or seven inventions working together, and remove any one of them and the whole thing stops being a scalable business and becomes a person with a car. In 2006, almost every layer of that stack was missing. We were not competing on a level field a few years before the giants. We were trying to build a skyscraper on a lot where the foundation had not been dug.

Walk the stack from the top down. At the top is the consumer's device, the smartphone, which puts an ordering interface in every customer's pocket. Below that is the app store, the distribution channel that lets you ship that interface to millions of phones. Below that is location: GPS in the phone and mapping APIs that can route a driver to a door and give the customer an ETA. Below that is payment, the ability to take money with a tap instead of cash at the door. Below that is supply, a network of on-demand drivers you can summon without employing them full time. And underneath all of it is the plumbing: cloud infrastructure, real-time dispatch software, push notifications, and cheap digital marketing to reach the customer in the first place.

Count how many of those existed in a usable form in 2006 for a small operator. Smartphones as we know them: no, the iPhone launched in 2007. App stores: no, they arrived in 2008. Phone GPS and turn-by-turn routing: no, that came later on the mobile side. One-tap payment: no, the modern developer-friendly payment era arrived around 2010 and after. An on-demand gig-driver network: no, Uber was founded in 2009 and the delivery players came years after that. Cloud dispatch, push notifications, social marketing to a local audience: no, no, and not in the form that works. We had the demand and none of the machinery.

This is what makes "too early" so cruel and so hard to see from the inside. Each missing piece on its own looks like something you can work around with hustle, and you can, for a while. No app? Take orders on a web page and over the phone. No consumer payment rails? Collect cash at the door. No driver network? Hire drivers yourself and pay them by the hour. No dispatch software? Use a notepad. Every workaround is reasonable in isolation. The trap is that the workarounds do not compose. A business that patches all six holes by hand does not scale, because the human effort required grows with every order, and the whole promise of an on-demand marketplace is that it should get more efficient as it grows, not less.

The table below is the argument in one view. On the left is what on-demand delivery needed. In the middle is what actually existed for a small operator in 2006. On the right is when the real version arrived. Read down that right-hand column and you will notice something uncomfortable: almost every enabling technology showed up between 2007 and 2014, which is exactly the window when the companies that won this category were founded. They did not beat us to the idea. They arrived after the tools did.

Missing piece: a smartphone in every pocket

Start with the device, because everything else in on-demand delivery hangs off it. The reason DoorDash and Uber Eats feel effortless is that the customer is holding a small computer with a screen, a data connection, a location sensor, and a payment method already loaded. Tap the app, see the restaurants near you, build an order, pay, and watch a little car move across a map toward your door. None of that is possible without the phone. In 2006, the customer did not have the phone.

The iPhone launched in June 2007, a year after I started RuDeliver. Let that sit for a second. The single device that made consumer on-demand delivery possible did not exist when we opened, and when it did arrive, it took years to become common, to get a real data plan, to get an app platform, and to get into the hands of the students who were our customers. Android followed in 2008. The world we now take for granted, where everyone is carrying an internet-connected computer, was still being born while we were driving crave cases across New Brunswick using a phone that could do two things: call and text.

Then came distribution. A device is only useful to a delivery company if you can put your software on it, and that requires an app store. Apple's App Store opened in 2008. Before that, there was no consumer channel to ship a food-ordering app into people's pockets, no matter how badly you wanted one. Even if I had somehow built an ordering app in 2006, there was nowhere to put it and no device ready to run it. We did have our own web ordering page, which put us ahead of the local curve, but it loaded on a desktop, not on a phone in a student's pocket, so most orders still came in by voice. The mobile ordering channel the winners would later live on simply had no home and no host yet.

Consider what the phone plus the app store gave the companies that came later, all of it for free by the time they started. It gave them a customer who could self-serve an order without a human answering a call. It gave them a screen to show restaurants, prices, and photos. It gave them a channel to send a push notification that says your food is five minutes away. It gave them a device that knew where the customer was standing. Every one of those is a cost we had to cover with a human being, and every one of them is a reason a phone-based operation cannot scale the way an app-based one can.

I do not say this to make excuses. I say it because it is the mechanism of the whole failure. We were mostly asking students to do the harder thing: call a phone number, talk to a person, and wait. The later winners asked students to do the easiest thing in the world by then, which was tap a glowing rectangle they were already holding. Same demand, same food, same city. The difference was a device that had not been invented when we started and was everywhere by the time they did. You cannot out-hustle a missing device.

Missing piece: an on-demand driver network

The second thing modern delivery cannot live without is supply, and by supply I mean drivers you can summon on demand without carrying them as full-time payroll. This is the quiet genius of the companies that won. They did not build fleets. They built a network of independent drivers who log on when they want to work, get matched to orders by software, and get paid per trip. That network is what lets a delivery company grow, because you can add drivers as fast as you add orders without the fixed cost of hiring, scheduling, and managing employees for every shift.

That model did not exist in 2006. Uber was founded in 2009 and popularized the idea that an ordinary person with a car and a phone could be summoned to do a job. Postmates arrived around 2011 with courier-style delivery of local goods. DoorDash launched in 2013, built specifically around restaurant delivery in exactly the kind of setting we had operated in. Uber Eats came in 2014. Every one of those depended on the smartphone and the app store to coordinate a fluid pool of drivers, which is why none of them could have existed at the time we did. The supply side of the marketplace was waiting on the same device the demand side was waiting on.

So what did we do for supply? We were the supply. Dispatch was me and a small crew, drivers were people I could reach directly, and coordination happened in real time inside our own heads and over our own phones. When orders came in fast, there was no software rebalancing the fleet, no algorithm assigning the nearest driver to the nearest pickup, no surge mechanism to pull more drivers online. There was a group of people trying to remember who was where and who could grab the next run. It is a beautiful thing to watch a small team do this well, and it is also a hard ceiling, because the coordination lives in human attention and human attention does not scale.

Picture the difference on a busy night. A modern platform sees fifty orders come in, and its software fans them out across dozens of independent drivers, batching nearby pickups, routing each one, and quoting each customer an honest ETA, all without a person touching it. We saw a rush of calls and had to solve the same puzzle with memory and hustle, one order at a time, hoping we had enough people on and enough gas in the tanks. The winners turned dispatch into a math problem a computer solves instantly. For us it was a human problem we solved slowly, and slowly is the enemy of on-demand.

This is the layer people underrate most when they look back and say we were just early. The driver network is not a nice-to-have. It is the engine of the entire business model, the thing that lets proven demand turn into a growing company instead of a busy night. We had proven demand and no engine. We had to be the engine ourselves, and a business where the founders are the engine has a ceiling you can calculate on the back of a napkin: it is however many runs your drivers can physically make in a shift while a human tracks every one of them in his head. That is not a company that takes over a category. That is a company that runs on borrowed time.

The payroll math that could not work: paying idle drivers by the hour

If you want the single sharpest proof that RuDeliver was too early, it is not the missing app or the cash at the door. It is payroll. To deliver food fast, you need drivers ready and waiting the moment an order comes in. In 2006 there was no gig economy to supply those drivers on demand, so we did the only thing available: we hired drivers and paid them a flat ten dollars an hour to be on shift, on the clock, ready to go, busy or idle. Idle time was paid time. A driver sitting in the parking lot between runs at 11pm cost us exactly as much as a driver mid-delivery.

To keep deliveries quick across a whole county at peak hours, we needed tens of drivers on at once. Do that math. Tens of people, ten dollars an hour, every hour of every shift, including the slow stretches where the phone barely rang. The payroll clock never stopped, but the orders did. On a dead Tuesday between rushes, we were still paying a full roster to stand ready. That fixed, idle-heavy payroll is the cost that no amount of margin from the fee and the discounts could reliably cover, because it did not scale down when the orders thinned out.

Now put the gig model next to it, the one that arrived a decade later and made the whole category work. DoorDash and Uber Eats do not pay drivers to wait. Drivers are independent contractors paid per delivery. If no orders are coming in, the platform pays nothing, because there is no idle payroll to carry. When orders surge, more drivers log on, drawn by the work. The cost of supply flexes perfectly with demand, up and down, order by order. Zero idle payroll. That single structural difference is a large part of why a business that was impossible for me in 2006 was viable for them by 2013.

One more detail matters and I want to be clear about it, because it is a point of pride. The drivers kept one hundred percent of their tips. Tips were never company revenue, not a cent of them. The ten dollars an hour was ours to pay and the tips were the drivers' to keep. That was the right thing to do by the people driving all night, and it also meant the tip pool did nothing to offset the fixed payroll that was sinking us. We carried the full weight of paid idle time and passed all the tips through to the drivers, which is honest and humane and also, in a business already underwater on labor cost, one more reason the numbers would not close.

This is the cleanest expression of too early in the entire RuDeliver story. The exact innovation that made on-demand delivery profitable, a flexible pool of contractors paid only when they work, did not exist yet. We were structurally forced to carry fixed payroll through every slow hour because the alternative had not been invented. You cannot out-hustle that. It is not an efficiency you can find or a deal you can negotiate. It is a labor model that the world simply had not built in 2006, and its absence put a floor under our costs that our revenue could not clear.

Missing piece: frictionless digital payment

Payment is the layer people forget, and it quietly shaped everything about how RuDeliver ran. Today, paying for a delivery is invisible. The card is already stored, the tap happens inside the app, the tip is a preset button, and the money moves without anyone counting bills or making change. That invisibility is a technology, and it is a fairly recent one. In 2006, taking a consumer payment cleanly and cheaply over the internet, especially for an independent operator, was hard and clumsy, and taking it inside a mobile experience was essentially impossible because the mobile experience did not exist.

So we did what you did before digital payment was easy: cash on delivery. The driver collected dollars at the door. On paper that sounds simple. In practice it shaped the whole operation and taxed every single order. Every driver had to carry a float to make change. Every transaction happened in a stairwell or a doorway at 1am, in the dark, with someone counting bills. Every shift ended with a reconciliation of cash against orders, which is a slow and error-prone ritual that a card processor now does automatically and perfectly. Cash is not free. Cash is a tax you pay in time, in risk, and in mistakes, and we paid it on every run.

The frictionless payment era that the winners enjoyed showed up later. The developer-friendly payment infrastructure that made it trivial to take a card inside an app, the kind of tooling that arrived around 2010 and after, simply was not there when we started. That tooling is what lets a company store a card once and charge it a hundred times with a tap, add a tip with a preset, split money to a driver, and reconcile everything in software. When that arrived, taking money stopped being an operational chore and became a line of code. We never got to make that trade. We were still counting bills at 3am.

Think about what cash-on-delivery does to demand, not just to operations. It adds friction at the worst possible moment, the moment of handoff. The customer has to have cash. The customer has to have close to the right amount, or wait for change. The driver has to protect that cash all night. Every one of those is a small reason not to order, a little bit of sand in the gears, and on-demand delivery lives or dies on removing sand from the gears. The whole promise is that getting food should be as easy as wanting it. Cash at the door breaks that promise at the last inch.

None of this was a decision we got wrong. There was no tap-to-pay to offer a customer. On the consumer side we used the only payment method a late-night operation had in 2006, cash at the door, and it worked, and it also capped us. When I say the enabling infrastructure was missing, payment is one of the clearest examples, because you can draw a straight line from "no easy digital payment" to "cash at the door" to "more friction, more risk, and a hard limit on how big and smooth this can get." The later winners did not just have a better app. They had a better way to move money, and moving money smoothly is half the magic of on-demand.

Missing piece: the real-time logistics layer

Underneath the phone, the drivers, and the payment sits the least visible layer of all, and it is the one that actually makes a delivery marketplace hum: real-time logistics. This is the software that knows where every driver is, routes each one to a pickup and a drop-off, calculates an honest ETA, batches nearby orders together, and keeps the customer informed with a push notification at each step. It runs in the cloud, it responds in milliseconds, and it is completely invisible when it works. In 2006, for a small operator, none of it existed in a usable form.

Consider location alone. Google Maps launched a web mapping API in 2005, which was genuinely new and useful, but that is not the same as GPS in a customer's phone, and it is not the same as turn-by-turn navigation guiding a driver through a city. The mobile side of location, the part where the customer's phone knows where they are and the driver's phone routes them door to door, came with the smartphone era in 2008 and 2009. We routed drivers with memory and knowledge of the town. That works in a town you know cold, and it breaks the moment you push out across a county your drivers do not have memorized.

Now stack the rest of the logistics layer on top. Real-time dispatch software that assigns orders to drivers automatically: we did not have it, we did it by voice. Cloud infrastructure that scales up when a Friday night rush hits: we did not have it, we had however many people were on shift. Push notifications that tell a customer their food is close: we did not have it, the customer waited and wondered and sometimes called to ask. Each of these is a piece of the modern experience that the customer never sees but absolutely feels, and each of them we replaced with a human being paying attention.

And then there was reaching the customer at all. The winners had cheap, targeted digital marketing: social platforms and mobile ads that could put an offer in front of exactly the right local audience for a few dollars. We had flyers. We printed them and put them where students would see them, around campus, in the places late-night hunger lived. Flyers are not nothing, and in a tight college town they actually work, but they are a blunt, slow, physical instrument compared to a targeted ad that finds a hungry 20-year-old on the device in their hand. Even our marketing had to be manual and physical, because the digital version had not been built yet.

Put the whole layer together and you see the real shape of the disadvantage. On-demand delivery is a logistics company wearing a food company's clothes, and the logistics only work when software is doing the coordinating in real time at a scale no human can match. We had no logistics software. We had a phone, a notepad, a car, some flyers, and people who cared. That combination can run a real delivery service by hand for a while. It cannot become the coordination engine for a category, because the coordination engine is made of code that responds in milliseconds, and in 2006 that code, at a price a small startup could touch, had not been written yet.

The timeline: when the enabling tech actually arrived

It helps to see the whole sequence in one line, because the pattern is almost comically clear once you do. Nearly every technology that on-demand food delivery needs was invented, matured, or made affordable in the years right after 2006. We did not start a few months early. We started at the front edge of a roughly decade-long build-out of the exact stack our idea required, and we started at the wrong end of it.

Walk the years. In 2005, Google Maps introduced a web mapping API, useful but not yet mobile. In 2006, we founded RuDeliver into a world with none of the rest. In June 2007, the iPhone launched, putting a real computer in a pocket. In 2008, Apple opened the App Store and Android arrived, creating the distribution channel and a second platform. Phone GPS and mobile turn-by-turn routing became practical across 2008 and 2009. In 2009, Uber was founded and proved that ordinary people could be summoned to drive on demand. Around 2010 and after, developer-friendly payment infrastructure made taking money inside an app trivial. Postmates came in 2011, DoorDash in 2013, and Uber Eats in 2014, each one arriving after the pieces it depended on were already in place.

Line those dates up against the founding dates of the companies that won this category and the lesson writes itself. They were not smarter about the idea than we were. The idea was the same idea. They were better timed. They started building at the moment the infrastructure they needed either already existed or was arriving in real time under their feet. Every year they waited, the ground got firmer. Every year we operated before them, the ground stayed soft, because the concrete had not been poured.

This is the part that is genuinely hard to accept as a founder, and I have made my peace with it slowly. The most important input to the outcome was not the quality of the idea, the effort of the team, or even the reality of the demand. All three of those were on our side. The decisive input was the calendar. We were operating in 2006 with tools from 2006, and the business we were trying to build required tools from 2013. No amount of hustle closes a seven-year gap in the fundamental technology stack. You cannot work hard enough to summon a smartphone that has not been invented.

I keep this timeline close because it is the antidote to the two lies a founder tells themselves after an early failure. The first lie is that we just did not work hard enough, which is a way of taking on guilt that is not yours to carry. The second lie is that the idea was bad, which is a way of unlearning the one thing you actually got right. The timeline refuses both lies. It says: the idea was right, the effort was real, and the timing was fatal, and the timing was fatal in a way you could have seen if you had known to ask the right question. That question has a name, and the next sections are about it.

The operational grind of doing it all by hand

Let me take you inside a night, because the abstract argument about missing infrastructure becomes concrete the moment you live one shift. Every layer that a modern platform automates, we performed with human beings, in real time, under pressure, for six hours straight. The grind was not a sign we were doing it wrong. It was the direct, unavoidable consequence of running an on-demand marketplace with the tools of a corner store.

A night started with the phone. Someone had to be reachable and answering, because the phone carried most of the front end of the business. A call came in, and a person listened, wrote down the order, the restaurant, the address, and any special requests, and read it back to confirm. That is a job a form does now, instantly, with no errors and no hold time. For us it was a person with a notepad, and the quality of the whole order depended on their attention and their handwriting at 1am.

Then dispatch, which was the hardest human job of the night. With orders arriving and drivers out on runs, someone had to hold the whole board in their head: who was where, who was free, which pickups were near each other, which order had been waiting too long. A platform solves this with an algorithm in milliseconds. We solved it with memory and judgment, and it got harder with every additional order, which is the exact opposite of how a scalable system should behave. The busier we got, the more the coordination strained, because the coordination lived in a person and a person has a limit.

Then the run itself. A driver took the order, drove to the restaurant, waited in line like any customer, paid out of a float, carried the food back, found the address without phone GPS, climbed the stairs, handed it over, and made change from cash in the dark. Multiply that by the orders on a busy night and stack the drives on top of each other, with no routing software batching nearby stops, and you have a night that is pure physical effort from 9pm to 3am. At the end of it came reconciliation: counting cash against orders, sorting out what came in and what went out, closing the books by hand.

I look back on those nights with a strange mix of pride and clarity. Pride, because a tight crew ran a real service on nothing but attention and hustle, and served customers who were genuinely glad we existed. Clarity, because every hour of that grind was a receipt for the missing infrastructure. Everything we did by hand is something the winners got a machine to do for free. The phone answering, the dispatch, the routing, the payment, the reconciliation: all of it is now software, and software does not get tired at 3am, does not misremember an address, and does not have a ceiling on how many orders it can hold in its head. We were the software, and being the software is a wonderful way to run a small business and a terrible way to build a large one.

Launch week: three-hour waits and tens of thousands lost

The opening week nearly ended the company before it started. Demand showed up exactly as I had bet it would, in a flood, and we were not ready for the one thing a delivery service absolutely has to get right: actually delivering, on time. Customers waited up to three hours for their food. Not minutes. Hours. Some orders placed for a late dinner did not arrive until the night was nearly over.

The reason was the exact set of missing pieces this whole article is about, all failing at once under real load. We did not have enough drivers on to meet the surge. And we had no efficient way to coordinate the pickups and deliveries we did have, because there was no dispatch software, no GPS, and no routing. When ten orders come in across a county at once and you are assigning them from memory to drivers you are tracking in your head, everything backs up. A driver would finish one run and we would send them on a long drive to the next pickup when someone closer was free, because nobody had a real-time picture of where everyone was. The delays compounded on themselves.

The financial damage that week was severe. We lost tens of thousands of dollars. When customers waited three hours, many were understandably furious, and we made it right the only way you can: full refunds. The part that really stung came next. The restaurants had done their job. The food was made, and we had paid for it. So when we refunded an unhappy customer, we also ate the cost of the food itself. We were out the refund and out the wholesale cost of a meal that arrived too late to be wanted. Multiply that across a brutal week and the losses climb fast.

I do not tell this to wallow in it. I tell it because launch week was the whole thesis compressed into seven days. Everything that made those three-hour waits happen was a missing technology that the winners would later get for free: enough on-demand drivers, real-time dispatch, GPS routing, live ETAs so a customer knows their food is twenty minutes out instead of silently waiting three hours and boiling over. We had none of it, and the first serious rush of real demand exposed every gap at once. A modern platform absorbs a surge with software. We absorbed it with apologies, refunds, and the cost of wasted food.

Why it could not scale, honestly

I want to be careful and honest here, because this is the part of the story where it would be easy to either inflate RuDeliver or shrink it. It reached across Middlesex County, ran a late-night student service and a daytime lunch business, put tens of drivers on the road, and carried more than fifty restaurants, and it still never became the category winner. It aimed big and it did not scale, and in the end it folded. I am not going to attach invented numbers to it, no revenue figure, no order count, no funding round, because the honesty is the point and the lesson does not need a bigger number to be true. And I am not going to pretend it was a cute little side project, because the ambition was real and so was the failure.

The reason it could not scale is baked into everything I have described. A business whose coordination lives in human attention has a ceiling equal to the attention available. A business that still needs a person to take and place every order by hand can only handle as many as those people can process. A business that dispatches by memory strains a little more with every order instead of a little less. A business that runs on cash and floats carries risk and slowness on every transaction. A business that markets with flyers grows at the speed of paper. Each of those is a wall, and we were inside a room made entirely of them.

The cruel arithmetic of on-demand is that the model is supposed to get more efficient as it grows. Add more orders and, with the right software, each one costs less to coordinate, because the algorithm is doing the work and software scales for almost nothing. We had the opposite curve. Adding orders made every night harder, because there was no software absorbing the complexity, only people, and people are the most expensive and least scalable resource there is. We could grow to the edge of what a dedicated small team could physically do between 9pm and 3am, and not one order past it.

So what happened is what happens to a good idea running years ahead of its tools. It reached for real scale, ran hard against a cost structure that would not bend, and folded. It served a whole county for a couple of years and did the job it could do with the tools of the era, and it never crossed the gap from a hand-run operation into a scalable company, because the bridge across that gap is made of technology that had not been built. There was no dramatic collapse to narrate, no single villain, no fatal mistake I can point to and say if only I had done that differently. That absence of a single fatal mistake is what marks it as a timing story rather than an execution story. The failure was structural. It was in the calendar.

If there is one thing I want a founder to take from this section, it is that "we could not scale" is not always a confession of a bad team or a bad plan. Sometimes it is a diagnosis of bad timing. We could not scale because the machinery that turns proven demand into a growing marketplace did not exist for us to buy, rent, or build. The winners could scale because, by the time they started, that machinery was sitting on a shelf waiting for them. Same idea, same demand, same city, different decade, and the decade was the whole difference.

Two years of routes, ten-mile runs, and why it folded

We did not fold after launch week. We fought. Over the next couple of years I tried many things to make the operation work, and the most serious of them was building delivery routes, batching multiple trips together so a driver could handle several orders on one loop instead of one order per drive. Routing is the right instinct, it is exactly what modern platforms do automatically, but doing it by hand, without GPS or dispatch software, is slow and imperfect. We got better at it. We never got good enough, because the tool that makes batching actually work is software that watches every driver and every order in real time, and that we did not have.

Distance made it worse. Early on we were delivering from restaurants as far as ten miles away, out into the county, in New Jersey traffic. A ten-mile run in central Jersey is not a quick hop, it is a long, expensive trip that ties up a paid driver and a tank of gas for a single order. Every one of those long runs was a small money-loser, and in the early days we made a lot of them, before we understood how tightly you have to control distance to keep a delivery economical. Routes helped. Distance still hurt.

Underneath all the tactical fixes, the cost structure never changed, and that is what finally decided it. We were carrying high fixed payroll from the idle-driver model, office rent, and a steady bleed of costs nobody thinks about until they are paying them: insulated delivery bags, supplies, cards, phones, gas. Revenue was a five-dollar fee plus a negotiated spread. Costs were fixed and constant. Without the technology that arrived with the smartphone, the apps, the GPS, the real-time dispatch, the gig-labor supply, the mobile payments, there was no version of this that got cheaper as it grew. So it stayed expensive, and expensive plus small is a business on a clock.

A few years after I started it, RuDeliver had to fold. There was no single catastrophe, no dramatic blowup. It ran out of a way to be sustainable, because the machinery that would have made it sustainable did not exist yet and would not for years. I had tried the routes, tried to control the distances, tried to hold the whole thing together by hand through two years of grind. What I could not do was manufacture, out of effort, the technology stack the business actually needed. That stack showed up later, in someone else's hands, and built the company I had been trying to build too soon.

The real cost of being early: you fund the market

There is an expensive truth about being too early that nobody warns you about. When you are early, you do not just fail. You pay to prepare the market for the company that succeeds after you. You spend your years and your money proving the demand is real, teaching customers the new behavior, and discovering all the ways the thing is hard. Then the next entrant, the one with the technological tailwind, walks into a market you warmed up and harvests it. You paid the R&D bill for an industry, and the receipt has someone else's name on it.

Every early company in a category does this unpaid work. They answer the question "will people even want this?" so definitively that by the time the timing is right, no later founder or investor has to wonder. They train the first customers to trust a new behavior, so the behavior feels normal by the time the winners scale it. They map the operational potholes the hard way, by hitting them. All of that is real value created, and almost none of it is captured by the company that created it, because capturing value requires the infrastructure to scale, and the early company is early precisely because that infrastructure is missing.

This pattern is old and well documented, and the dot-com era is full of it. Webvan, the online grocery delivery company that raised and spent enormous sums and went bankrupt in 2001, was chasing a version of the future that arrived and worked years later, once broadband, smartphones, logistics software, and consumer habits had all matured. Kozmo.com, which promised rapid on-demand delivery of small goods in cities around the same time, burned out for similar reasons: the demand was plausible and the enabling economics and technology were not there yet. Neither company was foolish. Both were early, and early wrote the tuition check for the schools that graduated later.

I put RuDeliver, humbly and at a much smaller scale, in the same family of stories. We were not raising Webvan money or making Webvan headlines. We were a county delivery company run by hand. But the shape of the lesson is identical. We proved, in our small way, that late-night on-demand food delivery was something people wanted enough to pay a fee for, and we proved it years before the tools existed to serve that want at scale. The demand we validated was validated again, and captured, by companies that started once the stack was ready. That is the cost of being early. You do the proving, and someone else does the winning.

The reason this matters for you, reading this, is that "being early" gets romanticized. Founders wear it as a badge, first mover, ahead of the curve, visionary. Sometimes it is a badge. Often it is a bill. Before you take pride in being years ahead of everyone, ask a colder question: am I ahead because I saw something they did not, or am I ahead because it is not actually possible yet and they are wise enough to wait? If it is the second, the years you spend out front are not a lead. They are you, generously and expensively, preparing the ground for whoever shows up on time.

Why now: the most underrated question in startups

Good investors have a question they ask that most founders underweight, and it is not "is this a big market" or "is this a good team." It is "why now?" Why is this the right moment for this specific thing to exist? What changed recently, or is about to change, that makes possible today what was impossible a few years ago and would be crowded a few years from now? A strong "why now" is usually a recent shift in technology, cost, behavior, or regulation that opens a window. A weak "why now" is a founder insisting the timing is right because they want it to be.

If I had known to ask myself "why now?" in 2006 and answered it honestly, RuDeliver would have failed the test on the spot. Why 2006? The true answer was that I was a hungry student who saw an obvious unmet need, which is a real "why me" and a real "why this," but it is not a "why now." Nothing had recently changed to make on-demand food delivery newly possible. No new device, no new network, no new payment rail, no new behavior. The window I thought I saw was not open yet. I was pushing on a door that would not open for years, and mistaking my own certainty for the door giving way.

A strong "why now" for on-demand delivery did eventually exist, and you can date it precisely. By around 2013, the answer to "why now?" was overwhelming: everyone was carrying a smartphone, app stores were mature, phone GPS and mapping were standard, digital payment was trivial, an on-demand gig-driver model had been proven by Uber, and cloud infrastructure had made real-time logistics cheap. That is a "why now" with six parts, each of them a recent change that turned an impossible business into an inevitable one. DoorDash did not have a better idea than I did in 2006. It had a "why now" that I did not have, because the changes that make up a good "why now" had all happened by the time it started.

The practical value of the question is that it forces you to name the change, out loud, specifically. Not "the time feels right." Not "the market is ready." Name the shift. What is different now? If you can point to a concrete, recent, durable change, a new platform, a collapsed cost curve, a new consumer habit, a new rule, then you may genuinely be on time. If your best answer is that the idea is good and you are motivated, you have described a "why me," not a "why now," and a good "why me" without a "why now" is the recipe for being early.

I ask this question of every idea now, my own and other people's, before I ask almost anything else. Is the enabling technology in place, or arriving in real time, or still years out? What specifically changed to open this window, and is the window actually open or just something I badly want to be open? The answer does not have to be a yes to make an idea worth loving. But if the answer is no, you should know that you are choosing to be early, and you should count the cost of that choice with your eyes open, because early is a real strategy only if you can afford to wait for the world to catch up.

How to tell if your startup is too early

So how do you actually diagnose it, from the inside, before you spend years finding out the hard way? Being too early is difficult to see precisely because it feels like being a visionary. The signals look like virtues. You are the only one doing it, which feels like an edge. Customers love the demo, which feels like validation. You are building something genuinely new, which feels like the whole point of a startup. Each of those good feelings can be a warning sign in disguise, and here is how I now tell the difference.

The first test is the infrastructure test. Is the enabling technology your product depends on actually in place today, or are you quietly assuming it will show up? Make a list of every capability your product needs to work at scale, the way I should have listed smartphones, app stores, GPS, payments, and a driver network. Then check each one honestly. If your product needs several things that do not exist yet, you are not running a startup, you are running a research project betting on a future that has not arrived, and you should price that bet accordingly.

The second test is the "am I building three things at once" test. A healthy startup builds the product and finds the market. A too-early startup is forced to build the product, create the market, and invent the infrastructure all at the same time, because none of those exist yet. That is three companies' worth of work funded by one company's runway. If you look at your roadmap and realize you are not just building your thing but also educating an entire market that has never heard of the category and constructing the technical foundation the category needs, the load is not a sign of ambition. It is a sign of bad timing.

The third test is the loneliness test, and it is the subtle one. If you are the only company doing this, ask honestly why. There are two possible reasons, and they lead to opposite outcomes. Either you are first because you saw something real that others missed, which is the good kind of alone, or you are alone because it is not actually possible yet and everyone else is sensibly waiting for the tools, which is the dangerous kind of alone. The way to tell them apart is to look for the enabling change: if you can point to a recent shift that opened the door and you simply moved faster than the pack, you are early in the good way. If you cannot, your solitude is a verdict, not a moat.

Run all three tests together and the picture is usually honest. If the infrastructure is missing, you are building three things at once, and you are alone with no recent change to explain it, you are too early, and no amount of talent or effort will fix that, because the missing ingredient is time. That is not a reason to abandon the idea. It is a reason to change your relationship to it: to keep it warm, to watch for the enabling shift, and to be ready to move when the "why now" finally arrives, instead of exhausting yourself trying to drag the future into the present by hand. Being right early is only worth something if you are still standing when the timing catches up.

Too early versus first but on time

There is a companion story to this one on my blog, and reading them together is the best way to understand what timing really costs, because the two failures look similar and have opposite causes. That story is about the Ideal Card, an NFC business card I helped build. There, I was first to market and I lost the lead anyway, but the reason was completely different from RuDeliver, and the difference is the whole point.

With the Ideal Card, the enabling technology existed. NFC chips were in phones, the web could host a live profile, and the pieces were all on the shelf. We were first because we moved first, not because we were ahead of the possible. We lost the lead there to complacency: we had a real head start with the tools already in hand, and we let competitors who came later out-work us on the boring, relentless job of building a brand. That is a story about squandering a lead you legitimately had. The tools were ready and we relaxed.

RuDeliver is the opposite failure. Here the tools were not ready, and no amount of hunger or focus would have made them ready, because you cannot out-hustle a smartphone that has not been invented. With the Ideal Card, the ground was firm and I got lazy standing on it. With RuDeliver, the ground had not been poured and I kept trying to build anyway. Both stories end with someone else winning, but one is a discipline failure and the other is a timing failure, and the fixes are nothing alike. You fix complacency with focus and effort. You cannot fix bad timing with anything except a different year.

Sitting side by side, they teach the two questions you have to get right, in order. First: is the timing right? Is the enabling technology in place so that effort can actually compound? If the answer is no, focus will not save you, and RuDeliver is the proof. Second, and only if the first answer is yes: are you willing to do the relentless, unglamorous work to keep a lead the timing has made available? If the answer is no, the timing will not save you either, and the Ideal Card is the proof. Timing gets you a game worth playing. Effort wins the game. You need both, and you need them in that order, because effort spent before the timing is right is the most expensive kind of wasted work there is.

The table below lays the two failures against a third case, the on-time winner who does both things right, so you can see all three at once. Read across the rows and the lesson is stark: right idea, wrong timing loses even with maximum effort; right idea, right timing, low effort loses to a hungrier competitor; and right idea, right timing, high effort is the only combination that actually wins. I have personally lived the first two. This whole article, and its companion, exist so you can skip the tuition I paid for both.

What I would do differently, and a warning

If I could hand the 2006 version of myself a note, it would not say give up on the idea, because the idea was right and the demand was real. It would say change your relationship to time. Stop trying to force a future that has not arrived, and start positioning to move the instant it does. There are things a founder who is early can do that are far smarter than exhausting themselves building an entire missing stack by hand, and I did none of them, because I did not yet understand that the enemy was the calendar and not my own effort.

The first thing I would do differently is name the missing pieces explicitly and watch them like a hawk. If I had written down "this business needs smartphones, an app store, phone GPS, easy payments, and an on-demand driver network," I would have had a checklist of exactly what to watch for. When the iPhone launched in 2007, I would have known it was the first domino, not just a shiny gadget. I would have been reading the arrival of each enabling technology as the market timer it actually was, instead of grinding through nights unaware that the thing that would decide my fate was being built somewhere else.

The second thing I would do differently is match the burn to the era instead of trying to force full scale before the tools existed. I poured myself and the company's money into growing a countywide, two-segment delivery business, tens of drivers and fifty-plus restaurants, when the machinery to run that at a profit had not been built. The mistake was not the ambition. The mistake was spending everything to scale something that structurally could not scale yet, instead of running lean, protecting the runway, and keeping the brand and the customer relationships alive until the enabling stack arrived and the window opened. Position, then pounce. I tried to pounce before there was anything to land on.

The third thing, and the most important, is that I would ask "why now?" of everything, forever, and I do. Before I fall in love with an idea, before I spend a year of my life on it, I make myself name the recent, concrete change that makes it possible right now. If I cannot name one, I do not necessarily walk away, but I know I am choosing to be early, and I count that cost honestly. Being early is a real strategy, but only for people who can afford to wait for the world to catch up, and who position themselves to win when it does rather than burning out trying to drag it forward.

So here is my warning to founders, the one I wish someone had given me. The idea being right is not enough. The demand being real is not enough. Your effort being total is not enough. If the infrastructure your idea depends on does not exist yet, you are early, and early is indistinguishable from wrong, because both of them fail to ship something the world can use, and both of them hand the prize to whoever arrives on time. Ask why now before you ask anything else. Name the change that opens the window. And if the window is not open, do not spend your life throwing yourself against the glass. Keep the idea warm, watch the timer, and be ready to run the moment it is. I built food delivery in 2006, and timing beat me. Do not let it beat you the same way.