Tyler A. Young’s Blog

Since I made the decision to go independent and build SleepEasy, I’ve faced a couple points where I needed to decide whether to build a particular feature from scratch myself or buy someone else’s code to do the job.

In my years of working at small software shops, the common refrain was that we would consider buying tech to solve a problem if it wasn’t core to our business or part of our unique selling proposition. I don’t really feel like that principle applies at the MVP stage of SleepEasy, though. As I’ll discuss below, I happily considered shelling out to a third party for a core feature of my app, just because the value to customers is in the way that feature gets wired up to their web site. At this stage of the product, having something to fill a gap is better than spending months trying to make the best, most unique version of a feature.

Unsurprisingly, cost is also a much bigger factor for me than it was at my Real Jobs™. When you’re paying a developer, say, $15k/month, it’s easy to justify spending thousands of dollars buying a solution if it lets you use that developer’s time for something else. In my case, of course, SleepEasy’s current lifetime revenues amount to $0, so that calculus doesn’t quite work the same. At the same time, though, there’s an opportunity cost to me not having a Real Job. Every month I’m trying to bootstrap SleepEasy is a month my family is foregoing tens of thousands of dollars, so if the business is going to fail, it’s better to do so quickly. The right amount for me to be willing to spend, then, is not $15k per month of dev time saved, but it’s also quite a bit higher than $0.

So that’s where my head has been on these things. I have three examples I can share for how those ideas have worked out.

Eric Ries’ book The Lean Startup popularized the idea of the minimum viable product: the smallest version of a product that allows the creator to learn about the market, their customers’ needs, and what the next steps should be. Over the last week, I’ve really shifted my idea of what “minimum” means with respect to SleepEasy’s MVP—what’s really required for customers to get value out of it and for me to get feedback.

It started with asking myself: if I commit to shipping by December 1 to early access customers, what can I push back and what absolutely must be ready if the product is going to be worth paying for?

There’s an exercise for founders that strikes me as really valuable:

Suppose it’s a year from now and the business has failed.

Why did it fail?

This is surprisingly insightful. In the case of SleepEasy, the biggest risks are not technical… after all, I’m basically building a Cadillac version of website monitoring. There are certainly some interesting technical challenges (we’ll get to those), but it’s not like I’m trying to build a wearable lapel pin to replace the smartphone. 👀

These are the slides for my talk at the Denver Erland and Elixir Meetup from November 6, 2023.

• Download the Keynote file (23 MB)
• Download the PDF (4 MB)

As you may know, last week I sort of quit my job to start a website monitoring service.

The key differentiators of that service are:

1. “Done for you”—you just point us at your domain, and the monitoring just works… no configuration necessary.
2. Capable of way more advanced checking than competing services, including running login, account creation, and ecommerce/billing flows against your live site.
3. No false positives—all issues get reviewed by a human before alerting your team.

That service now has a name and a web site (yay!). If you’re interested, you can sign up there to get in on the early access program as soon as it’s ready.

I thought I’d share a bit about how I came to the name, and some of the challenges I ran into getting there.

If you’ve never tried to name a service, it’s kind of miserable. You’re putting your blood, sweat, and tears out into the world, and you have 2-4 words with which to pique someone’s attention enough to get them to look deeper into what you’re offering. The perfect name will:

1. Communicate what your thing is or does
2. Communicate why someone would want it
3. Be memorable
4. Not be a mouthful
5. Have a matching domain available, ideally .com
6. Be unique—not just among product names, but among all trademarks, which may include regional consultancies that use your would-be name as a tagline on leaflets at the local chamber of commerce (but I’m not bitter 😒)

It’s easy enough to satisfy some of those, but all of them is pretty much impossible. That’s led to me spending an absolutely embarrassing amount of time digging through trademark and domain registries trying to find the perfect name.

In my service’s short life, it’s gone through 3 names and 3 brand identities. First, I was calling it “Is Prod Okay?”, a name I rather like for appealing to SaaS folks, but I worried the name would be alienating if it turned out that ecommerce shops running something like WordPress were a better client base. Next, it was just called “Site Monitor.” It certainly communicates what the thing does, and I did like the potential SEO benefits of the name being an exact match for a bottom-of-funnel search term. Ultimately, though, that name leaves a lot to be desired on the branding front… it certainly doesn’t communicate the benefits of the service or what makes it unique from dozens of competitors.

Then, inspired by a discussion with Andrei Soroker on Elixir Outlaws, I wanted to call it “SleepWell.” That did a good job of explaining the benefits—you can have confidence your site’s core flows are working as intended—but unfortunately there’s already a company in the monitoring space using the name. Same goes for “RestAssured” and other variants.

That’s how I got to “SleepEasy.” I’m not in love with the name (a friend teased that it sounds like a bad translation), but it’ll do for now. It gets at the benefits, and you certainly can’t fault it be not being unique. There are still a handful of names I’m kicking around that I might eventually pivot to, but for now, I have to cut myself off and get back to building the damn thing. An imperfect name won’t make or break the service, but not getting it in front of customers will. I’m steeling myself for a future “SleepEasy is now _________” email, though. 🤪

I’m definitely interested to hear any feedback you might have on either the name or the site!

In the spirit of Halloween, I’d like to tell you a scary story. This one, though, is all the more scary because it’s true.

It was a dark and stormy night, and two software developers were working late to ship a new internal service for their team. The finishing touch was to add production tokens for Google OAuth so their peers could sign in without manually creating an account.

They slowly opened the GCP console, the web page loading so slowly you could almost hear it creeeeeeak across the wire.

“This storm must be messing with the wifi,” said the senior dev. “Weird.”

I sort of quit my job.

I say “sort of” because I’m going to be gradually winding down my work on Felt, where I’ve been for the past couple years, in order to gradually ramp up the amount of time I spend working on my own business.

That business is a new take on website monitoring. Existing monitoring focuses on uptime (“is my site down”), which is fine, and sort of table stakes. But I think there’s a market for being way, way more proactive about monitoring… alerting you before there are problems, or alerting you about things that might be damaging to your business or your reputation, but which aren’t captured by the most basic “is the site responding at all?” checks. At the same time, existing solutions are just massively more complex than they need to be… starting from the way they bill (“$x/month for y monitors”) through the amount of configuration required to get them to just do what you want (“tell me if my site is broken”). And don’t even get me started on the false alarms… in the course of my career, I’ve had maybe 10× more wakeup calls at 2 in the morning from false alarms in a monitoring service than actual issues with my website!

So I’m building a site monitoring service… it’s going to be:

• Absolutely dead simple—just tell us the web site you want us to monitor and we do the rest
• Way more capable than any other service on the market (for instance, maybe your web site is online, but one of your business’s key user flows isn’t working—login, new account signup, checkout, billing, etc.—we’ll alert you about that)
• Guaranteed to never produce a false alarm—if you get a 2 am phone call, it’s because your stuff is actually having a critical incident!

This is the slide deck from my conference talk at ElixirConf 2023.

Download the PDF

The talk references this little microframework we put together to implement David Bernheisel’s “Batching Deterministic Data” recipe from his Safe Ecto Migrations series.

This is a tiny little to-purpose framework for data migrations we’ve used at Felt. It’s based on David Bernheisel’s outstanding Safe Ecto Migrations series, specifically his Batching Deterministic Data pattern for backfill migrations.

I recently released my first side project in years.

CBTea is a privacy-first tool for doing cognitive behavioral therapy (CBT) automatic negative thought records.

The idea here is that you:

1. Record a negative thought
2. Categorize it into a few common cognitive distortions
3. Come up with some “challenges” to push back on the automatic thought
4. See if you can find a new way of thinking about the situation that’s more healthy/accurate

The app is based on an old open-source mobile app called Quirk CBT, which was amazing in its day… and then they took VC funding and had to try to turn it into a business. 😭

I have big plans for the future… I’d like to add end-to-end encryption, support for using it without creating an account at all, offline support, and so on. The GitHub issue tracker has the world’s most basic roadmap.

I had someone tell me their company is considering moving away from Elixir because they’re worried they can’t hire enough devs. (They currently employ, um, 3.)

This is a bad reason to move!

Instead, here’s a brief guide to hiring in niche languages, using Elixir as an example.

At this point, I’ve seen a handful of companies execute on maybe half these strategies half well. Every single one of them had more qualified applicants than they could hire. (Which means they got to be extremely choosy about who they picked!)

We’ve had a persistent problem at work with Elixir tests of Phoenix Channel interactions failing in CI only. The simplest push + reply you can imagine may, due to the vagaries of low-end, shared CI hardware, wind up taking a full second to receive a reply. 🥴

I’d been fixing these one at a time by adding a third timeout parameter to my assert_receive, assert_push, assert_reply, and assert_broadcast calls.

TIL you can instead just do:

config :ex_unit, assert_receive_timeout: if(ci?, do: 2_000, else: 100)

(In the main ExUnit docs, search for :assert_receive_timeout.)

Phoenix LiveView 0.19.5 and later include my very modest PR to use this as the default timeout for LiveView’s message-receiving test functions too (assert_patch, assert_redirect, assert_push_event, and assert_reply).

TIL that from a browser’s JavaScript console, you can use the copy() function to write a value directly to your clipboard.

I’ve been using the mouse to highlight the output for so long!

This is the video and slide deck from my conference talk at ElixirConf 2022.

Download the PDF

TIL in Postgres, if you do this:

SELECT * FROM things WHERE property NOT IN ('foo', 'bar', 'baz');

…it won’t take rows where property was NULL.

Surprising, but under the hood, it’s trying to do an equality comparison, which never works on NULL.

Further discussion on StackOverflow

TIL in TypeScript you can have type predicates, where the return value of your function indicate the type of an argument.

Instead of:

function isUserRole(role: string): boolean { }

…you can do:

function isUserRole(role: string): role is UserRole { }

That can be used to inform the type system of the value’s type, letting you do this:

const validatedRole =
  isUserRole(roleInput) ?
    roleInput :
    undefined;

…and use validatedRole as an optional UserRole rather than just a string.

Suppose you have a Stream of values that you want to insert into the database. You can do this easily in many modern programming languages, but here’s what it might look like in Elixir:

Algorithms give a name to a kind of data transformation. They’re the building blocks of programs, and they’re fractal: a program as a whole can be seen as an algorithm, and it’s made up of many smaller algorithms; those algorithms are in turn made up of smaller ones.

Over on the Felt blog I wrote about how we pushed our continuous integration (CI) system for Elixir to enable devs to be more productive. The examples are all in GitHub Actions, but you can probably translate it to whatever CI system you’re using.

The highlights:

1. Deploy a staging environment (a complete reproduction of our production environment) for every PR, and update it as new commits get added
2. Run most CI jobs in parallel so that you get the fastest feedback, and make the jobs never “fail fast,” so you’ll know all the things you need to fix on the first run
3. Refactor boilerplate for setting up and caching the project into shared “composite” actions
4. Clear the build cache when a human asks for a retry, neatly resolving mistrust of build caches
5. Report code coverage in the GitHub PR description, and update it as new commits are added
6. Run as much static analysis as we can
7. Use Dependabot to get PRs to update our dependencies

Read the full post

Jump to the sample project