Releasing a Product Into the Market
Unlike many apps you can download and just start using right away, with Delect we aren’t just building an app, we’re building a platform that can fit into any situation, at any time — a polyglot that is living and breathing.
The story of Delect began back in my days at the University of Maryland, College Park, where I’d go out to eat with friends on the weekend. Like many college students, I had many friends with whom I’d go to dinner, 10, 15 friends on any given weekend. Most of the experience I enjoyed, until it came to the check, where I’d watch my friends fall into the abyss of figuring out who owes what and watch as they pull out cash, credit cards and shout across the table for someone to spot them. I viewed it as the single most annoying phenomenon on most occasions. And the amazing thing about this is that it didn’t stop there. Now they had to go figure out which items their credit cards should be swiped with. And on most occasions, the bill still fell short after we’ve paid. And there starts another scramble to figure out who was going to cover the remaining balance.
The Journey to Delect
Watching my friends figure out how to split bills and wait on checks to be processed was one of the most frustrating aspects for me to look at, because I hated having to wait for the bill. I fell the next adventure was waiting, what are we waiting for bills and fussing over these useless details for? This was in 2013.
Fast forward to 2015 when I was a contractor at the National Institutes of Health (NIH). I had already begun tinkering with the idea of launching an app, I had a bit of an idea what I wanted it to be so I began putting together some of the early prototype screens, conceptualizing the app. While I was at the NIH, I was also involved in a city council campaign in the state of Virginia, where I was managing the digital presence of a political candidate. There too the problem of fussing over bills at the end of meals existed. And that’s where the idea to make Delect a reality really began to kick-in, why should we have this problem at all, even in a political dinner?
Making it a Reality
When my contract at the NIH ended in May 2015, I didn’t want to look for another contract, Delect was calling, but I knew one thing. If I was going to start another company, it needed to win, we had to win, and I was going to dedicate my entire life to make it a reality. So I took the next six months and did research. I wanted to know about the space better than anyone else in the industry. I wanted to know why no one has been able to solve this issue and what will it take to actually solve the problem.
I interviewed over 500 restaurateurs, and must have talked with over 800 potential users (I know because a good chunk of them came back and signed up when I launched a beta site). And that is where I learned what the root of the problem was, what restaurants were looking for, what needed to be in place to allow restaurants to engage their customers in the most interactive way, keeping the human aspect to servicing guests, while enabling guests to pay from their mobile phones, and reaching them via their mobile phones when the time came to bring them back in. I did learn one big fear, the paralyzing fear that introducing pay at the table would alienate their customers.
Armed with the information I had now gleaned from my potential customers, a few realizations came to play, that in order to really solve this problem, we needed the absolute best team in place. I needed people who were smarter than me, the absolute best. So I embarked on a journey to find the best engineers and developers to build the team.
In Comes Jeremy
I spent the next four months looking for developers who could help make Delect a reality. I went through 5 developers/engineers before meeting Jeremy, a former Bosch engineer who worked on projects funded by NASA, NIST and NSF, who would become my co-founder and CTO.
We Were Off to the Races
This was in April 2016. And we began working on Delect. As I mentioned in the beginning, we weren’t just building an app that we could throw out there, get downloads and go nimble at the next thing. We were building a platform that would connect restaurants directly to customers and improve the interaction between the two while keeping the human interaction alive. To break it down, we were building a system that would allow users to pay from their mobile phones, an app that would allow restaurants to process orders from an iPad, and an engine that would allow the two to stay in contact even after customers have left — a platform to really connect restaurants directly to their customers.
Our Alpha Launch
Fast forward to September 2016, we had a working product, or so we thought. Along the way we brought on two phenomenal engineers — Anuj and Neil. Anuj, whom I met shortly after Jeremy, and a young computer science graduate from Virginia Tech. Neil, a few months later at a DC tech event where we stroke up a conversation on his streak of development work over the past year.
With an engineering team starting to take shape, we had a product we could test, and we had a restaurant, really, an advisor, willing to take a chance on us in his restaurant. Like all first versions, nothing worked. Some users couldn’t check-in to the restaurant, we discovered the myriad of different devices our initial users had that we had tried to account for but to no avail. The restaurant system flat out did not work. And much was done manually.
But we learned a whole lot. Much of the assumptions we had — the existential slow connection issues, especially in corners of the restaurant, and crashes — all played before our eyes.
And it was time to go back to the drawing board, take what we learned and make the platform better. Fast forward to December 6, 2016, we were at it again, ready to put the improvements to the test, we made it a beta public launch because we had spent a lot of time working out the kinks and fell we were ready for the world to see it. 70 to 80 percent of the people that came were able to use it and pay from their mobile phone. It was magical to see, but the restaurant side didn’t work too great, still many bugs, many fixes to be done and we didn’t have functions that the restaurant would actually need because we wanted to build a Minimum Viable Product (MVP) that they could just get by with. One thing we learned is when building a product like this for restaurants, you can’t follow the conventional build an MVP and get them to start using it that you always hear.
And while we weren’t building a rocket, it would be like Elon Musk deciding to hold off on one of the rockets to the Falcon 9 on its first launch. If you’re building a complex system, let issues be a result of bugs, not missing, critical features that are needed.
If you’re building a complex system, let issues be a result of bugs, not missing, critical features that are needed.
Velocity and Now
Thanks to Velocity Accelerator, we received our first outside funding, spent the next three months, building, refining and making our platform better; considering every single little detail, taking into account all the feedback our users and test restaurant — advisor, has provided us, making tweaks after tweaks to get the perfect product — working functional product. Then we launched it, and it worked, it actually worked. We kept waiting for a crash to occur, a bug to show up somewhere, a user not being able to pay, the restaurant not being able to see the user — nada. It worked. And it’s still working and we now have a product on the market, a working, functional product.
And the feedback we’ve been receiving is nothing short of positive.
