The reality of building a company is examined in this installment of the “31 Founders at Applied Intuition” blog post series.
A startup’s early days can be fun, even exhilarating. And then comes a dose of reality.
“That’s the nature of starting companies,” was the matter-of-fact comment by Qasar Younis, Applied Intuition’s Chief Executive Officer and a co-founder. “I think not only do you learn how weak some of your skills are—just because of the nature of how broad the things you have to do are—you also get humbled. And learn that sometimes it’s not enough to be hard-working and ambitious. That is just not enough.
“These ex-founders, they're not intimidated,” he added. “They’re more durable.”'
What Could Go Wrong?
They seemed to plan correctly. But sometimes stuff happens.
Ryan Brigden and his team were working on a cashierless payments system for retailers. Their first order of business was to identify the right kind of customer, and they landed on targeting European retailers. Such stores tend to have standard footprints, and are located in busy train stations and other transportation depots with heavy foot traffic. They were the kind of establishments that would benefit from an automated system that minimized friction.
“We wanted to get rid of the whole idea of a turnstile,” recalled Brigden, now an engineering manager at Applied Intuition. “This was really compelling to a lot of the European retailers, who couldn't imagine putting in a turnstile. Retailers think about the fact that once you get someone to enter your store, at that point then you have an 80 percent chance of conversion. So any kind of friction in that place is a huge problem. We ultimately tried to launch in Europe.
“But then COVID happened.”
The pandemic prevented them from getting to stores in Europe, necessitating a change of plans, and the team ultimately launched in San Francisco instead. They served a couple thousand customers over several months and the system was feasible from day one. But ultimately, they could not get sufficient attention from shop owners.
”We really had trouble scaling this thing up in terms of selling it to others,” Brigden said. “Other retailers were just like ‘I'm trying to survive, I'm not going to buy this new tech.’”
Misalignment with market needs
Alan ElSheshai dipped his toe in the startup waters multiple times before joining Applied Intuition, where he is now a senior software engineer. His first foray was in email security—“really early stage, we didn't get too far with that,” he recounted. Next was a venture intended to assist consumers in content discovery recommendations. Later on, he launched a healthcare recruiting startup, like a LinkedIn for nurses. Part sourcing tool, part applicant tracking tool.
“It was right market, wrong product,” he says of the content discovery tool. “The whole idea was you use all these other people you don't know, who are like you, to filter all this information that there's too much of, and content there’s too much of. And so I think on that one, we really just missed the mark on the product. We tried to boil the ocean, didn't work out too well.”
He acknowledged a similar misfire with the healthcare recruiting venture, which in retrospect was a good product but with which he should have pursued a different market—staffing for RNs and above RNs, and doctors, segments for which they could have commanded a higher value for lower volume.
“I was closer on the product, but I think wrong on the market.”
Another choice he made that he would change: Going it alone. “Where I went wrong [was] thinking that I could do it on my own—‘I don't need anybody else.’ And kind of going and trying to do it on your own, or without a lot of other support, was kind of a mistake.”
Despite the setbacks in his startup experiences, ElSheshai seemed to describe them without rancor, as simply lessons learned. He thought for a second before commenting.
“It takes a while to come to terms with it.”
Managing Releases: “Looking Good. Ship it.”
Completeness vs. time to market. Tech debt vs. fast development. Anyone who has had to deliver software knows these balancing acts.
The value of speed was raised by most of the founders. One of the lessons Greg Granito took away from his startup experiences was the importance of not letting anything impose delays. This played a part not just in delivering finished products, but in proving concepts.
“All your ideas about what will be awesome in a product, or what will be great, or what users will love are really…just ideas,” Granito said. “Even if you talk to users and validate all those different ideas, there's still some element of ‘You're not sure if it'll be great until you launch it.’ And so the best way to do that is to just get it out there as quickly as possible.”
He acknowledges the company lacked a formal release process and offers no apologies for that. In the early days, with a limited customer base, the priority was not polished perfection. It was responsiveness.
“If a customer says on Monday, ‘Hey, it'll be great if we have this new feature’ or something like that, it'll be great if you could get it to them at the end of the day,” Granito said. “The end of the week is even too long."
For early-stage companies the software engineering practice of continuous deployment offers advantages by letting companies deliver features and bug fixes to customers faster. It also facilitates faster learning cycles by letting teams experiment and iterate more rapidly. It provides a fast feedback loop that reveals what works and what doesn’t.
“Part of what we did that I think worked out well for us was continuous deployment,” said Joe Moster, now a software engineer at Applied Intuition, describing how that approach enabled maintaining a rapid pace of release delivery. The strategy allowed deploying as quickly as if it were a cloud-based product, even though they were working with hardware.
“We built a tiny version of a warehouse. We would just run drones in there counting those boxes, 24/7. So we let it run for a week.” And then? “We’d say ‘hey, it's looking good. Ship it.’”
In addition to how quickly and how often to release, there is the question of when.
“As a very early-stage company we thought of releases around events that we would support,” said Amir Shah, currently an engineering manager at Applied Intuition. The release strategy was driven in part by the market they were targeting, college students. Because building a marketplace requires having both consumers and suppliers meet up, talk to each other, produce content, exchange money for goods, etc., it required collocation of buyers and sellers. The college student demographic made localization easy—buyers and sellers would be on the same campus.
Targeting that market came with its own set of imperatives around the timing of releases. “There were some hard deadlines—you can't not have the product ready when the semester starts, or when move-in starts, because that's when everybody is doing the bulk of their shopping,” Shah said. “So we really made it important to target these critical events and do marketing campaigns around events that were hyper localized to that particular campus. Things like homecoming, rival games and things like that were areas that we invested heavily in.
As with any technical project, problems can arise along the way, necessitating decisions that affect the release schedule. “You're going to be faced with two decisions. One is ‘okay, do I push launch to make this a better product?’’ Or ‘is there some mitigation strategy that we can put into place and launch anyway?’ For us, launching at the time of move-in was super-duper important. There was no situation that we could envision where you’d acquire the same number of users, same usage, etc. Everything that we did was hyper focused on meeting that criteria, and so that meant potentially losing features.
“
All your ideas about what will be awesome in a product, or what will be great, or what users will love are really … just ideas.
“If we felt something wasn't high enough quality or not ready we’d punt it. And we'd say ‘Yes, that’s something we can do later. Let's get the basic functionality out, hyper focus on brand awareness, hyperfocus on the core features that people are looking for.’”
Ultimately, in particular for that initial launch, the focus was on getting something out the door fast to start getting feedback. “That informed a lot of our decisions in terms of what to release with, and what to postpone.”
In some cases functionality loses out to time. To paraphrase an old proverb, markets wait for no one, so it is no surprise these stories reflect a premium on deploying quickly. But what about quality? Shah described the balancing act they played to maintain quality, taking advantage of the down time—relatively speaking—between release pushes to work on the product.
“Outside these big move-in and move-out type events that we had was the time that we took to breathe and say, ‘OK, now we're gonna focus on quality,’ or ‘we're gonna focus on improving a particular workflow or work stream,’ or the UI or something like that,” Shah said, as they worked out the timing between critical and non-critical releases.
So what ultimately drove the decisions on adding new features? Shah put it simply: "Metrics and data.” They did not leave quality to chance.
Maintaining High Quality: “Rewriting from Scratch…Never is the Solution.”
It is celebrated by the Malcolm Baldrige award. It was “Job 1” in a Ford Motor Company tagline. It is an objective that every company says it values.
“It” is quality. Maintaining high quality in any competitive field is always a goal, usually an imperative. But is it always practical?
“You can cut one or two corners,” Roland Philippsen said. At some point, though, the corner cutting starts to take its toll. “From a technological point of view, what you're building is way too intertwined. And that makes it very hard to change in the longer term."
It kind of creeps up on you, Philippsen said. “You just have a big burning mess somewhere that's not working anymore, and now we have a customer breathing down [our] neck because it's not working. And then you fix it. But you have to fix it in a hurry. And chances are you won't fix it the right way.
“You need to be able to take the time as an engineer, to sometimes take a step back and say, ‘If I were to design it from scratch, would I structure it differently?’” he continued. “And if you would structure it differently, is there a way for you to get closer to that without rewriting things? I think people often think that rewriting from scratch is going to be the solution, but that never is the solution. The solution is you have to have at least a clear picture of what it could have been. So that when you make changes anyway, you can move towards that.”
The quality question was somewhat different for Amir Shah, whose startup was aimed at solving a problem for consumers. “We’re a B2B company, our users expect to have a constant and reliable method of feature improvement,” Amir Shah said of the quality expectations for Applied Intuition. For his B2C startup, though, the expectation was not the same. “Consumers expect something similar, but it's not to the degree where they need to know that, ‘Hey, your next drop is… .’ Nobody's paying attention to when you're going to release something next.” As a result, the team had some latitude in how and when it focused on making improvements to quality. They decided to fix quality only during lulls.
“[We had] a little bit of flexibility here, outside these big move and move-out type events,” Shah said. “And so this was the time that we took to breathe and say, ‘Okay, now we're going to focus on quality,’ or ‘we're going to focus on improving a particular workflow or workstream,’ or the UI or something like that—in between these critical releases. Maybe you can think about that as a critical versus non-critical release.”
“
You just have a big burning mess somewhere that's not working anymore, and now we have a customer breathing down our neck because it's not working. And then you fix it. But you have to fix it in a hurry.
Even if quality tradeoffs are survivable in the near term, long-term goals require coming to grips with the need for quality. That coming to grips can necessitate awkward changes. Adriano Quiroga tells the story of an early employee with stellar qualifications who simply was unable to deliver at the necessary level.
“He just was struggling, struggling, struggling,” said Quiroga, now an engineering manager at Applied Intuition. “You need to put in the attention to detail. It's not like he wasn't smart—he had a PhD in neurochemistry. It just wasn't the type of work environment that was best for him. At some point, we made the decision that we needed to get rid of this particular person.
“You have to deliver. The quality needs to be high.”
Tech Debt: “A Very High Interest Rate”
Technical debt can carry implications for companies of all sizes, but for growth-stage startups it poses special questions. How do they address the phenomenon and achieve product goals? Can they retire that debt and still get to market quickly?
“A lot of people fall into the trap of thinking that tech debt is any code that doesn't meet their standard. And that's always an interesting one, particularly for small-stage startups,” Moster said. “One of the challenges I see around tech debt is you can build something that's maybe not the most scalable. [But] Is that tech debt?”
Moster shared a story from his drone management days, a scenario requiring the ability to fly multiple robots for the warehouse—without hitting each other of course. He crafted a framework that would scale up to five or six robots. Sure, it would be nice to eventually control hundreds of robots. Would this approach constitute tech debt?
“In our scope I said ‘I need this code to operate for at least the next 18 months or two years. This will get us there. So, this is acceptable debt, this is the low-interest debt,” Moster said. “This is not going to harm me if I can only support half a dozen robots in these warehouses. We just weren't doing deals above that size.”
On the flip side, Moster used another scenario to illustrate the business repercussions of neglecting technical debt. In this case they allowed a Docker container and its dependencies to fall out of date, requiring that a dependency be taken offline.
“So I can't build my Docker containers anymore. That is very, very expensive tech debt,” Moster said. “If I need to make any change to that code base, if we use Docker to deploy out to the edge, or if we need to fix a bug, we're not going to be able to do it. That debt comes with a very high interest rate.”
“Tech debt, big issue,” said Gaurav Bhatia, an engineering manager who joined Applied Intuition after his experience founding Ottomatika. He recognized that in the course of getting a company launched and product out the door a lot of tech debt can accumulate.
“We would have these one month or two weeks, every quarter, where we would try to reduce our tech debt, we dedicated it for just that,” Bhatia said. “Two weeks, every quarter, everyone sat down, looked at all the accumulated Jira tickets that we had, prioritized them, and went to just tackle them. We just started to get into that habit of kind of doing that. So every quarter, for two weeks, same thing, we would basically send a group of engineers to…sit in the cars and solve the problems together. We would get a lot of progress out of that.”
“
I need this code to operate for at least the next 18 months or two years. This will get us there. So, this is acceptable debt, this is the low-interest debt.
Tech debt, Roland Philippsen says, is one of his favorite topics. In his earlier comments about maintaining quality standards, he referred to cutting corners, acknowledging that doing that is not always bad, that doing so within reason does not constitute tech debt.
Still...
“They're the starting points for tech debt,” he says of the corners that are cut, describing how short-term steps to solve a problem for one customer can lead to later problems. “And then another customer comes along, they need almost the same thing, [so] I'm just going to copy-paste this second thing again.” The problem is compounded with the creation of multiple implementations of essentially the same thing.
“And every time you find a bug, you have to fix it in four different places. And then somebody else goes in and fixes the bug, they don't know that these other three places exist, they only fix it in one place. So, then you have discrepancies in how the system behaves, depending on who uses it. And soon enough, your debugging will get slowed down tremendously, because one person says, ‘Oh, I have this bug.’ And the other person says, ‘Oh, no, it works perfectly fine for me.’ These are the kinds of things that are really hard.”
How to address it? Having smart people who take ownership of the problems. “They will figure it out.”
.webp)
.webp)
