Grateful – TAVR, Health Issues, and Reflecting on the Past Ten Years

Assuming everything goes smoothly, this scheduled post should be going out around the time I’m getting out of an operating room. 2022 has been a year of ups, downs, and severe aortic stenosis, and I’m excited to get a TAVR procedure done. A TAVR is a minimally invasive way to replace my failing aortic valve, which should restore my normal heart function and let me get back to having an unrestricted day-to-day life for the next few years.

Stressful situations have always brought me clarity. As I sit here, on a quiet Sunday in an empty office, I want to use that clarity to take stock of the impact these ten years of heart issues have had on me.

I was diagnosed with a congenital heart defect in 2012. Since then, I’ve had two open-heart surgeries, a heart attack, and innumerable doctor’s appointments. Frankly, I’ve had a worse-than-expected outcome at basically every step. The congenital defect is extremely rare, the first surgery was supposed to be the only one, that heart attack never really got explained, and the valve I get replaced tomorrow normally lasts much longer. I’m going to be dealing with heart issues for the rest of my life.

That’s all happened in the past ten years, and none of it is good. Yet, the past ten years have also been my best ones. I’ve been surrounded by incredible friends and loved ones. I’ve gotten to build a great company doing work that matters. I’ve had full athletic opportunities, becoming a league-champion wrestler, a (very bad) varsity college athlete, and a gym regular. I truly think those great things have happened because of, and not in spite of, my heart issues. My heart issues have given me drive, focus, and an invaluable sense of perspective. The contradiction I live with every day is that the worst moments of my life, and the outcomes I fear most, are why so many of these amazing things have happened.

Thinking on that contradiction today, my main takeaway is I’m grateful. Not grateful for being in this position, but grateful for the people around me, and the time I live in. The line between benefitting from adversity versus being dragged down by it is razor thin, and I’m grateful I’m on the right side of it.

I’m grateful that my mom thought to ask our family pediatrician about one episode of me feeling dizzy on a treadmill, and that she got the right answer. I’m grateful that medical imaging technology existed to diagnose my defect, and that there was a proven surgical option to address it.

I’m grateful that we have medical providers that listen to patient’s wishes. More specifically, to the surgeon who spent hours trying to repair my aortic valve during my second surgery before ultimately falling back to having to replace it. The repair didn’t work, and extended the surgery, but I had told the surgeon I wanted him to try it, and greatly value the closure from him having done so.

I’m grateful to the unknown horseback tour guide in Costa Rica this January. He saw me stumbling and dizzy on a hike, put me on his horse, and got me up to the top. I had just started to be symptomatic, thought it was just dehydration, and stubbornly assumed I could just keep on going. I’m grateful I didn’t find out how stubborn I could be.

I’m grateful that the TAVR procedure is an option. Twenty years ago it didn’t exist. Five years ago, when I had my last surgery, it never would have been considered an option for patients in my position. Now, they can go and replace my heart valve through a small incision. It feels like sci-fi to me, and I’m grateful that I get some more time before getting my ribs cracked open again. I’m amazed everyday by innovation in healthcare technology. I’m optimistic that by the time of my next valve replacement, there will be even more options than we have today.

I think of my life in eras defined by my surgery dates. Since my first surgery, those eras have been in roughly five year increments, and I think each one has corresponded to a new phase of life events, achievements, and personal growth. With the TAVR, I enter a new one. The things that we can’t help but care about make us who we are. Reflecting on the past five years, I feel good about what I’ve cared about, and where I’ve spent my time. I’m excited to build on those in this next phase, and to have more things to be grateful for.


Update – 9/27/2022: The TAVR went smoothly and I am already out of the hospital. Modern medicine can feel like a miracle sometimes!

Our React Native Experience

Ben Sandofsky, an iOS developer I have immense respect for, recently tweeted about why React Native is “stuck at its niche 2.6% adoption.” His negative opinion got a lot of traction, so I wanted to share our experience at Healthie.

In 2018, we rebuilt our native iOS and Android apps (which used Swift and Java respectively) in React Native. It was one of the best engineering decisions we’ve made. Here’s why

1) Given our size at the time, it did not make sense for us to have more than one iOS or Android developer. This meant those devs were working in isolation. React Native let us set up a (mostly) shared codebase with multiple people working on it.
2) It allowed our web engineers to understand and give feedback on the mobile app code. We use React for our web front-end, and once we switched, our web devs were able to help mobile out with code reviews and trouble shooting.
3) While you definitely can’t just re-use web React code in React Native, we were able to share libraries and parts of code between our web and mobile applications.
4) 90%+ of the code can be shared between iOS and Android. No more separate git repos per mobile platform.
5) Code push. At the time, we sometimes had to iterate quickly on the mobile app. Code push allowed us to quickly release hot-fixes and improvements without always needing to go through the (at the time slower) App Store review process.
As Ben mentions, 1-5 could all be accomplished via web views, so why not just use that? 95% of our mobile app lends well to React Native. However, parts of our app (Apple Health syncing, video chat, etc), needed to be done in native code. React Native makes it easy to bridge out to native where needed. In addition, there are existing open source libraries for some of those bridges. This is a huge advantage versus a web view approach.
React Native is definitely not right for every type of app or team, but has been a great fit for us given our needs. I don’t think it makes sense to dismiss it out of hand.


Wrestling state finals, senior year of high school. I’m cruising through the match, up 5-0 over someone I had already pinned twice that year. I tilt my opponent onto his back as the ref’s hand hovers over the mat, waiting to call the pin. I’m an inch away from being a state champ. Six years of hard work are about to pay off, and then, my opponent escapes and we’re back on our feet.

The escapes only worth one point, I’m up by four, and with 20/20 hindsight, could have done nothing the rest of the match and still won. Instead, I panicked. I took a flailing attempt at a move I never did, ended up on my back, and thirty seconds later was watching my opponent get his arm raised.

I fucked up. I had a plan, the plan was working, something unexpected and surviveably bad happened, and I started flailing. The panic was worse than the problem. As markets get more volatile, trend down, and doom is spread, I think about this match a lot. For most startups, those who are not burning an immense amount of money to “blitz-scale” or in industries at the epicenter of the downturn, the fundamental facts on the ground have not changed.

Even though facts stay the same, the pressure to attempt large moves ratchets up. When other competitors are visibly pivoting, doing lay offs, and making sweeping changes, it can seem like a mistake to not follow in those footsteps. The same goes in a bull market. When your competitors are paying 100k over your target salary for a role, there’s pressure to match.

This pressure causes panic, and panic causes reactionary flailing. Whether your company is bootstrapped or venture-funded, it’s your company and no one knows more about it, or has a better plan for it, than you as a founder.  “No one” includes Twitter pundits, your competitors, your investors, and your mother.

This doesn’t mean putting wax in your ears, a blindfold on, and sticking your head in the sand. Plans should always be iterated on. If fundamental facts change, plans should be blown up and rebuilt from the ground up. However, plans should not be re-adjusted in a flailing panic. The opinions and actions of others around you should be just one input, not the main driver, when it comes to adjusting strategy.  To paraphrase “If”, trust yourselves when everyone else doubts you, but make allowance for their doubting too.

After the season ended, one of the team parents printed large foam board pictures of each wrestler and gave them out. Mine happened to be from that match, showing me in a dominant position to win, about a minute from when I panicked and lost. That picture remains where it has been since the day I got it, on the shelf of my childhood bedroom. Whenever I go visit my parents, it serves as a helpful three-by-two foot reminder. A reminder that panic, and the flailing half-hearted actions it causes, can be much much worse than the initial cause itself. As things get crazy and markets pull back, it’s something that needs to be remembered.


What’s Next For Telehealth

It’s been an eventful past few years for Telehealth (to put it lightly). Telehealth usage started at less than 1% of outpatient visits pre-COVID, shot up to 13% percent in the first six months of the pandemic, and has since fallen back down to ~8%. With both COVID and telehealth usage numbers flattening, there has been a lot of conversation about the future and direction of telehealth moving forward. So what comes next?

There’s a striking range in what people think when they think “telehealth.” To many, their experience with it has been as a 1:1 replacement. They’ve had the same appointments with the same providers. However, instead of those being in-person, they’ve happened over video.

Given that, it is no surprise that telehealth visit usage numbers look the way they do. To these patients, telehealth visits quickly went from a non-option, to the only option, to a choice. Many providers now offer both in-person and virtual visit options, and will continue to do so. More choice is good for patients, but those visits remain a virtual copy of what they have traditionally been.

Telehealth goes from good too great when it stops copying and starts stealing. Telehealth truly succeeds when it takes the good parts of provider visits, but blends them with capabilities that would be impossible without technology. For example, new care models can utilize smart device data, asynchronous communication, and automated interactive educational content (often alongside shorter provider video visits), to deliver care that goes far beyond what could be possible in-person.

“Automated”, “interactive”, “asynchronous”, and “smart” all sound like buzzwords, but this new type of care is happening. Both startups and large incumbents are launching and scaling care models that are fundamentally different than what could be offered in-person.  The issues these new care models address (addiction, asthma, chronic pain, obesity, etc), and the type of care they provide, are all very different. However, these care models are unified by the common thread of tech-enabled recurring healthcare. Also excitingly, many of these new offerings are proactive. By more effectively addressing patient issues before they require urgent care clinics or hospitals, these models could fundamentally shift the type of care our healthcare system provides.

Before video games, there were mechanical pinball machines. You can (and people do) make video games that copy pinball machines. However, the best video games aren’t pinball machines copies, and we don’t sit here and talk about what percentage of pinball games are played mechanically versus virtually.

The above sounds a little absurd, but that is where the telehealth discussion is right now! Telehealth replacing traditional in-person medical visits 1:1 is a tiny part of the potential benefits.  Telehealth’s future should be forecasted based on the new types of care that it allows for.

That future is bright.


Stripe turns 10 today, so I figured I’d share my favorite personal Stripe story. It’s an experience that greatly impacted how I think about customer service (and growth) at Healthie. It was Jan 2013. I had recently turned 16, and was building my first product that I wanted to charge people for.

I’m not sure how I found Stripe (probably through a coding tutorial) but decided to use them to add subscriptions to the product. I was (to put it nicely) raw at programming, and had never built something like that. I got stuck for a few hours on adding coupon codes to the checkout. I thought I was experiencing a bug with Stripe and fired off a support email.

Shortly after, I realized that the issue was completely on my end, fixed it, and moved on, forgetting about my support ticket. Later that day, Stripe Support followed up to confirm I had gotten it resolved, and offered to send me a free t-shirt. A shirt? For free?! Sounds tiny now, but at the time I was over the moon.

I was a high-schooler. I hadn’t taken any payments through Stripe. I didn’t even have access in Stripe to run real credit cards, and they were going to mail clothing across the country to me. Sure enough, a few weeks later the shirt (along with stickers and a handwritten card) arrived.

Getting that shirt was one of the first times I felt like I could be a real part of the startup ecosystem. It felt like a badge of honor. I wore it in the airport the first time I went to SF. I wore it around Palo Alto the first time I went to Silicon Valley. I wore it for years and years until it gradually ended up full of holes and unwearable. It made me, an awkward teenager, feel like I belonged.

The product I was building didn’t work out, nor did the next few, but the admiration and respect I had for Stripe never went away. Three years later, when we started Healthie, it was never in doubt what payment processor we would use.

We’ve since processed over one hundred million in payments using Stripe, and have paid them millions in fees. Shipping that t-shirt, which probably cost them $20, ended up being a pretty decent investment.

It is (relatively) easy to provide personable support to your largest customers. It is hard to do the same for your smallest. However, those tiny customers normally appreciate it a lot more. It feels more unique and special to them, and can give you life-long advocates.

Surgery and Startups

When I had my second open heart surgery in March 2017, the thing I worried about most wasn’t the getting anesthetized and cracked open during the surgery itself, or the mortality risk, or the uncertain recovery. it was the impact that being unreachable for a couple days would have on my startup.

In the lead up to my surgery, Healthie was a year old. We’d raised a million dollars just a few months prior. When you raise, you paint a vision for investors, full of billion-dollar liquidity events and company immortality. You paint a picture of being able to predict and control the future. Going under for surgery is the opposite of all of that. You are giving up all control (and consciousness). You are placing your life and future in the hands of a surgeon you’ve met a couple times and in a care team who are complete and total strangers. It sucks.

It was hard for me to tell my cofounder about it. It was mortifying for me to go from raising money, to our next monthly board meeting, where I felt obligated to tell our new board member (and also lead investor) about my newly scheduled surgery.

I was worried that they’d think I wasn’t pulling my weight, that I wouldn’t deliver on my promises due to a medical event I had no control over. I was concerned about how all my recent direct hires, who I pushed to bring on, and had agreed to manage and lead, would do in my absence. I thought I’d be letting all our customers down, especially the many who I had gotten on sales or success calls with and promised that I’d be there to offer personal support.

In all these cases, I’d stammer out a poor explanation about having a problem with my aortic valve, and that I’d need to be out a few days for a surgery. I’d prep myself for the worst responses, and get nothing but understanding and positive reactions. It wasn’t even accommodating or sympathetic (which I appreciated), just people being supportive and treating it as a non-issue.

I was knocked out for the surgery itself, and the immediate recovery is full of blurry memories and dialudid. A day later, after recovering enough, I felt unnecessarily compelled to hop back on email and support tickets from my phone in my hospital bed. This was a bad idea.

A couple of days later doing that, my recovery was progressing well and I was hours from being released. I got an automated email alert that we were having web application availability problems. My blood pressure spiked so much that an alarm went off, and a nurse came rushing in.

The alert ended up being a non-issue, and my blood pressure went back to normal. However the blood pressure spike (despite my explanation) greatly worried my care team, and I came close to not being released from the hospital that day.

In hindsight, I took one of the worst things ever to happen to me, and made it worse. Despite my worries about having surgery, our customers didn’t mind, my cofounder didn’t mind, our investors didn’t mind, and our team performed admirably in my absence. I took a shitty, scary time and made it shittier and scarier.

It’s common to talk about a reality distortion field that comes from a startup’s founders. However, I’ve never seen anyone taking about that field distorting things in reverse. As a founder, you’re supposed to live and breath what your company does. That attachment makes it very easy for founders to overemphasize and fixate on molehills, which quickly turn into personal mountains, and in many cases (including mine), actual quantifiable health issues.

In hindsight, my reaction was incredibly irrational. However, as a founder, it’s normal to seem irrational. The ability to have strongly differing opinions is what allows founders to build big, novel companies. Unfortunately, that same personal conviction can cause trouble.  I know it did for me in this case.

If you’re a founder beating yourself up about personal events that are outside your control, take a deep breath. What’s inflicting more damage to your company? Those events? Or your reaction to them?


For the first time in over a year, I’m resting my elbows on the carved wooden bar at the hole in the wall, only in NYC dive bar underneath our (now former) office.

Undercover cops shot a black security guard on the doorstep in 2000, after the security guard refused to sell them pot. The Grand Jury declined to indict them. Anthony Bourdain,  the Hunter Thompson of our time, drank here. 30,000 New Yorkers have died of COVID since I’ve last sat at this bar.

This bar has five different names — on the sign, on google, inside, etc, including one calling it a “distinguished cocktail lounge.” I recommend buying only bottled beer and paying only in cash.

This bar is a survivor, between a LensCrafters and a Dos Toros. It’s one of three businesses on this block older than 10 years, the others being a hardware store, and a sex shop that has a sign proclaiming its “busines hours.” (sic)

This bar is a survivor, but in between the (mostly) socially distanced bar seats, are ghosts. Of Bourdain, of Patrick Dorismond, the father of two murdered by undercover, unidentified cops, of the 30,000+ New Yorkers killed by “just the flu.”

Much like scars, the ghosts never go away, but they make us who we are as a city. On dark, rainy nights like this, where we can uneasily re-experience something we took for granted for so long, I remember them.

Survival Bias in Startup Advice

Lots of startup advice is told like a war story. Founders of (now) successful, thriving companies talk about the dark days, full of all nighters, personal debt, stalled growth, and low runway.

These war stories generally include advice like “never quit” and “keep on pushing.” The storytellers talk about taking huge personal risks, working themselves to the bone, and approaching their mental breaking point.

These stories all have the same ending. The efforts paid off, the company turned around, and the founders did (more than) well. They look at these dark days almost nostalgically, and talk about how they overcame them on Twitter or over drinks.

These stories all have happy endings because the companies (and their founders) survived. Very few people look to advice and stories from unsuccessful founders of failed companies.

Companies that ultimately fail have plenty of dark days as well. Their founders, in many cases, work just as hard and take on just as much personal risk as founders of companies that work out. However, their stories end in a range of begrudging acceptance to soul-crushing sadness. It’s not pretty.

3 years ago, in April 2018, we went through one of our darkest days at Healthie. Our sales and marketing strategy was not working, and we had to lay off 20 people (85% of the company) in a single day. What followed was three months of little sleep and crunching the team, trying to rebuild our product from basically the ground up. It was an absolutely miserable time, but ended up turning our company around, and put us on a sustainable path to fast growth, profitability, and success.

We survived those dark days, but a lot of companies don’t. There were times where it looked like we wouldn’t, and I still have mixed feelings about how close myself and other employees came to burning out. Our decisions were the right ones, but I definitely made them with a great deal of naive optimism.

If you’re struggling and thinking about the best path forward, it’s important to be mindful of survivorship bias in startup advice. Before taking on immense risk and emotional burden, get a clearer picture of your expected outcome, not just stories told through rose-tinted glasses.

Entrepreneur is a Dirty Word

When I meet new people, and explain Healthie and what I do there, some of the most common responses are “It must be cool to be an entrepreneur” or “I want to be an entrepreneur.” I always smile, nod, and cringe internally.

I am not an entrepreneur. I build healthcare software.  No one is an entrepreneur. Despite literally millions of LinkedIn profiles with that title listed, “entrepreneur” is so generic and non-descriptive, that it ceases to be a real thing. You can be the founder of a specific business. You can even be a “serial founder” if you really want to call yourself that.  Those words describe actual actions taken.  “To Found” is a verb. “To Entrepreneur” is an absurdity.

When asked about your job/career, You would never say that you are a “business person” or a “human.” Calling yourself an “entrepreneur” is equally as generic and unhelpful. Worse, the word “entrepreneur” has been latched on to and weaponized by the Grant Cardone, Kevin Zhang, fake Lambo-owning, get-rich-quick-course-selling crowd. They talk about their glamorous lives as “entrepreneurs” and use the concept to take advantage of people.

They can only do this successfully because so many legitimate people currently call themselves “entrepreneurs.” When I searched the job title “Entrepreneur” on LinkedIn, many of the results are people who have built real businesses, who have created amazing products and teams. These are people that I respect, look up to, and want to emulate as we build Healthie. Frankly, the fact that they refer to themselves as “entrepreneurs” undersells their achievements.

We should be using words and titles that focus on specific actions taken and work completed. The more we do that, the easier it becomes to recognize and celebrate builders, while leaving scammers and charlatans behind. Let’s stop using the word entrepreneur.

Finding a Developer for your MVP

The most common question new founders ask me is how to hire developers to help build their MVP. These founders are normally passionate and knowledgeable, but are not technical. Their companies (like most nascent start ups) are normally tight on cash and time.

In an ideal world, these potential founders would all have a trusted technical friend who had the time, willingness, and ability to help build an MVP. In a slightly less ideal world, new founders could go to a meet up, hit it off with a person who is a great initial fit, and have them build it. Unfortunately, both these scenarios are rare. Good developers are in high demand, dev jobs are well paid and stable, and new startups are risky and painful (albeit hopefully rewarding). This leaves a tiny pool of developers that fit the above two categories.

New founders can’t afford to wait for the perfect developer to come along. To get the ball rolling quickly and affordably, these founders normally need to look to a much bigger pool of talent, namely online freelancers.

What follows are the tips and learnings I’ve gained from hiring contractors at Healthie, as well as helping a bunch of brand new companies find their first engineers. 

The below advice is for you, assuming you’re a non-technical (or not technical enough) founder building a web or mobile application with minimal tech risk. For example If the MVP of your app is based around machine learning or has intensive graphical needs like custom 3D rendering, there is likely better advice out there. This advice also assumes you’ve exhausted preferable options like finding a developer who is a great fit and you know directly (or comes highly recommended as a referral).

First, three pieces of general advice on hiring and working with your first engineer hire. 


  1. References, references, references – no matter who you hire, you should always do reference checks. No one is offended by it, and talking to references really helps you work with the hire. In the case of good references, they help you learn how the hire likes to work and interact with others. On the downside, the hire can’t provide references (or the references are lukewarm or negative) and you can avoid a huge amount of trouble. The worst candidates we hired at Healthie looked amazing on paper and from their initial interviews. We were very excited, and didn’t want to risk losing them, so we made offers without doing reference checks. In hindsight, references would have exposed the issues that we had to learn very painfully. 
  2. Own your accounts – You should be the primary account holder/admin on all services that your engineering hires are using to work with you. Most notably, this includes where your code is stored (e.g Github), where your server is hosted (e.g AWS), and the tool you use to manage the project (Trello or Clubhouse). Your first engineering hire may have (strong) opinions on the specific tools to use. Whatever tools you use, you need to be the one to create the account, and then invite the engineer as a user. This has a range of benefits, but most importantly, it protects you and your company if your relationship with the engineer ends badly. It makes you much less vulnerable to a bad first hire, which unfortunately, does happen. 
  3. If you’re non technical, avoid making technical assumptions. When it comes to development, some seemingly complex things are trivial, and some seemingly trivial things can be incredibly time-intensive to add. It is important for you to trust your developer, to respect their estimated degrees of difficulty, and to not micromanage. That said, it is worth doing the work upfront to feel very good about your engineering hire. It can also be helpful to have an outside technical resource that you can bounce basic assumptions off of (e.g does two weeks to build out a graphing dashboard make sense?)

With those pieces of advice in mind, it’s time to find the engineers to build your MVP. I normally see founders look at five main sources — agencies, Toptal, Upwork, AngelList, and Fiver. 

 I’ll go through them one by one, but first, here’s a TL;DR summary. You should use 

  • an agency if money is of no concern, 
  • Toptal if you have time, (less) money, and few tech skills
  • Upwork if you are comfortable taking a risk, very cost-conscious, or able to thoroughly vet candidates. 
  • AngelList along with Upwork (it’s more focused on full-time employees and with a smaller talent pool)
  • Fiverr never


Full service agencies promise the world, and sometimes, they deliver it. They normally pitch an approach where you give them the project details, and they can handle everything from design to tech specs to development to QA to release. Working with an agency is generally more opaque, hands-off, and expensive than trying to work with developer(s) directly.  That management layer needs to be paid for somehow, and they are, through the prices you pay the agency. They also generally charge high upfront project deposits that can be cost-prohibitive for new companies. 

When their work turns out good, it is high-quality, cohesive, and takes some serious weight off your shoulders. When it doesn’t, you can be left high and dry midway through a project. In my experience, you really get what you pay for with agencies. If the price sounds too good to be true, it is. 


Compared to the free-for-all nature of the other platforms, Toptal is a guided tour to finding a freelancer. You start using their service by getting on a call with a “matcher.” You explain the project and what you are looking for, and the “matcher” introduces you to potential fits that have already been interviewed and vetted by Toptal. You then get to interview the different suggested candidates yourself, and if you want, hire one. This approach has serious pros and cons. 

On the plus side, you completely avoid a lot of the outright scams and fraud that can be prevalent amongst online freelancer sites. If you are non-technical, you can feel comfortable knowing that Toptal has done both personality and technical interviews, and the candidate is who they say they are. I’ve worked with a lot of great  freelancers from Toptal, and the average quality is the highest of all freelancer platforms I’ve used.

However, Toptal does have large drawbacks. First, you are basically at the mercy of your “matcher.” I have seen cases where the matcher doesn’t set up many introductions, or is slow to respond. Other times, the matcher doesn’t have a good understanding of your project (or the project is badly explained to them), and you’ll be introduced to candidates that are clearly not a fit. This can be frustrating, and outside of badgering your matcher, you don’t have meaningful direct control over the speed or quality of matches. Finally, this extra layer of vetting and staff need to be paid for, and that is reflected in the general higher rates that Toptal freelancers charge. From my experience, freelancers on Toptal are not meaningfully cheaper than devs in New York. 


Decades old and formed by mergers of large freelance platforms, Upwork is the largest freelancer marketplace out there. It is a marketplace that covers every type of skill and experience level. Every job posting you make will be quickly inundated with applications. However, Upwork does close to no verification of it’s candidates. It’s basically a wild, wild west where you’ll find amazing developers for great prices, fraudulent but convincing charlatans, and everything in between. With Toptal, the difficulty is finding candidates. With Upwork, the hard part is sifting through them.

For some ”fun” anecdotes, we’ve had Upwork candidates switch out people between interview rounds, switch out people between the interview and the first day of work, and secretly take multiple full-time jobs and farm out work to lower paid devs. I have also been asked to give references on Upwork candidates who I have never heard of. It turned out there’s a whole series of fake portfolio websites out there that have added Healthie as work experience. Despite all those above stories, we still use Upwork! Why? If you can separate all the noise out, there are some fantastic freelancers on Upwork. If you are comfortable and capable of doing the vetting, and ok with some risk, Upwork has the best price to value freelancers that I have found. 

Here are some tips that have made a big difference to our usage of Upwork.

  • Have your application require specific questions to be answered. Try to make the questions specific enough to your project that candidates cannot just copy and paste answers. These questions lower the number of total applicants, show that the candidate put some initial effort in, and make it much easier to choose who you want to interview. In other situations, a longer application can deter good candidates, but that will never be an issue with Upwork. 
  • Be very selective about who you interview. Your big cut of candidates should come between the application and the first round interview. Otherwise, you will spend way too much time on video calls with clear non-fits. 
  • Require video to be turned on for all interview rounds. I like taking calls without video personally, but this is an important verification step
  • In the interview, make sure the person’s description of their experience and work timeline matches what was in the Upwork application. 
  • Take a screenshot of the person you interview, and at every round of the interview. Make sure that the picture matches anything online (e.g LinkedIn), and also that it is the same person at different interview rounds. This sounds insane, but candidate swapping (e.g a different person interviews than applied, or different people do different interview rounds) happens regularly. 
  • Ask for references, but don’t stop there. You want to do due diligence on the reference, both to ensure that a) the reference company is real b) the person you speak to actually works at the company. Candidates will provide fake work experience, and even fake references. If possible, you want to speak to a technical person at the reference company. 
  • If you move forward with the hire, hold them to a high initial standard of a) joining a daily check-in on time, and b) joining with video on and giving their update. This helps cut down on the farming-out-work problem, and you can be a lot more lenient once you get comfortable with the dev. 


AngelList is similar to Upwork. Anyone can join AngelList, and they do not vet candidates for you. Compared to Upwork, AngelList is more full-time focused, and is more U.S-centric. In general, it takes minimal extra time to post the same job on Upwork and AngelList, and there is no harm in doing so. 


Fiverr can work well for odd-jobs (e.g freshening up the design of a pitch deck), but your MVP is not an odd-job. Personally, I’ve had bad results with even trivial non-programming projects I’ve tried to use it for. It’s not a fit for this.