Curbside pickup - How we invented it, but blew our lead

Prologue

This is a story about a startup that dominated my life from 2012-2014, pioneering order-ahead with curbside pickup for restaurants and retail stores, with a perfectly-timed handoff coordinated by mobile apps.

Today, there’s no question that curbside pickup is a winning idea. It’s ubiquitous. I can’t go anywhere online or around town anymore without seeing reminders that curbside pickup is a thing, and I could be using it. Which I don’t actually! Maybe because every time I see it, I feel a very odd mix of emotions.

In a way, it feels validating, but at the same time, it’s tinged with regret, after three tough years at this startup attempting to catalyze the concept, knowing deep in my bones the idea was a winner, silently fighting an uphill battle in the shadows of Amazon’s rising skyline.

I was neither the Founder of this startup nor its first CTO. I was officially hired as Lead Engineer before becoming CTO or “acting” CTO in 2013.

Tragically, (see: Founder’s Syndrome), the Founder with the brilliant idea at the right time was also the wrong person to run his own company. To his credit, he more-or-less admitted this, though it was still a problem. I wasn’t coveting his job, but it was painful to live through numerous rookie mistakes I would not have made myself. I tried to give him the best possible advice, advice that would have been transformative for the company, and both of us suffered when it was ignored.

I wish I could tell you a story of runaway success, or the scrappy success I was doggedly determined to achieve until the bitter end. We did accomplish a lot, especially for a tiny team, but overall, the company did more things wrong than right during this three year period. We left the starting line at the right time, with many of the ingredients critical for success. But we were an underfunded startup with poor product-market fit (more on that below), roughly zero marketing budget, and miniscule transaction volume. Our pathways to some kind of grand success kept narrowing.

Curbside beat us to market, partnering with Target

About a year after we started, another startup called Curbside with exactly the same idea, but dramatically more effective leadership, appears to have done every aspect of this better than we did. Curbside took off like a rocket, while ours was sputtering on the launch pad and leaking fuel when I walked away.

After a false start in 2012, we created in 2013 what may have been the world’s first commercial curbside pickup service. We (actually, mostly I) built mobile app and back-end services from the ground up, and we launched them with dozens of restaurants and retail partners in Seattle.

We were technically “beta” at the time, but there were people running real transactions through our apps well before the April, 2014 launch at the Sunnyvale Target by the better-funded (and better run!) Curbside.

Our company got started roughly a year earlier, but we blew that year with the Founder’s poor choice for CTO. We then blew our second chance in 2013, when the Founder CEO failed to hire, or failed to retain, specific people we’d identified for key positions, which would have been transformative for the company’s prospects.

Then, for a large portion of 2013 I comprised the entire engineering team, and we didn’t really have a product manager so I was splitting that role with the person in charge of sales.

When we finally did expand the team in 2014, the Founder focused on minimizing costs rather than maximizing benefits, making hiring decisions that slowed us down instead of accelerating us. I was still bringing the new hires up to speed on our codebase and tech stack when Curbside launched.

Curbside won the race to plant a flag in this new realm with a high-profile launch partner, Target. Curbside quickly scaled to many locations, and a million transactions, while we were still doing a beta pizza here, a beta dog toy there, and spinning in circles on our go-to-market strategy.

Now the idea was validated in the real world, and it was safe to assume it would be a hit, it would be promoted, and widely replicated by others. Despite this huge development, we remained in stealth mode.

Still stealth?

My aim here is to share lessons from this experience, while steering clear of personally identifiable criticism. When I walked away after three years, after calmly speaking my truth to the leadership, such as it was, I made a conscious decision not to publicly air any grievances, which isn’t my style anyway.

It’s inherently hard to depersonalize an early stage startup cited by name, so I’ve decided not to name this one. I don’t mean to be mysterious. Maybe you heard of it, maybe you haven’t. You probably haven’t, because it isn’t a household name, like Postmates or Uber Eats.

After I left, the remaining engineers carried on, with help from new hires. During that time, I couldn’t share my own experience without talking about a going concern - and former employer - that was still trying to make it.

The people I refer to generically here are actual people, each of whom has an individual perspective that differs from mine. I presume they tell their stories in their own ways.

When I left, I wasn’t sure how to tell my story. It took some time for me to process this intense, extended experience. Now it is long past time to share it. It has a beginning, a muddle, and an end. Let’s start here:

The concept stage

Opening scene: Fuel Coffee, Seattle, February 2012

Having co-founded my first startup at 13, I caught the startup bug again in 2012, when I was introduced to an individual I’ll call “The Founder” with a capital F, rather than by name. We were introduced by someone who thought my background would be perfect for what the Founder envisioned.

We met at a quiet neighborhood cafe, a better place for a post-NDA conversation than the buzzing Starbucks in Madison Park. He described a novel idea that had come to him in a flash. It was basically just a slide deck and scribbles on a pad at this point.

But we talked it through sotto voce, and the idea was gold: Turn any restaurant or retail business into a drive-thru, with nothing more than curb space and an app. Order ahead, and pick up at the curb with a perfectly timed handoff straight into your hands or the trunk of your car. Facilitate business-to-consumer logistics, and take a piece of the action.

We were having the conversation in the middle of a vast pool of tech-savvy consumers with disposable income, stuck in terrible traffic with dogs and kids and nowhere to park and usually rushed for time. Curbside pickup would have high intrinsic value for these consumers, while delivering a competitive advantage to brick-and-mortar businesses who provide it.

It was a heady feeling, listening to the Founder describe such a novel concept at once so simple, and so feasible. I listened, took it in, occasionally interjecting, “I’ve heard a lot of ideas, and this is an exceptionally good idea.”

We kept talking, riffing on the concept, how it could work, and ways to turn it into a business. Each conversation led to the next, and I would soon join this early stage startup.

Kickoff

At this point, the startup consisted of the Founder, some patent applications in the works, a modest sum or flow of seed capital, and one other person who had just come on board as CTO. The Founder was not an engineer. The CTO was an CS PhD who did know how to code and had some other startup and management roles on his resume, but he was somewhat academic, and by his own admission, wasn’t primarily an engineer. None of us had published a mobile app before.

I was fresh out of being schooled in modern web development and a variety of open source tools, JavaScript, Git, Ubuntu Linux, Node, Express, AWS, etc. from my job at Walk Score. I was an engineer on Dinerware before that, a leading restaurant touch-screen point-of-sale system, in a closely related space to curbside pickup.

I was enthusiastic, and the Founder was ready to take the leap. My joining the company effectively kicked things off for real.

Going local

Way back in 1998, in the boom days of the first dot-com bubble, there was a startup called Kozmo that promised one-hour free delivery of certain locally purchased goods. This is a great concept that is hard to do well, and Kozmo ended up flaming out. Hiring people to fan out to every dark corner of every town is a really big lift. Today, Amazon is a logistics empire, but they have over a million employees. It’s logistically way easier, in contrast, to be in one place and have your customers come to you, as traditional restaurants and retail stores do.

Curbside pickup is essentially just the modern version of a drive-through, in which you order before you arrive. The drive-through is an American invention that caters to a deep societal desire for convenience and instant satisfaction. Not getting out of a car is very convenient, especially when there’s nowhere to park, you’re in a hurry (and who isn’t), it’s raining or snowing or freezing or blowing, your kids are sleeping in the car, you’ve got the dogs, etc. All this was true long before the pandemic, which of course gave everyone one more reason to avoid unnecessarily entering a building.

At the time, Amazon was on the ascent, and traditional brick-and-mortar retail was on the run. I’ve been buying stuff from Amazon since 1997, but I loved the idea of a platform that made it easier for consumers to support their favorite local stores and restaurants, which may even be locally owned, and for local stores and restaurants to serve more customers, more efficiently. The concept would obviously work just as well for large chain retailers. Curbside pickup seemed like a real business opportunity that Amazon itself was likely to ignore, since it didn’t fit their model.

Platform play

The plan from the start was to be a platform specializing in curbside pickup.

We’d build separate mobile apps for the buyers and merchants, like Uber has a rider app and a driver app. With the app, buyers could initiate the experience, and then complete it automatically by simply driving up.

We’d also provide an API that merchant point-of-sale (POS) systems could use to pass orders to us. Of course, those merchants are enormously diverse, from single proprietorships to chain restaurants to big box stores and everything in between. The platform would amass a lot of customer data, and could leverage that in various ways, such as using machine learning to get good at predicting order prep times, arrival times, etc. We knew that all the private data we’d collect on people’s travel and purchase habits could potentially be a goldmine, eventually, a practice that is less in vogue today than it was back then.

The proposed business model was to funnel transactions through our platform in order to retain some sort of fee, and to sell a subscription service to the merchants. The buyers would not be required to pay anything extra.

I was certain that curbside pickup would soon become a phenomenon whether we catalyzed it or not, because it had real utility and wasn’t all that hard to do. Restaurants and retailers would have to staff and operate a bit differently to support this.

It then occurred to me that all these Uber cars driving around would be perfect for picking up these orders and shuttling them to people. I thought, if we can solve the restaurant/retail end of this, we’d potentially be attractive as an acquisition target for a company like Uber. There seemed to be an opening. They didn’t seem to be focused on this problem.

My instinct was correct. Uber Eats was founded August, 2014 and hit $5 billion in revenue in 2020.

The Founder with a feature phone

Oddly enough in 2012, but then continuing into 2013 and 2014, the Founder retained a proud, quirky attachment to his old school feature phone, avoiding the iPhone and all the Android models as well. It was not because he could not afford a smartphone. I won’t speculate on the real reasons, which venture towards the personal, but this should have been a red flag.

The Founder had many personal connections and “angel investor” kind of money, something like a trust fund. He had the kind of money that could seed a startup, but not enough to self-fund the whole shebang, unless the startup could bootstrap itself.

Old school take-out by phoning up the restaurant

In the traditional model for take-out orders, before curbside pickup, before order ahead and pick up in store, you call a restaurant on the phone, and hopefully, a human being answers. They may ask you to hold.

And then they take your order. You have an opportunity to ask questions about the menu, pricing, availability, options, prep time, etc. as you place your order, but you may feel rushed and there’s often background noise. You might pull out a pizza-stained coupon from last time you did takeout. If you were really high-tech, you might download a pixelated menu from their website… hopefully before you made the call, because you’re on an iPhone with Verizon prior to 2014 without simultaneous voice and data, D’oh!

The person who took the order would then tell you a time estimate, like 15 minutes, which was generally a guess. You’d then show up at roughly the prescribed time, and maybe you’d wait awkwardly inside, if they were still prepping the order.

It was usually at this time that you would whip out a wad of cash or a credit card, maybe they would swipe it, you would sign it, and you would grab your order and head back out across the rainy, windswept parking lot with your hot (but rapidly cooling) food in hand.

This voice-order, enter-the-building protocol was the still basically the only way to do take-out for a whole lot of restaurants in 2012.

Improving on the traditional model

It was easy to imagine rapidly improving from the baseline of voice-order, manual take-out. Here are three obvious ways:

• Present a higher quality, browsable, searchable, personalized menu in the context of a well-designed app.
• Take care of the payment before you get there, hopefully without having to re-enter payment information.
• Have someone carry it out to your car (or bike etc.) so you never even have to park and go in.

New services such as GrubHub and Snapfinger were solving the menu problem, and, increasingly, the ordering and payment problems as well, for at least some of the restaurants, but there were on the order of a million restaurants nationwide, and most were not online at all.

These other startups hadn’t thought of the curbside pickup idea, but it wouldn’t have been too hard to implement as an add-on to their existing services and apps. They already had all these restaurant relationships, buyer and merchant apps and ordering and menus. They were very close. And they had far, far more resources than we did.

Nobody likes to wait

Our problem was sort of the inverse of the Uber/Lyft pickup problem. With rideshare, the service comes to you. With curbside pickup, the customer is the mobile one, generally coming to a fixed location such as a restaurant or retail store.

Everyone knew that something had to give when you ask existing retail or restaurant staff already pressed for time to do this extra work for potentially lower tips. The hope was that curbside pickup would boost the overall business, and they could hire more people.

But it’s still inefficient to pay employees to linger outside a restaurant while a customer is supposedly en route for pickup.

Nor is it a great customer experience to make the people picking up linger in the car for someone to emerge with the goods (while occupying potentially limited parking space.)

Nobody likes to wait. The magic is to have someone already there when you arrive, or, even better, just stepping out as you pull up, fresh hot order in hand.

Our way to deliver that magic was to track customer locations with a mobile app, and use a heuristic or machine learning approach to predict and refine arrival times. By 2012, smartphones reached 50% penetration, and they were pretty ubiquitous in places like Seattle, our home base. There was no part of this for which the technology was missing.

A visit to the Founder’s other startup

The Founder had previously put a lot of his own money into a VC-backed Seattle company providing single click (single tap?) mobile payment services, a couple of years before Square and Stripe launched. They had some good ideas, but it was more work than they expected, with higher security costs. Worse, it was yielding lower sales than they’d counted on, and when they had a deficit of good news, that cut off the funding spigot. The company was supposed to revolutionize payments, but by the time I saw it, it was well on its way to not paying its own bills.

I had the opportunity to visit their fancy pad down in Pioneer Square with the Founder as the spending spree was winding down in 2012. Top-floor office, big monitors, big view, big vision, modern furniture, vintage loft.

I got wind that the business prospects were worse than most of these people knew on that day. By the time I saw the place, some desks were already empty. When we walked in, it felt like arriving just before the end of a party, when a lot of guests had gone, everyone now fit around one big table with half empty glasses, the hosts were looking tired, and some people needed a ride home. The meeting was ostensibly to explore using their technology for payments, but some of them were clearly angling for a new job, which didn’t indicate confidence in the platform.

The party was truly over later that year. Smarting from that bad investment, and frugal by nature, the Founder emerged with an unyielding impulse to economize the next time around.

Diner, where?

Restaurant take-out was the single most obvious use case for curbside pickup. I had previously worked for what was then, at least in the Pacific Northwest, the top-selling restaurant point-of-sale system, Dinerware. I had intimate knowledge of it from an engineering role in 2009-2010 that was still fresh. I had known Dinerware’s brilliant and visionary founder, Carl English, since we had worked together on Microsoft Works. I had witnessed Dinerware’s journey from zero to number one. I knew the team at Dinerware, including an outstanding lead PM.

The Founder of this curbside pickup startup saw my Dinerware role as relevant when making the decision to hire me, but inexplicably declined to leverage it, once I walked in the door. He failed to intuit the potential of partnering with a leading point-of-sale system that already had all the menus onboarded, and already took care of all the ordering and payments. My familiarity with it was like a secret weapon that could have been exploited to gain an advantage on other startups that had much more funding and a massive head start. I felt almost guilty for having such an advantage, it was so unfair.

Dinerware had a network of field sales reps all over the US, and longstanding restaurant partnerships from single sites to regional chains in every category. Even if you were rolling around with suitcases of money (which we were not) you could not buy the kind of small business relationships, trust and widespread market acceptance Dinerware had labored to build over many years.

Restaurant and retail operations is a world unto itself. It takes quite the combination of naïveté and hubris to believe that you can waltz in with essentially zero real-world industry expertise, embed some new technology (the one we proposed to build) that solves one new problem in relative isolation, and have every other piece of the puzzle magically and instantly reorganize around it, but that’s essentially the strategy the CEO and CTO were both inclined to pursue.

Because of my NDA and the Founder’s fears about our curbside pickup idea being ripped off before we could implement it, I was not at liberty to close the loop with the Dinerware people. What I wanted to do was get the Dinerware people to have a substantive conversation with the Founder of my startup on the business and operations of restaurants and the POS landscape, and start to explore how curbside pickup could be integrated into Dinerware. Dinerware was built to be extensible so it could evolve into a conversation about how to build some kind of add-on that could even be offered through their own sales channels.

I’m not sure why the Founder did not pursue this partnership opportunity thoroughly. It’s not like he didn’t have time. I think he didn’t intuit or understand the extent to which the bar for user expectations was simultaneously being raised for online ordering and food delivery. If you want “hockey stick growth” for your startup, skate to where the puck is going, not where it has been.

What about privacy?

When customers share private information such as real-time location with a third-party service, they have a right to know: What do you intend to do with my data? These days, Apple, a global leader on privacy, requires app developers to be up front about privacy practices, and rightly so.

We didn’t really need to know where the customers were en route, except to estimate their arrival time, and that was really just for synchronizing pickups. It did occur to us that the data we would collect on customer ordering and pickup habits would potentially be worth a lot to some other parties for marketing and other nefarious purposes. We had a general habit of recording everything that ever happened in our universe, a practice that creates a stream of privacy issues. I was personally committed to using the data ethically, but we made no specific promises. These days, that’s not enough.

Mobile platforms

Sidebar: Why we ignored Windows Phone

We lived in Microsoft’s home town. So Windows Phone (previously Windows Mobile) was definitely on our radar.

Our startup’s 2012 CTO was more enamored than I with Microsoft tools and platforms, even though I was the one who had worked there for years. By then, it was abundantly clear (to me at least, but clearly not to Microsoft) that iPhone and Android would, together, completely dominate the new mobile era. By 2012, the war was effectively over for Microsoft, but they were in deep denial.

I actually thought it was over two years earlier, in 2010, when Microsoft rolled out the Microsoft Kin phones, while Apple was busy rolling out… the iPad. Let’s see, looking back, which of these products had a bigger impact? Ouch.

To me, the decision to bring the absurdly ill-advised Kin phones to market telegraphed Microsoft’s panic, desperation and lack of conviction. I knew they would struggle to compete with Apple even if they focused 100% of their efforts from the start, but they were hedging their own bets. Microsoft could not even consistently commit themselves to a coherent mobile platform strategy, so what were developers like us supposed to do? I saw Blackberry and the Windows Phone as the walking dead, and Kin as DOA.

Year after year, from both inside and outside the company, it was simply astounding to watch Microsoft slowly burn a decade-plus head start in pocketable touch-screen Internet-connected smartphones. Way, way back in 2000, I had a Pocket PC Phone running a Microsoft OS with a touch screen and a web browser, plus mini Office apps, IM, email and even games. It was pricey, slow and glitchy, but it all basically worked and you could see the potential.

Then, in the half decade before the iPhone, Microsoft made a mystifying sequence of decisions, took a big step back from touch screens, and produced nothing more than a dribble of incremental, inconsequential Windows Mobile updates, practically nothing… kind of like Microsoft Internet Explorer 6.0 in the same period, 2001-2006. It was a fallow period that defies a simple explanation (cough-SteveB-cough), when Microsoft seemed to back away from their prior vision.

If you ran into me at a Seattle bar during this time, you would have gotten an earful about how Microsoft was completely, unbelievably, utterly blowing it in mobile. But, I kept saying, you know who should build a phone? Apple should build a phone!

In 2007, when Apple launched the iPhone and Steve Ballmer laughed it off on camera while criticizing its price, my jaw dropped. I thought, that’s it, this confirms it, it’s game over when it should have been game on. I knew at that moment I was witnessing Microsoft in the process of ceding leadership in the post-PC era of the next decade. This is what you say when you are threatened and you have nothing to show. The alternative explanation was that Ballmer was being sincere in dismissing the iPhone, and didn’t even take the threat seriously himself. Either interpretation meant certain doom for Microsoft’s mobile ambitions.

Even though Microsoft was yet to launch the much vaunted Windows Phone 8 when we were crafting a platform strategy for this startup in Spring 2012, I didn’t see how they could ever catch up to Apple or Android. The success of both of these platforms proved the inconvenient truth for Microsoft that should really have been self-evident: that you didn’t have to be Windows, or be Windows-compatible, or look like Windows to be a successful mass-market smartphone OS. Looking like Windows was actually a liability.

Unlike the juggernaut days of the 1990s, this time, the economies of scale, the ecosystem effects, would not work for Microsoft as they did in the PC world. The Windows brand didn’t have such a caché in the new mobile realm. This should have been obvious if they took a sample of people who lived more than 10 miles out of Redmond, WA. Everyone outside of Microsoft knew that Windows actually had the opposite of a cool aura, which was not a popular message in the Microsoft executive suite. I thought the brand was tired and they should have made something called the Xphone… kind of like Xbox. But you know that wasn’t going to happen. I can still hear Ballmer’s booming voice at the Kingdome, fist in the air, shouting Windows, Windows, Windows!

By 2012, Apple and Android had already established a steady rhythm of positive feedback cycles with new devices and OS features inspiring new app developers. Consumers were bringing their favored devices into corporations, just like the PC had come in through the side door a generation before, which Microsoft’s senior leadership was old enough to have lived through. The Microsoft campus itself was filling up with iPhones!

I knew how Microsoft tended to react in the face of competitive threats. I knew the internal conflict and second guessing they always went through before doing anything that risked their hegemony, and I more or less knew thematically how those conflicts would ultimately be resolved. They would be resolved in favor of whatever approach protects and serves the Windows brand and ecosystem.

By the time Microsoft took the competitive threat seriously, it was too late. Microsoft tried hard to compete with Apple on UX refinement and hardware design, which is especially challenging coming from behind. But how do you compete with free (Android), when that free platform already has tons of apps and you have bupkis? And even more crucially: How do you compete for the attention of app developers with basically no installed base of users?

Despite the Windows branding, Windows Phone was basically starting from zero when it came to apps, and Microsoft literally couldn’t even bribe developers like us to target that platform when market forces naturally drew us to the platforms everyone else was using. Their email entreaties were poignant. They offered to throw money at developers, but they couldn’t have paid us to write a Windows Phone app, when there were essentially no users to target who weren’t Microsoft employees, many of whom had personal iPhones in addition to corporate-issued Windows Phones. On the rare occasions I saw a Windows Phone in the wild, I assumed its owner worked for Microsoft. I would see employees down at the bus stop with a blue badge and a Windows phone carrying a second, personal phone… usually an iPhone.

It was all sort of sad because you could see Microsoft was really trying by this point. For Microsoft, it sucks to be on the losing side of that Catch-22, but that’s life, and that was life with Apple products back when Windows was running roughshod over the PC market. I guess I shouldn’t feel too bad for a $2 trillion corporation.

When I ran into the Corporate Vice President of Windows Phone, my old buddy JoeB the drummer and Windows PM from Microsoft, at an Elvis Costello concert in Seattle in 2012, and he recognized me, I said something friendly like, “Hey Joe, great to see you! Enjoy the show!”, but I didn’t have the heart to yell out what I was really thinking, which was, “Hey Joe, I think your platform is doomed!” Sorry, Joe! We’re forever grateful for the Start Menu.

Dual platform: iOS and Android

We settled on a dual platform strategy for our mobile apps.

In 2012, as our startup was starting up, iPhone share was over 30%, skewed toward wealthier consumers who could spend more money on stuff like curbside pickup. We would definitely do an app for iPhone. But Android had a larger unit share, close to 50%, and it would make no sense to exclude the majority of consumers.

Instagram famously launched on iPhone first, but they finally launched their Android version just as we were having our platform discussion. We went in circles on the issue several times, but where we settled out was, we’d target iPhone and iPad first, with Android close behind. We’d aim to minimize the gap between them.

We figured we would need an actual mobile app for the consumers who were doing the pickup. This would relay location back to our servers to track the buyers in real time, to dynamically predict arrival times, which we would share with the merchants. We figured they’d run a distinct merchant app on their smartphones, or perhaps an iPad or Android tablet, coordinating their end of things.

We didn’t really talk about the 50% of the market that still had feature phones (like the Founder!) or how much we could quickly accomplish across the 100% of the phones that could send and receive text messages and phone calls, though I tried to initiate that conversation many times. We had no product manager.

So, we aimed to target both iPhone and Android with apps. Since Android phones were available at a lower price point, they would be easier to budget into restaurant and retail operations.

Engineering Phase 1

So here we were in 2012, an early stage startup, wanting to target two mobile platforms. React Native did not exist back then, nor React. We didn’t have the budget to hire two native app developers (like we should have!), and there were extremely few in the hiring pool anyway, most of whom would have charged more than our Founder CEO was willing to pay. Coming up to speed on native Android development, plus native iOS development, while simultaneously implementing 100% of the web presence and the back end sounded like a daunting proposition.

I’d faced the cross-platform problem multiple times before. Years earlier, I’d been a developer on Microsoft Works for the Mac, which was done the most expensive way: it was a completely separate codebase from the Windows version. After that, when I worked on Microsoft Bookshelf for the Mac, we used an internal cross-compiler technology and essentially ported the Windows version. That was a lot more efficient, even though it was hard to debug. Retaining native look and feel on the Mac despite some Windows code underneath required some extra effort on my part.

The cross-platform technology the first CTO selected in 2012 was PhoneGap, later known as Apache Cordova.

PhoneGap/Cordova - a reasonable choice in 2012

PhoneGap is a “hybrid” mobile app development framework that starts you off with a blank full-screen static web page, packaged up as an app, and you add things from there. With PhoneGap, we could use standard and familiar web technologies, JavaScript, HTML, CSS, and whatever libraries we wanted, to compose a UI. We could communicate with our server using a REST API. Basically, it’s a native app shell that opens a web view, with some included plug-ins to access device capabilities, such as geolocation.

Developers who knew web-based technologies used by PhoneGap were easier to find than native app developers. Our mobile apps and consumer-facing web sites could share code. Android and iOS apps would share code. This was not a bad way to get started, though it was folly to think this approach would spare us from many of the very same issues we would have faced just writing native apps.

JQuery Mobile - a lamentable choice

The CTO in 2012 was oddly enamored with the client-side library known as “JQuery Mobile”, a library I would have preferred not to use at all. At the time, particularly before React hit the scene, JQuery was the go-to library for direct manipulation of web pages on the client side. I always viewed it as an ungraceful but expedient way you might accomplish some localized immediate effect on a web page, but something you should generally try to minimize.

Because of JQuery’s lingering prominence in 2012, which was about to rapidly fade, the CTO perceived “JQuery Mobile” as the default, go-to choice for doing things on a web page in a mobile context. Everyone uses JQuery, and now we’re doing mobile, so… JQuery Mobile!

Unfortunately, this JQuery Mobile library did very little, very slowly, while imposing a straitjacket on our UI design. You could work around its constraints, but that was harder than just not using it in the first place.

The performance of this library in the context of a PhoneGap app on an iPhone in 2012 was abysmal. At one point I did some profiling, comparing it with direct manipulation through the DOM API, and the difference was night and day. But for some reason, the CTO defended his choice of JQuery Mobile to the last.

Windows on the back end in 2012

The original CTO was, by his own admission, not really an engineer, yet he had some strong opinions on our tech stack. He was personally somewhat familiar with the Microsoft tech stack consisting of Windows NT Server, SQL Server, ASP.NET, C#, and he had a bias in favor of the familiar. He was only somewhat familiar with JavaScript, unlike the experts I’d worked with at Walk Score. He hadn’t really worked on apps of any kind, mobile or desktop, mostly just academic and “enterprise” projects. He had no native mobile application development experience when we started, but neither did I. Experienced mobile devs were like unicorns at that time.

At Walk Score, I’d become a huge fan of Ubuntu Linux + NodeJS on the server side, and quite proficient and productive in that context. I saw no reason on a greenfield project such as this to invest in what I increasingly viewed as an expensive, bloated and slowly dying tech stack that offered no real advantages, other than maybe it was slightly easier to find Windows devs in the Seattle metro area at that time.

These Microsoft technologies introduced a lot of avoidable friction for our tiny team at a critical phase. Windows and a suite of apps had to be purchased, installed and licensed. We also needed Macs to create an iPhone app, so I was using a MacBook Pro with Parallels or Boot Camp and constantly switching between the two operating systems.

The dual platform engineering was a tax on my time. We gained nothing from using Windows, and we definitely wasted effort duplicating our own business logic, first in C# on the server side, and then again in JavaScript in our app, when we could have just used JavaScript across the board with the help of Node.

I had sold my candidacy in part on my versatility. I think if I had insisted on rejecting Windows up front, I probably would have been denied the job. I didn’t have a strong objective argument for rejecting Windows and C#, though I did have the intuition that the Windows stack would be clumsier for us, and would also make us less attractive as an employer or acquisition target.

By itself, Windows on the server-side would not have been so bad if the CTO hadn’t simultaneously saddled us with the Naked Objects framework. What’s that, you say?

Naked Objects - an emperor with no clothes

The 2012 CTO mandated that we use something called Restful Objects and the Naked Objects for .NET on the server side. You’ve probably never heard of it. I hadn’t heard of it myself, and haven’t since then.

Naked Objects used a “code first” approach to modeling data. On the server, we would write C# classes to model our data domain, naming and decorating things using conventions unique to this framework, and then we’d run a special tool that used .NET reflection to create an abstract domain model from that. From there, the system would automatically generate a REST API to access that domain, which is real slick until the moment your needs don’t align with that API, maybe somewhere around week three.

The system also generated an interactive form-based web app accessing the same data, something for which we had not identified a need at this time. Giving actual customers or support reps direct full access to our system database is not something we’d ever do. And for debugging, I didn’t really need a web-based UI.

The library used Microsoft’s .NET Entity Framework, which I’d used at Dinerware, to talk to SQL Server on the back end. The whole thing involved many layers of abstraction and marshaling of data, which yielded questionable performance, even at small scale. The underlying database schema had to rigidly conform to the oddball Naked Objects specification.

There were arguments in favor of tools like this. They were supposed to facilitate rapid application development. They were supposed to solve plumbing issues for us while giving us agility (ha!) in our domain modeling and predictability in our API. I see the appeal of the sales pitch. I was unconvinced we needed such a thing, and quite skeptical of these particular libraries, but it wasn’t my call to make.

Experience has taught me that while things like Naked Objects may seem like a silver bullet, the sales pitches tend to leave out the downsides that you are likely to experience with such layers. You lose a great deal of visibility and control when you delegate so many things at the very core of a system to such a framework. You introduce a huge, avoidable dependency. Maybe it buys you something, but that comes at a cost.

New issues arise. What happens to all your existing data when you add fields to your classes and the schema gets automatically extended? Er, that was sort of up to you. But that is a general and recurring problem, handled gracefully by many others. How would non-elementary queries perform with the schemas that were automatically generated by this system? Who knew. They weren’t making any promises.

These sorts of real world problems were basically ignored in the beautiful, idealized, academic world of Naked Objects. This layer turned out to be cumbersome for prototyping as well as pretty much unusable for production, yet the CTO had insisted we wholly adopt this mostly untested, little known framework for all the data modeling, data flows and APIs on our back end.

Imagine trying to run fast with an albatross wrapped around your front end (JQuery Mobile) and another albatross wrapped around your back end (Naked Objects Framework) at the same time. This did not go well.

For Naked Objects, you might say the emperor had had no clothes. Literally everything this framework did, I could have done manually, faster and more reliably by hand. The framework had bugs and quirks. The documentation was incomplete. The support was pretty close to one guy. The build process was slow and brittle. How do you do something as basic as initialize values in the database? It has to be done a certain, special way.

At the CTO’s insistence, we bet our whole system on a little-known, little-used, poorly-performing, semi-opaque framework. It was cumbersome to keep everything aligned when anything changed, and we lost a lot of time first trying to understand, and then trying to work around, the self-imposed limitations of this system.

The original CTO

Let me just say flat out, there’s nothing personal about any of this, but the original CTO was mismatched for that job, and on some level, I think he knew it. He could have leaned more heavily on me, but he was too proud and/or insecure, and he didn’t seem to fully value my experience and expertise. He was obviously smart, but he was neither a hotshot general purpose engineer nor a specialist in any technical or business realm directly relevant to our space. I was willing to work with him, but I would not have chosen him as CEO, CTO, COO, PM, engineering lead or even individual contributor for this startup at this phase.

It was somewhat tortuous for me to have come out of Walk Score having learned how to solve problems harder than ours, at scale, with free, open source tools that could run circles around all this stuff, and then having to work under someone who actively stands in the way of applying all these skills. I had to shake my head and bite my tongue. He’s sharp and I could have taught him in 3 months how to do most of what he would need to know, or I would have been happy to do it all myself (which I essentially did, the following year), but there was a lack of willingness and openness. I’m not sure where the excessive Microsoft fealty came from as he hadn’t even worked there. I think it was really a strong bias for the familiar, plus fear of the unknown.

I came to recognize his insistence upon using Naked Objects / Restful Objects as an instance of a larger pattern. The CTO was primarily academic. Unlike me, he did not have years of engineering experience on production apps and websites. He was attracted to technologies that promised to solve a lot of problems and take care of messy plumbing that he would prefer not to think deeply about.

He was not experienced at anticipating the downstream costs of additional layers or libraries we might incorporate. He did not understand common best practices of coding, how to build or run an engineering org of any size, how to ship real products… there is so much he did not know. He lacked a big picture view of the landscape of alternatives. His code was weak, and he held himself to low engineering standards, with wildly inconsistent styling and beginner mistakes. His code lacked separation of concerns, but he insisted on a separate server and API just for the location data, which introduced all sorts of avoidable work and server coordination issues in order to achieve a premature optimization. He would frequently copy and paste blocks of code rather than refactoring it, not just here and there, but as a habit.

His manner may have been humble, but his approach was ultimately unyielding. The CTO was in charge, and to him, that meant, he could do whatever he wanted, and he would be the ultimate arbiter of any technical decision, and the one to frame the conversation around next steps.

The CTO was enamored with Eric Reis and the Lean Startup movement, which recommends releasing the MVP, minimum viable product, as quickly as possible and iterating from there. I was on board with that.

There was a tension, however. The Founder wanted to surprise everyone with something awesome from day 1 and did not want to roll anything out until it was “ready”, but we kept going in circles and were not driving to a conclusion on what “ready” meant. We were developing a prototype in a vacuum. It seemed absurd that nobody was having product-level conversations with our potential business or consumer customers in this phase.

Months in, we still had no schedule or spec, yet we had running code for a significant feature set. The CTO seemed to receive the message that the drafting of a task list that had some dates attached to it would somehow tarnish the “lean startup” mojo we would otherwise have.

There was no product manager. The CTO resisted assigning product management type work to me, moving slowly himself. He eventually sent out some specs he authored solo that sort of reflected things we’d sort of talked through, but I was disappointed in the go-it-alone approach, and we kept redoing the designs, partly because they weren’t very good. We kept rethinking and rewriting basic flows.

We lacked even a graphic designer on contract to draw stuff like icons for us. We kept reaching out to different design firms, failing to really engage with any of them or allocate sufficient resources. Their resulting efforts failed to impress us, let alone anyone else, and in each case we moved on, having wasted more time and money.

The resistance to creating even a provisional dev schedule was baffling. I pointed out how I got reamed at Walk Score when I was 1 day late on a 3 day task I had been the one to estimate in the first place, whereas we didn’t even have time estimates, just deadlines that kept receding.

I repeatedly offered to draft a project schedule for review, which I’ve done a zillion times, and the CTO actively resisted. If we were meeting all our external expectations with some ad-hoc approach, that would have been one thing. We were not. The CTO claimed we were being “lean”, but it smelled territorial to me.

I thought, what are we afraid of here? I had managed project schedules for Microsoft, and taught Yale students how to do it, but now I can’t even draft one on my own team as “Lead Engineer”? Or choose the tech stack? What am I the “lead” of exactly?

The CTO said he’d make a schedule, but what he eventually produced lacked dates, dependencies, specificity, and intermediate milestones. It was essentially a high-level vision doc. It wasn’t a schedule!

Mid 2012

A contractor suddenly appears

I never saw or heard of a budget for our early stage startup, though the CTO and I were both being paid, at least for some time.

One day, the CTO basically air-dropped a new engineer onto the scene I had not had the opportunity to meet or interview in advance. This contractor was someone he knew before, a junior developer who knew some C# and ASP.NET, and had zero mobile experience.

The CTO had decided that this person would start work on our “Dashboard”, an idea we’d only vaguely tossed around, an administrative web site for the service we planned to run. The Dashboard could be used to configure merchants in the system, deal with support requests, sales reports, stuff like that. But we had no sales to report, no customers to support, no merchants to configure, and we weren’t even sure how things should work yet. And I thought one of the chief selling points of this PITA Naked Objects layer the CTO insisted upon was that it automatically gave us a web interface to our data, so… what problem are we trying to solve here? We hadn’t scoped it out.

Meanwhile, no offense to the individual, a nice guy, but I was aghast that I had not even been informed, let alone consulted, about whether, when, or whom to hire next for engineering. This is not just because my title was (almost comically, now) “Lead Engineer”. I thought, this is no way to build a team. And the CTO had seen my resume. He knew I had spent years screening, interviewing, hiring, mentoring and managing engineers. Theoretically, that helped me qualify for this position. And then, he’s not even going to ask for my opinion when it comes to hiring? What is that about?

This was a red flag. If we disagreed on strategy, or on a specific candidate, that would be one thing. But to deny me the chance to give any input was to send the unmistakable message that he saw no value in it, and saw no value in even appearing to care. Not only was that insulting, it was self-defeating. I did have value to add, a lot actually. And frankly, I would not have hired this person at that time. Maybe that’s why he didn’t ask me.

If we had the budget to hire anyone else (which nobody had told me), I would have looked hard for someone with iOS and/or Android mobile development experience. These people did exist. Sure, they might be hard to find in 2012, but we didn’t even try. The Internet existed, even back then. One posting would have produced candidates.

No ad went up. Instead, we got this one specific person whose primary skill set consisted of technologies the CTO was biased in favor of, and nothing else relevant to our problem space. And then, to make matters worse, this person was assigned something that had never been specced or even whiteboarded, let alone prioritized, because it didn’t serve a real need at that time. Was that supposed to make it OK that it wasn’t even scoped? All of this was putting a cart of red flags before an unborn horse.

And yet, here we were, in 2012, at a startup, writing mobile apps, quietly laboring to catalyze the phenomenon of coordinated curbside pickup, which did not yet exist, while actually being paid a salary. How cool was that? Too cool to walk away.

Paranoia

The Founder was paranoid about letting anyone outside the company know what we were working on. Sure, everyone is naturally hush-hush on their awesome new startup concept for some time. But when you perpetually have to speak in generalities, and can’t ever engage with others on the substance of an idea, it’s hard to get anyone excited. It’s hard to sell anything when you can’t talk, and have nothing to show.

If you are also exceptionally reluctant to yield equity or any control, it makes it harder to raise money. And if you are a startup unable or unwilling to offer some reasonably competitive combination of salary and equity, it’s really hard to hire the best people and build a great team. I mean, this is basic stuff, not something you should need an MBA for (which the Founder had, and I do not.)

Curbside pickup was an idea that was completely off the radar in 2012, but would not be for long. The Founder treated it like some kind of Manhattan Project whose very existence was secret. My LinkedIn page was updated to say, “Stealth Startup”. Ooo.

This stealth strategy succeeded in keeping us and our awesome idea off the radar, but that is only useful during a brief phase when you need to get a head start. Pretty soon, you need to launch something real so you can iterate and achieve “product/market fit”. But we kept placing artificial barriers in front of ourselves that repeatedly delayed this feedback cycle.

The Founder was paranoid that his idea would be stolen, and I became paranoid myself that we’d be beaten to market. With every passing month, I thought, the chance of us being the only ones working this problem are diminishing fast, and we are blowing the chance to be first. I’d anxiously code till the wee hours, waking up in a sweat, scanning the news to look for the announcement of someone else launching the same thing.

Founder getting restless

At one point, the Founder tried adding a Chief Operating Officer to the mix, a grownup who genuinely wanted to help and seemed like a more capable project manager than the Founder. We had some good conversations, but this person ended up essentially just documenting and communicating what we were doing, rather than identifying the root problems and addressing them. He seemed like a good guy but nothing really changed, and he soon disappeared. It seemed like an opportunity lost.

As we headed into the fall of 2012 without a launch in sight, the Founder was understandably getting restless. The CTO continued to resist any kind of written project schedule, but he did continue to add features that he thought were cool while I stayed the default course of trying to get all the basic flows working.

Fall 2012

A compass shows us losing our way

One day when I rode my motorscooter over to the CTO’s office (we worked in our respective basements), he proudly showed me a new feature we hadn’t discussed. It was a compass, so when the buyer arrived at the curb, the merchant would know where exactly to carry the goods, and the buyer would know where to look.

Never mind that there was probably only one small pickup area to target, and one door to emerge from with the goods, and the buyer is more likely to make eye contact if they are looking out the window instead of staring into their phone, and it wasn’t like we had buyers lining up to use a service that hadn’t launched. The compass wasn’t even the best way to solve that problem, and it wasn’t conceived as part of a larger picture, and we hadn’t discussed it, and it didn’t really work. Other than that it was a great idea!

I wondered if it was a sort of smokescreen, to shift the Founder’s focus away from the lack of real progress. It was beautifully ironic, the CTO’s gratuitous compass supposedly showing the way, while exemplifying how we were totally lacking in direction.

The compass was a distraction, but it was far from the only one. The CTO’s JavaScript coding style was consistently inconsistent. I thought, I don’t mean to be petty, but it’s easy to use consistent styling, and it reduces the cognitive load when you read code, which we do all the time. Maybe try at least?

But the CTO loved spaces and blank lines, as long as they were extra, and random in placement and number. Elsewhere, like where they would help readability, he tried to minimize them. I think he rested his hands on the space bar while thinking. I would go in and clean things up, but as soon he touched the code, it’s spaces everywhere. It was a Sisyphean task.

I tried to have rational conversations about how to collaborate efficiently, but the CTO was deflated that I didn’t respond better to his random contributions. Increasingly, I felt we were both wasting our time.

Phase 1 comes to a head

As 2012 drew to a close with no launch in sight, the Founder became understandably vexed. We were asked to explain how we had spent this much time with so little to show. A fair question!

I did not trash the CTO or blame everything on him, but I did “disagree and commit” on some decisions he made in favor of Windows on the server side, the Naked Objects layer, and JQuery Mobile on the client, and every one of these ended up biting us. I disagreed (but went along) with the CTOs decision to bring on the contractor for the low priority task. Some other decisions, I agreed with. I thought PhoneGap was useful. I tried to be even-handed.

But the CTO did not take criticisms well. He defended each choice, to the end. We had to agree to disagree. I had no personal issue with him. I thought he was a smart, good person with a fixed mindset who was in over his head in this role. But in the end, we both concluded we did not want to work together going forward.

Early 2013

Limbo

After the holidays, things went on ice for a little while as we cooled off and I pondered my next move. The regular salary came to an end. This was a big chance to run away, but I did not.

In early 2013, the original CTO was in a limbo state. When the Founder made it clear that we could not carry on with the status quo, the CTO half-agreed to shift to a more “research” oriented role involving machine learning on our data, which was full of interesting possibilities. It was one foot out the door. We’d agreed it was not required for our MVP, and the company didn’t have resources to spend on speculative long term stuff that only made sense at scale. He ended up essentially stepping down, and was not happy with the outcome. It was sort of sad. The Founder concluded he wasn’t right for the role, which was my take as well.

At this point, having blown another chunk of his own money, the Founder was ambivalent about continuing at all. I was too invested in the notion that this startup was a golden ticket to walk away from it now. I wasn’t going to let not getting paid stop me! I burned the midnight oil studying every technology relevant to our space. Moving away from Windows, I started building experiments with Node on Ubuntu Linux, with other databases like MongoDB, Backbone and other client-side libraries. I quickly found it to be a far more productive tech stack.

The Founder knew people, and there was always a small pool of would-be advisors buzzing around. There were always folks in the outer orbits who were trying to make their way to the inner circle. There were people who were essentially auditioning for some kind of COO, CMO, sales or business role floating in and out, and lots of far-ranging conversations. Everything was pretty fluid, and nobody was getting paid.

Conversations with investors

The Founder often reported on his conversations with investors. There was always a stream of personalities and possibilities in the pipeline, which invariably produced zero actual outside investment.

I wondered, why am I never meeting with any of these people? What we’re doing isn’t working, so maybe we should try something new. I’ve made a good impression on others. I had real world experience raising actual money for a startup myself. Does none of these investors care to meet me, or does the Founder not want me to meet them?

On one rare occasion, I got to meet a potential investor one-on-one, someone with multiple successful exits. Towards the end I asked him, what do you see as the biggest challenge or impediment for this startup? He answered with one word: undercapitalization. (My thought: Hey, you could fix that!)

This sounded sort of right, but more money would not have solved all of our problems. I think there was a problem even more fundamental, which was that the Founder was demanding a valuation he couldn’t justify without a product in the market that had actual paying customers. It was the classic bootstrapping problem. If he had been willing to offer a bit more equity to cofounders and new hires to get good people to work for lower compensation, that would have helped. But the Founder was so stingy with equity that the value of his own stake would ultimately suffer, even if he owned more shares.

There was no outside investment, and there were no partnerships.

The Product Manager we desperately needed

We desperately needed a product manager who intimately understood the space we wanted to bust into, and restaurant take-out was a core use case. As I had worked as an engineer on the Dinerware restaurant point-of-sale system and followed its story from day one, I knew a lot, but I also had a sense of what I didn’t know, which meant I also knew how ignorant everyone else on our tiny team was about how restaurants operate, and the overall point-of-sale realm. But, being the only person who sees a problem is a problem of its own.

There was a magic window of time where we had the opportunity to hire the excellent, experienced lead PM from Dinerware, Jesse Walmsley, in a graceful way that would not be problematic for his former employer and my other friends there. I knew it would be transformational for the company if he joined. I facilitated an introduction with the Founder.

There was some back and forth, and some talk about talking and maybe more, but in the end, no cigar. And so, there was no synergy between Dinerware and this curbside pickup startup, no add-ons, no learning, no new co-branding or sales opportunities. It didn’t happen.

There were also lots of other POS vendors, and other good people worth consulting, if you didn’t like my people. But our little startup did not pursue any kind of partnerships, or seek to hire anyone with industry expertise, or form an advisory board including such people. This is a self-defeating strategy for a B2B + B2C venture, perhaps explained only by the Founder’s extreme secrecy and trepidation.

Brian K, the 10x engineer

There was an engineering candidate we first heard of in fall 2012 by referral. When I saw his email to the Founder, I knew I wanted to meet him.

He was a recent UW CS grad who, like me at age 20, already had a long resume. He’d already been lead developer at two startups, one with NLP, another with ML. He’d built a distributed architecture in EC2 with his own API. He had built real time messaging apps. He knew JavaScript and all the web tech and various frameworks. He knew Objective-C and Java, native app development on iPhone and Android. He knew SQL and MongoDB. He’d consulted for large companies all over the world. His name: Brian K.

The original CTO slow-rolled the response, even though it was obvious to me this was exactly the kind of engineer we needed on board ASAP. Did he feel threatened?

When we finally did meet Brian K early in 2013, I showed him the code we had written, and I asked for his opinion.

In a matter-of-fact way, with neither hesitancy nor arrogance, he replied, you’re going to need to throw all of it away. The original CTO looked ashen. All of it, really? Yeah, he said. Start over. He then proceeded to describe how he would approach the problem.

I knew, this is a person who is going places. This is someone incredibly versatile who could scale smoothly from week 1 to year 5 at a company. You don’t meet people like this often. I’ve interviewed a zillion people. I could see, he had the right stuff.

He had a gift for clear, calm communication. He was well-spoken but unassuming, good-humored but serious, creative, full of insightful ideas. I got the sense he was in some ways a stronger engineer than I was. That wasn’t threatening, that’s what we were looking for! I figured, this is someone I could learn from.

Six months after we heard from him, in March 2013, he was close enough to signing a contract that we started talking through architectural issues, MongoDB, EC2, etc. By May of 2013, he had a contract in hand, and the original CTO was out.

I was now “in charge” at this point, but I viewed Brian K as a peer. The fact that I was over twice his age seemed to have zero impact. Our general approach, outlook and way of looking at problems could not possibly have been better aligned.

Mid/Late 2013 - Phase 2

A brief golden era, a glimpse of what could have been

Brian K came on board officially in May, 2013. Together, our productivity was like 20x what it had been with the original CTO. Within one week, we had enough scaffolding up to do a stream of location updates to the server with real-time messages flying in both directions over websockets. The Founder was blown away.

From there, throughout the summer, Brian K and I completely re-engineered the server and the apps on Android and iOS. We jettisoned Windows NT and Naked Objects and JQuery Mobile. We built a new system using AWS EC2, MongoDB, Node, PhoneGap / Cordova, and Backbone.

The Founder never properly valued Brian K’s contributions, and over the weeks and months of summer 2013, he started to disengage until he was finally officially out. I think the Founder probably lowballed him, as he did in general, and Brian K knew what he was worth. No amount of pleading or appreciation from me could make up for it.

At one point in summer 2013, the Founder got wind of a UW sophomore looking for a summer tech internship. The Founder was super interested until he found out that “intern” wasn’t the same as “free”, and then interest in the same individual suddenly dropped to zero. That tells you where he was at.

Meanwhile, Jaron Waldman, Founder/CEO of Curbside, the startup we didn’t know about yet doing basically the same thing, was burning rubber up and down Sand Hill Road. Based on results, he was more than 10x, maybe 100x more effective at raising money and building a high-functioning team.

I remember looking to Brian K for support and validation after the Founder was unable/unwilling to create the conditions to keep him on, and I was suffering doing 100% of the engineering for the front-end and back-end with no backup whatsoever. He was very kind. His advice was spot on.

We screwed up, big time. If we had hired the lead product manager from Dinerware, and if we’d managed to retain the 10x developer, it would have made all the difference. If I could have worked with that skeleton crew, we would been able to create something good enough to be self-catalyzing.

The Founder was essentially gifted a dream team that walked right in and through the room, and then out the door. With their help, we would have made enough headway in just a few months to beat Curbside to market with something that would have made a splash, likely starting with restaurants, which Curbside did not initially target. You would have heard of us by the end of 2014.

Payments, denied

Prior to this curbside pickup startup, the Founder had invested in a payments startup, as in, a service that facilitates paying for things from, say, a mobile phone, charging a small transaction fee. It’s certainly a winning concept.

That startup was neither Square nor Stripe, both of which were trying to do something similar around the same time, with legendary success. It was one of the many also-rans.

Curbside pickup had to be monetized to turn it into a business. The approach favored by the Founder was to run the transactions through our service. We would process payments and reimburse the merchants. The Founder, a fiscally conservative person by nature, did not relish the idea of paying fees to anyone else. He wanted to be the one collecting all the fees. His dream was to have one of his startups processing payments for the other.

But this payments startup underestimated the security and compliance costs, and was spilling fuel, running out of runway, and on a course for the trees just as we were taxiing for our own takeoff. It was looking tough for them to remain aloft long enough for us to launch, so to the Founder’s chagrin, we couldn’t use their service. The Founder was desperate to recoup some value from his prior investment, and he had a couple of favored employees parachuting out of that venture who were desperate to land on this one.

The CTO from the failing payments startup and one of his developers were courting the Founder for months. The payments CTO wanted to implement a payments back end for us, and talked a good game about all the money we’d save. When I met him, something felt off. My instinctive BS Geiger counter started clicking rapidly.

After weeks of buildup and big talk, the payments CTO scheduled a demo of the payments service he had been working on, which was supposed to be a stand-in for Square or Stripe for us.

In a story that sounded a lot like “The dog ate my homework!”, just before this demo, the payments CTO sent an email claiming that the server containing all the source code fell from a shelf in his garage, and that he’d have to rewrite everything but some snippets he found on his wife’s machine, and that this would teach him to do backups. I thought, wow, is that a lesson this CTO still needed to learn? We were on GitHub from day one.

The demo, when it finally happened, was a command-line program that took like five seconds to run on his own PC, and output a string that basically said, “It worked!” while offering no evidence that anything real was accomplished. No source code was shown. The rest was all talk. Underwhelming, to say the least. I might as well be looking at a one-line printf. I was wondering, is this a joke, ha ha, and now we see the real demo? It was not a joke.

Was this at least the output of a successful unit test? Hopefully so, but nothing was ever revealed behind that curtain, and it didn’t really matter, anyway. It did not make sense for us to process payments at all. Saving some tiny percentage fee was not the distinct value add we hoped to make. This was yet another distraction from the real problems we faced.

The false promise of a cheaper internal payment processor that would magically solve our payments problems ended up delaying the eventual adoption of Stripe, after a brief flirtation with Braintree, and that was among the many factors that delayed our launch. We never received anything of value from the payment tech CTO or that failing startup, but we did lose precious time.

Wanting to invent React and Redux

We were using Backbone client-side, which was serviceable. React came out in mid 2013, though I wasn’t aware of it immediately. By that time, I had already adopted an approach that was slightly analogous to React with Redux. The state management library known as Redux was released in 2015.

I thought, it makes no sense to render a page and then have all these different code paths manually munging the DOM based on all these properties mixed in with our views. This is labor intensive to write, slow to render, and horrendous to debug. I’d seen it time and again.

I thought, what we really need is, first, app-wide state, with a state machine that allows for undoable, loggable state changes that all go through a common mechanism and enforce data integrity along the way.

Then, we need a set of rendering functions based on slices of this state that create element trees we can insert in the DOM in predefined places. Buttons and so forth generate events of various types that can be passed around, logged and played back later. Each of these impacts the app-wide state in predetermined and preferably reversible ways.

It occurred to me in 2013 that the simplest thing to do was just to swap in the new content coming out of these rendering functions, but that doesn’t work so well with UI controls that have internal state, such as lists and other scrollable views.

The better approach was to do a series of smart updates to the DOM that minimize the number of steps, the overhead and the perceived UI disruption to get from state A to state B. Obviously you have to keep some additional state alongside the DOM so you wouldn’t have to keep doing expensive DOM API calls to get data you should already have about what the page looks like right now.

I thought, wow, this is a totally general problem, for which there is a totally general solution, which might consist of like 50 great interview questions in one project. This ought to happen!

I thought, that is the way to handle this, but I don’t have time right now. It’s a lot of work to do in the general case, which I don’t need to solve. So I just hand-rolled something for our own purposes.

I didn’t take a close look at React until mid 2014 when we were interviewing someone who’d used it. When I did, I felt immediately that this was the approach to use going forward. I kept reading blog posts, trying to understand why this wasn’t obvious to everyone else.

AngularJS was already popular and was getting a lot of attention. It did a ton more stuff, much of which I didn’t want. Angular just never clicked for me. I thought, this conceptual model seems to have three times as many concepts as it needs, while React is so simple. Simple is better. Then the Angular people decided to do breaking changes for 2.0, which was also gratuitously complex, but now in different, incompatible ways. Some people seemed to think better of Angular because it came from Google, but Angular’s journey made me a little less impressed with Google. When I see the ubiquitous “ng-” = I read it as, not gonna.

Early 2014

A front end dev arrives via the side door

One of the Founder’s favorites from the failing payments startup was a front end developer who knew JavaScript and JQuery. He had no mobile development experience.

This payments developer was very amenable to the technologies I had chosen for our 2013 reboot: Linux, Node, MongoDB. I’m not sure what portion of his enthusiasm was the fact that he needed a new job.

The payments developer wasn’t all that impressed with the payments CTO himself, and characterized him towards the end as kind of in research mode, focused on side projects.

The payments developer came on board through the side door, via the Founder, first, as part of the conversation around payments. Then, when that was all in limbo, in late 2013, the Founder simply decided he should work on our Dashboard “on the side”. Here we go again!

The Dashboard work turned out okay. The payments developer was a stronger web developer than the original CTO. By early 2014, payments were the only thing holding us back. The payments developer offered to help with that, and he had a good rapport with the Founder.

So, after I kept saying I needed help, I now had some help. And he did help, even though I didn’t think he was the best we could have found. I devoted significant time to getting him up to speed in early 2014, and then he did payments work I could have just done myself, some of which I had to fix or rewrite.

His code was very un-React-like. He would use JQuery to get the current DOM state to munge it iteratively, which was slow and propagated errors, instead of just referring directly to the system of record behind that DOM state, which had to exist anyway. I felt like he had a more to learn from me than the other way around.

Hotfixing

In early 2014, Apple was getting swamped with App Store submissions. They were trying to scale the approval process, and it was taking us up to 5 days to get a fix in. You could beg them to go faster, but you were at their mercy. It was profoundly inconvenient to be dead in the water for days while some two-line fix takes days to approve. This was just before Apple purchased TestFlight which made the beta process tremendously easier.

What I did in response to this was to conceive of and build a system analogous to what Microsoft’s Code Push did the following year. When our app starts up, it queries the server for fresh versions of code modules we’d registered in advance. If there is any code that is newer than the cached version of it, we’d download it and monkey patch the running app.

It worked like a charm and I could deploy updates in minutes. This appeared to be right on the edge of Apple’s guidelines, but technically allowed as long as it was for approved functionality. We used it.

Mid 2014

The Intern

A UW CS student who was the son of a friend of the payments developer was looking for an internship, and we were in need of engineering help, partly because the payments developer had required training and support from me to get started, and still wasn’t hugely productive on his own.

In mid 2014, this person was able to start a part-time “internship” for some miniscule rate that I’m not even sure was minimum wage, which the Founder thought was awesome. Done and done!

The Intern was portrayed as a low-cost, low-impact addition to the team, since the payments developer would manage his tasks. This was a back door for the payments developer to gain more control over engineering than he would otherwise have. Now he had someone very junior who was utterly beholden to him, who would always back him up on everything. I was immediately outnumbered on anything they disagreed with.

Pretty soon, the Intern and the payments developer were working closely all the time, coding the payments UI and back end. And once the Intern knew how the system basically worked, he was able to add some value, at which point, he was able to argue for real pay.

Except now, we were spending what little money we had on an engineering team that had some major skill gaps that we wouldn’t have had if I had been able to build the team I wanted.

Late 2014

The Entrepreneur and the Marketing Director

There was a period of time when we were shopping for office space, and friends-and-family type money was trickling in that could support hiring some additional people. For a stretch, we used my basement again as the HQ for a bigger team.

The Founder knew a serial entrepreneur from the Seattle scene whose startup was folding after doing some cool, fun stuff and burning through their funding. The entrepreneur showed up one day at the basement HQ with a woman very early in her career who had worked in marketing for his startup. He was a jovial middle-aged guy who yielded the first impression that he might be better suited for standup comedy than daily standups. He spun his tale while everyone sat rapt.

The Founder was announcing that he had decided to bring the entrepreneur on board, provisionally, in some capacity, as some kind of advisor. The entrepreneur expressed enthusiasm, while saying we should also hire the woman who had come with him as our marketing director. She agreed, we should do this! She took a big team photo in my basement. It was official now!

It’s a great photo that really brings that scene and that moment to life. I’m not posting it here.

It was all laughs, until he took off, and she stuck around. She then proceeded to rip her former boss to shreds, the person who had just gotten her (I suppose?) this new job as marketing director, a position I don’t think we’d posted. She proceeded to tell how he ran his own company into the ground and shouldn’t be let near anything involving money. Or something like that.

Everyone else in the room listened with disbelief and bemusement. This did not immediately doom his role, which, to my knowledge, consisted entirely of recommending people he had recently worked with and authoring emails containing spontaneous wisdom that was largely ignored. Within a few weeks, he was gone, and but the new marketing director was not.

The marketing director had frequent interactions with everyone else, while I was busy coding. Some people were thrilled, while others were increasingly exercised, about things she was doing, or not doing. I didn’t have time or energy for it. I didn’t see any actual marketing going on, but she was drafting web sites, collecting a salary, and coordinating with a mythical graphic designer whose face I never saw, and whose voice I never heard, who provided us with a very expensive new icon resembling clip-art.

At one point, there was a demo of what appeared to be a hastily drafted brochure site on Wix. It was better than nothing, I suppose, but a savvy and/or guerilla marketing strategy it was not. I was thinking, our competition is known to be down the road of strategic partnerships with national chains, while we’re stuck playing small ball and arguing over its color.

I thought, what’s the holdup here, for starters, just off the top of my head, we need stickers, banners, umbrellas, bags, some kind of promo codes or coupons tied to restaurants, some leave-behinds at the restaurant and in the takeout boxes, with logos and coupon codes. Let’s identify launch partners who are willing to hustle for some extra business and attention. Let’s make it a thing on some street where it’s famously difficult to park, generate some excitement, get some press, come on, let’s go!

All these things seemed obvious, but they didn’t happen. Or let’s hear some other ideas. But it was tortuous watching what little money we could muster for marketing produce no apparent marketing on the ground.

King of the Mountain

A brief vignette from my early childhood: Early on in grade school, there was a little grassy knoll out back by the playground, maybe 10 feet high. The summit of this mount, an unadorned patch of bare soil, was the most hotly contested territory at Park View Elementary.

Every day, during recess, there was a crowd of little kids, mostly boys, pushing and shoving their way to the top. At first, they were way bigger than we were, and I kept my distance. But soon, my peers were up there, shouting and shoving. I thought, this is an odd game. Why are they all doing this?

I came to understand that the point was to own the summit, and it didn’t really matter what you had to do to get there. This seemed like a pretty brutal game. I thought, I’m wired differently from these people. I just don’t feel this need to push other people down, or have everyone look up to me. My strongest impulse is collaborate with people, to create. They were also probably not focused on an internal monologue!

I built a tall tower out of blocks with a friend down the street, and when it was complete, he knocked it down. I asked why he did it. He thought it was fun. I thought, that is interesting, this person is different from me. Both of us enjoy creating, but he seems to enjoy destruction, and I didn’t have that impulse.

The CTO of the failed payments startup, after failing to build anything worthwhile for us or convince us that was even feasible, made a final bid in the spring of 2014 to come on board. Some big series of conversations was happening with the Founder in the background.

One day, the payments CTO showed up unannounced at one of our meetings. The Founder had said he really wanted to help out in some way. With smoke literally coming out of his nostrils, the payments CTO opened the meeting and started acting like he was in charge. He started saying, so, there are going to be some changes on the team. And he kept talking, about how things were going to work differently, and it was immediately clear he had not prepared, didn’t seem to understand even the scope of what we were doing, had not bothered to read the code he was granted access to, and had no idea of the real problems we faced.

I was like, hi, uh, so, what position are you currently seeing for yourself on this team?

CTO, he said. The rest of us all looked at each other in silence.

I responded, CTO? Of this company? Um, I don’t think so! The Founder’s style was to tell multiple people they were in charge, to be deliberately vague, and let them duke it out. This was turning into King of the Mountain. Unbelievable. A threshold of absurdity was reached, and something clicked within me.

I basically said, look, it’s unfortunate we have to have this conversation in this way, but this is nuts, and that isn’t how this is going to work. First, I need to hear this from the Founder directly, and when I do, I have some things to say myself.

And I proceeded to completely take the payment CTO’s candidacy down, on the merits, to his face, in front of basically the entire company, and explain why I thought he was unfit for the role he thought he just been handed.

Unfazed, the developer who had worked previously for him backed me up on the spot. “I don’t want to work with him either,” he flatly stated. From there, it took both of us to convince the Founder, who finally relented when I threatened to walk.

The payments developer really wanted to be King of the Mountain himself. My threatening to walk may have planted a seed. It served his narrative to have the app take a long time to modify, or appear to be unstable, and then he could portray himself as some kind of savior to new folks who didn’t know the tech.

As things fell apart in fall 2014, the payments developer started stonewalling and isolating me, while actively discouraging the Intern from helping to fix the few things that were actually blocking us from a wider release.

They weren’t that strong as engineers, and they weren’t giving the code their full attention. The majority of time was spent chatting up the Founder’s delegates, complaining about the status quo, while looking for an additional engineer who was more capable, affordable and controllable.

The End

There was one frustrating geolocation bug we were struggling with (mostly, I was), that caused dropped runs, but the mobile apps and all the back end services were otherwise working. The back end was extensible and performant, built with Node and MongoDB. We were in beta and about to launch for most of 2014.

By the end of 2014, in the absence of strong and effective leadership, there was a lot of flux and discord on the team, and things were trending in the wrong direction.

The Founder had completely checked out, delegating CEO authority to a financial advisor devoid of any business or product insight whatsoever, who somehow managed to wedge himself into a role in which he could filter and reinterpret all information flowing to or from the Founder. This was truly weird. It was like trying to talk with Brian Wilson through Dr. Eugene Landy.

The resulting dynamic made it very hard to figure out who was in charge of anything, which nobody really was. In the chaos, at the 11th hour, the payments dev and the Intern developed a sudden, odd compulsion to ignore all the tasks we’d identified for launch, and instead, take a months-long time out to replumb the most reliable parts of the system, the work I’d started with Brian K, and take an optional bet on a new and unproven full-stack solution, MeteorJS. Meanwhile Curbside was eating our lunch… after it was handed to them in a logoed bag.

Instead of staying relentlessly focused on building the business and making it a success, people around me were arguing over desk space in a cavernous office, engaging in yelling matches, Machiavellian power struggles, misogynistic microaggressions, and repeatedly threatening to quit or mutiny. Oh, and not doing any real work either.

It was one thing for me to stoically endure bad behavior directed at myself, but another to witness it as an emerging toxic corporate culture impacting the well-being of people right in front of me. That’s where I finally drew the line. I actually wondered if it was really a backhanded way of driving me out - behavior I wouldn’t tolerate, to usurp my position - a measure of how cynical I had become.

When all of this reached a crescendo at the end of 2014, my patience eventually ran out. I gave the company one final chance they didn’t deserve, and finally walked away, with my head held high.

I left the company with a functioning, well-documented system demonstrating at least one way to solve all the necessary technical problems end-to-end, the majority of which (>70% of the commits, for starters) I personally contributed. The folks who remained carried on, but from 2015 on, their story is theirs to tell. This one is mine.

Epilogue

Curbside pickup went on to become a phenomenon. Curbside, now known as Rakuten Ready, has thrived, but no single platform dominates. The fact that I still see as much ad-hoc pickup as I do tells me that collectively, even today, nobody has totally nailed the low-friction self-service model I was aiming to enable.

It was emotionally wrenching to have put so much sweat into an effort with so much potential, and then to see things devolve as they did, despite my unreasonable persistence.

As a kid, I immersed myself in books like Fire in the Valley: The Making of the Personal Computer, anything I could find that told the dramatic origin stories of people and companies who made it, and others who didn’t. I tried to learn everything I could from these stories years ago, and now I have my own to contribute.

• ← Building Walk Score's Apartment Search
• Porch.com →