OK, the title might be a bit “click-baity” 😅

The truth is, Kamal is super cool to setup!
I have never deployed an app from scratch so quickly.

I did end up spending time into 4 rabbit holes though, so I wanted to keep notes about what happened and how to overcome the issues I faced.

You know, just in case.

Multi-arch build issues

The first issue I encountered was somewhat of a tricky one, although the fix was simple in the end.

It's always like this, isn't it? 😅

After I setup Kamal for my project, I ran kamal server bootstrap followed by kamal deploy, as instructed.

Colorful logs started flowing on my screen and I sat back, amazed by the simplicity of it all.

The Docker build process started. Along came the bundling step, and gem names came trickling down the terminal.

And then, it hung. For a few minutes.
I thought it must be doing something big, and it was late, so I went to bed.

The next morning, it was still stuck on the same thing:

 DEBUG [0729c69a] 	#29 668.9 Bundled gems are installed into `/usr/local/bundle`
 DEBUG [0729c69a] 	#29 668.9 Post-install message from rubyzip:
 DEBUG [0729c69a] 	#29 668.9 RubyZip 3.0 is coming!
 DEBUG [0729c69a] 	#29 668.9 **********************
 DEBUG [0729c69a] 	#29 668.9 
 DEBUG [0729c69a] 	#29 668.9 The public API of some Rubyzip classes has been modernized to use named
 DEBUG [0729c69a] 	#29 668.9 parameters for optional arguments. Please check your usage of the
 DEBUG [0729c69a] 	#29 668.9 following classes:
 DEBUG [0729c69a] 	#29 668.9   * `Zip::File`
 DEBUG [0729c69a] 	#29 668.9   * `Zip::Entry`
 DEBUG [0729c69a] 	#29 668.9   * `Zip::InputStream`
 DEBUG [0729c69a] 	#29 668.9   * `Zip::OutputStream`
 DEBUG [0729c69a] 	#29 668.9 
 DEBUG [0729c69a] 	#29 668.9 Please ensure that your Gemfiles and .gemspecs are suitably restrictive
 DEBUG [0729c69a] 	#29 668.9 to avoid an unexpected breakage when 3.0 is released (e.g. ~> 2.3.0).
 DEBUG [0729c69a] 	#29 668.9 See https://github.com/rubyzip/rubyzip for details. The Changelog also
 DEBUG [0729c69a] 	#29 668.9 lists other enhancements and bugfixes that have been implemented since
 DEBUG [0729c69a] 	#29 668.9 version 2.3.0.

A second run led to the same issue.

So I started searching, and found a few threads about the problem. The one that led me to a solution is Discussion #747 on Kamal’s repository: Deploy stucks on message about RubyZip 3.0 coming.
Someone in there hints at the issue coming from Kamal building a cross-platform Docker image by default, targeted for both AMD64 (Intel/x86-64 compatible processors) and ARM64 (ARM architectures such as Ampere processors).
Apparently building for ARM64 from an Intel CPU tends to fail and hang, at least on a Mac.

Since I am building on an Intel Mac but also for an x86-64 server, I don't need to build for ARM. So I disabled the ARM build, and everything went smoothly after that!

Everything?
Well, not exactly.

Using GHCR as Docker registry

As hinted above, Kamal uses Docker to build an app “artifact” and deploy it onto your servers. In the process, it needs to push the locally built image to a container registry, from which it can pull it again for deployment from your servers.

Since I'm using GitHub to host my code, I wanted to keep things simple and use their Container Registry feature as well, instead of Docker Hub.

It's pretty straightforward to setup Kamal for this:

The KAMAL_REGISTRY_PASSWORD comes from your .env file at the root of your project.
For things to work with GitHub Container Registry, you have to use a new Classic Personal Access Token (PAT) as your password.

I did this, but unfortunately it did not work immediately: as soon as Kamal tried to push the built image, it failed with an error:

Error: unexpected status from POST request to https://ghcr.io/v2/techtrails/real-emails/blobs/uploads/: 403 Forbidden

Kamal does manage to log into the registry as its first step, so the error was a bit unsettling: why could it log in, but not push an image to my repository registry?

Since I'm not pushing to my user GitHub (https://github.com/olance) but to my Techtrails organization (https://github.com/techtrails-io), I thought it might be an issue with my PAT and the rights it had to push to my org.

I spent a lot of time trying different tokens and tweaking settings on GitHub.
To no avail.

The 403 error really misled me into looking for token issues, but it was actually much simpler: as you might have noticed, I was pushing to techtrails/real-emails, whereas my GitHub org name is techtrails-io.

Yeah, techtrails was already taken :(

Kamal generates the push URL from the image setting in the deploy.yml file:

So I changed techtrails into techtrails-io, and it worked!

Subscribe now

TLS and CloudFlare

At this point, I had my app successfully deployed to real-emails.com.
It's there, you can check!

There were a few things, SSL/TLS-wise, that were not 100% satisfying.

TLS termination point & redirection loop

I'm using CloudFlare as my DNS server, taking advantage of their Proxy feature that serves my site through their own infrastructure, allowing them to cache content at the edge, detect DDoS attacks, etc.

They also provide automated TLS certificates out-of-the-box, which is great.
To make this simple for everyone, the way it works is that their servers act as a TLS termination point:

As illustrated above, a request coming from a client will be encrypted only between the browser and CloudFlare’s servers. CloudFlare relays the request to my servers in plain HTTP, without TLS encryption.

With a Rails application, what this causes when you load your website is an redirection loop, because Rails is configured to force SSL connections by default:

So when CloudFlare relays the browser’s request to Rails as an HTTP request, Rails responds with an HTTP Redirect from http://real-emails.com to https://real-emails.com.
This triggers a reloading of the HTTPS URL by the browser, which again is responded to with a redirect… and thus the loop begins.

My first fix to this issue was to turn config.force_ssl to false. Easy!

This, however, feels hacky and suboptimal. Plus it caused another issue that I forgot to note down.
And, I do want end-to-end encryption between the browser and my server.

So what I really want is …

CloudFlare “Full (strict)” encryption mode

In this mode, you get end-to-end encryption and a certificate provided by CloudFlare that allows them to certify they're talking to your origin server.

I think I'll write a specific tutorial to configure Kamal for this setup, but here’s the gist of it:

• Store CloudFlare certificate on your server

• Declare a Docker volume for the Traefik service to get access to this certificate and am accompanying TLS config file

• Configure a TLS entryPoint on Traefik and route it to your app’s service

Traefik is the reverse proxy Kamal is built upon to route requests to your application. In CloudFlare’s Full (strict or not) encryption mode, it's Traefik that becomes the TLS termination point, right before Rails serves your app.

So what you have to do, as outlined above, is just to provide it with the right TLS certificate and be done.
It’s even easier if you don't aim for strict mode (but I thought, let's go all the way!) since Traefik can provision certificates for you with Let's Encrypt.

Anyway. The simple yet terrible mistake I made here is that “Traefik” is simply the phonetics transcription of “traffic”, and some muscle memory at some point made me write “traefic” in the Docker volume name configuration 🤦‍♂️

Only after I left the broken site for a night and came back to it with fresh eyes and a thorough review of Traefik logs (which only indicated it hadn't found any certificate) did I understand my mistake.

Bonus: conflict with foreman

As an added bonus, I finally faced a seemingly unrelated issue when I got back to developing locally.

Since I'm using TailwindCSS, I have the cssbundling gem installed to rebuild my styles as I add new Tailwind classes to my templates.
This is handled by a separate process, so I'm using the provided bin/dev command instead of running rails server.

bin/dev is provided by the gem, and simply uses foreman to run both rails server and rails tailwindcss:watch in parallel.

What happened after I had completed my Kamal setup, is that:

• running rails server would work just fine

• running bin/dev would see the rails server process fail with an error: ActiveSupport::MessageEncryptor::InvalidMessage

This error generally occurs when Rails, upon booting, is not able to decrypt the credentials.yml.enc file that contains the secret_base token and other credentials you might have stored there.

It made no sense though, that it would work when run alone and fail when run through foreman.

To figure out what was going on, I edited Rails core files to place a debugger instruction right before the code that would throw the ActiveSupport::MessageEncryptor::InvalidMessage exception.

This allowed me to run rdbg (a command-line Ruby debugger) and attach to the process, which in turn let me inspect live variables content and see what the process was dealing with when crashing.

This is the code I dove into:

From decrypt_and_verify, in which the first catch_and_raise method was the one ultimately causing the crash, I could verify that the message argument contained the encrypted content of my development credentials.yml.enc file.
As I would expect in this context.

Later on, the read_message call leads to the decrypt method.
In there, I inspected the @secret instance variable, and found that it contained my production encryption key.

No surprise it couldn't correctly decrypt the file!

Now the question was: how did Rails, started in development mode, was picking up the production key instead of the development one?

After some thinking and digging, I inspected the content of ENV["RAILS_MASTER_KEY“], which is one way for Rails to get the decryption key.
It was indeed set to the production key.

That's when I realized what was going on:

• One one hand:
  When initializing Kamal, it creates a .env file into which you can provide environment variables for your deployment.
  If you recall from the beginning of this article, this is where the KAMAL_REGISTRY_PASSWORD value comes from.
  
  The other value that you need to put there, is the RAILS_MASTER_KEY encryption key, so that Kamal can set it on the deployed container for Rails to boot correctly.

• On the other hand:
  Foreman, used in the bin/dev script, will by default load environment variables for the spawned processes from any .env file it can find in its working directory.
  So it picks up the one from Kamal, and “corrupts” your local process with environment variables meant for production.

It's hard to tell whether Kamal or Foreman is at fault here, but once I understood the issue I quickly found a PR on GitHub that addressed the problem: Disable loading .env file when running foreman for development.

Simply tell foreman to load environment variables from /dev/null (or another arbitrary file if needed) in the bin/dev script:

The end.

Failures

It's early morning on Thursday where I live, and this is what real-emails.com still looks like online:

And here's my current status:

• Friday:

  • ✅ Project setup

  • ✅ User registration & authentication

  • ✅ API service with API key authentication

  • ✅ Endpoints specifications

    • 🐰 Studied existing APIs with the same purpose, such as check-mail.org or Mailjet’s validation API.a

• Sunday:

  • ❌ Blocklist matching implementation

    • 🐰 Spent some time exploring existing blocklists and their sources, documenting myself on risky domains & spam detection, etc.

  • ❌ Dynamic checks & results caching

• Monday:

  • ❌ Payment setup & implementation

• Tuesday:

  • ❌ Server provisioning

  • ❌ real-emails.com domain configuration

  • ❌ Deployment preparation

• Wednesday:

  • ❌ Production deployment

  • ❌ Live tests

I have barely done more than what I thought I could achieve on Friday evening.

On top of that, I wanted to post daily on X, but I haven't sent a single message besides the project announcement.

All in all, it's not brilliant.

But I can't say I'm disappointed with myself, though, and here’s why:

Learnings

A few months ago, I set out to join the Indie Hackers movement and “build in public”.

In my very first post, I wrote:

My objective: personal fulfilment and financial autonomy.
But to be honest, I have no idea where this will take me.

What I do know is that it took me a long time to dare, and that I will learn many things along the way. Through failures and successes alike.

This small project with a short deadline is probably the best choice I could have made to put myself into learning mode.

Why? Because a short-term goal is much more motivating.

I still like Speakerine’s idea, but it is a larger project that I can only finish in a longer time frame.
Pivoting to a smaller project and imposing a short deadline gave me much more valuable information on:

🎯 How well can I focus on delivering what's needed and forget the rest?
It starts with framing the idea and giving yourself precise objectives. I think I did this part well enough.

However, I do tend to lose focus while I work and start exploring adjacent topics, or things I think “would be nice if the project works”.
Well, get it to work first!

👨🏼‍💻 How efficient am I when it comes to coding?
Clearly, the last few years of not coding at all and the last decade+ of not coding with Ruby/Rails have made me rusty.
And I did try to learn Rust, but that's not what I mean 😅

Whatever I build at the moment requires some back-and-forth between my code and the docs or between my editor and my browser to test things out.

The last few days have made me more confident, and I can feel that I'm catching up on things I once mastered, but I'm still feeling quite slow.
I also tend to overthink my code & architecture, so I'm trying to stick to the YAGNI principle: You Ain't Gonna Need it!

Hopefully, I'll get back to better speeds soon!

👨‍👩‍👦‍👦 How much time & energy can I dedicate to this?
This is maybe the biggest thing: I have a regular job and a family.
When I return home from work, my top priority is not, and should not be, my indie projects.

It's my family.

Only when everyone is fed, washed and tucked in bed can I start working again.

It usually means starting a bit late and, as a result, going quite late to bed. Which makes me tired and is not sustainable on the long run.

And of course, it's also important that I keep some quality time with my wife. This is something that's easy to neglect when you're head-on in your projects.

To be honest, that's the one main impact I've noticed from setting this one-week deadline for myself: duties done? Let's get to work!

Moving forward, I have to take that into account and set reasonable expectations for myself — there is actually no way for me to work every day or night on my projects.

So, where does this leave me?

Next steps

I am like most developers: too optimistic with time estimations.

On top of that, I have constraints I must take into account to plan my projects realistically.

Pushing myself to work on real-emails.com, something I consider quite a small project, was a great way for me to have this reality check I needed!

Now I do want to finish and deploy it, as the next step will be to work on marketing it and getting some sales in.

This time I'll give myself until end of next week to have my v1 live on real-emails.com.

I'll keep reporting here; see you soon!

First, Disney was fantastic 😁

But unfortunately, I'm late on my planned schedule!
Kinda like Alice in Wonderland’s White Rabbit 🐰

Two reasons for this:

• Starting up the Rails project took me more time than I expected

• I went down into a few rabbit holes, but I'm getting better at noticing and pulling myself out of them!

• I did not find as much time as I thought I would on Sunday

Here's my current status:

• Friday:

  • ✅ Project setup

    • Rails project with Turbo/Stimulus and Phlex

    • 🐰 Lots of boilerplate to setup for Phlex. I'll need to build myself a reusable lib to kick things off faster

    • 🐰 Spent too much time on UI/design on top of that

  • ✅ User registration & authentication

    • Using Devise + devise-passwordless

      • 🐰 devise-passwordless’ implementation isn't in line with what I had in mind.
        Even though I'm not a huge fan of them, the beauty of Magic Links is that you don't have to worry about the user being already registered: just show an email field, create a new user if needed and shoot the email link.
        Unfortunately, the gem did not merge sign-up and sign-in this way, so I had to override their sessions controller.

    • Some minor fine-tuning remains

  • ❌ API service with API key authentication

  • ❌ Endpoints specifications

• Sunday:

  • ❌ Blocklist matching implementation

  • ❌ Dynamic checks & results caching

• Monday:

  • ❌ Payment setup & implementation

• Tuesday:

  • ❌ Server provisioning

  • ❌ real-emails.com domain configuration

  • ❌ Deployment preparation

• Wednesday:

  • ❌ Production deployment

  • ❌ Live tests

Ouch! That's a lot of red 🙈

Hopefully, I will be able to accelerate now that I have the foundations in place.
For the moment, I think I can still meet Wednesday’s deadline.

I would probably shift it to Friday if I were on a freelance contract. 😅

Anyway, here's what it looks like at the moment:

As I wrote above, some fine-tuning is still needed on the login flow. Right now, it redirects to the homepage after sending the email, which isn't great.

It should be done quickly, and then I can move on to the core part: the API.

Stay tuned :)

My deadline is 6 days away. If I want to make it, I have to have some sort of plan.
In this first update, I’ll take you through how I go from an idea to a plan.

The idea

Here’s a template I like to use to keep track of my ideas.
It’s very simple but helps me see more clearly where I want to go.

💡 One-sentence idea pitch

Real-emails.com is an API that lets you find out whether an email address is temporary/disposable or legitimate.

🤝 Value proposition

Collect email addresses you can trust

🗣️ Target audience

• Anyone accepting email addresses from their users who wants to make sure they’re not garbage

  • SaaS owners

  • E-commerce owners?

    • making sure customers register with a legitimate address

      • could make sense when you get 10% off your first order by subscribing to the store’s newsletter

  • Landing pages & lead magnets builders

  • Newsletter authors?

    • Probably newsletter platforms

  • Fintechs (disposable email = fraudsters)

💰 Business model

I see several possibilities here:

• Subscription (yearly/monthly)

• Pay-as-you-go with per-check pricing

• Lifetime deal

💬 Product description

• This is an API-first product—it’s meant for developers integrating email validation into their own products.

  • The « product surface » could ultimately be larger and include:

    • open-source API clients for various languages

    • platform plugins to provide plug & play integration with the service

• It’s quite simple: send an email address (or domain) through the API, and it will respond with a status (disposable or legit).

  • It might be interesting to have a bulk check feature too

⚙️ Resources

• Disposable email providers:

  • Google results for « temporary email », « disposable email », « burner email », …

  • disposable-email-domains GitHub repository
    → lots of domains are listed already, although 100% of recent Yopmail domains I have tested are absent.
    → Interestingly, they also have an « allowlist »

    • I could automate contributing back to that repo at some point!

My constraints

Before moving on to the plan, I think it's good in this instance that I outline my personal constraints. They will be key to gauge what I'll be able to deliver.

• I've got a job, so every weekday I can only work during the evening

  • That's 4 days out of 6 remaining

• On Saturday I'm going out with my son for his birthday!

  • Pretty excited about this as we’re going to Disneyland, but that means I actually have 5 days remaining to work on real-emails.com

Since I want to deploy something next Wednesday, I'm thinking:

• 🧑‍💻 Get the basic service done by Monday evening

• ⚙️ Deployment setup (server provisioning, domain config and so on) on Tuesday evening

• 🚀 Production deployment and troubleshooting on Wednesday evening

The job to be done

From my basic idea description, what I like to do next is make a list of what I have to build. I usually break it down into Proof of Concept, Prototype and MVP phases (with meanings that might be my own…).

As I've already done some technical validation that could be considered a Proof of Concept, I'll keep things simple here and merge Prototype/MVP into one phase.

Let's call it the Get it done! phase 😄

Get it done!

As you'll see, I try to be exhaustive and will list both the very basic & more complicated stuff.

I try to use my idea “brief” as an anchor to decide what's a 🟢 must have, i.e. key to execute on the value proposition, versus a 🟡 nice to have or a 🟠 maybe later.

So, here's what I have to build.

Build an API service

• 🟢 Basic JSON API

• 🟢 API authentication

  • 🟢 API key associated to subscribed user

• 🟠 API throttling & rate limiting

Identify disposable/temp email providers

• 🟢 Gather list of temp email providers

  • 🟡 Automatically update blocklist sources

  • 🟢 Identify their domains lists and dynamic features

    • e.g. Yopmail enrols new domains regularly, emailnator generates dummy Gmail addresses, etc.

• 🟢 Match provided email domain to blocklist

• 🟢 Dynamically identify provider domains in case of blocklist miss

  • e.g. detect a newly added Yopmail domain that hasn't made it to the list yet

  • 🟢 Cache results for faster lookups

• 🟡 Process & check emails in bulk

  • 🟡 Implement async processing

    • 🟡 with task API? (i.e. get task status/result)

  • 🟠 Implement webhook notifications

• 🟠 Allow flagging of false positives & false negatives

Let users subscribe & pay

• 🟢 User registration & authentication

• 🟢 Accept payments

  • 🟢 Activate API key on payment

    • 🟢 Implement payment webhooks

Provide integration tooling

• 🟡 API clients in different languages

  • JS, PHP, Python & Ruby at a minimum

• 🟠 Paid-for self-hosted solutions?

  • Could be a Docker image, a Rails engine, etc.

• 🟠 Platform integrations

  • 🟠 Blogs & Content management systems

  • 🟠 E-commerce platforms

Note: I usually use Notion toggles & databases to work on this – sorry if it's not very legible on the newsletter!

Bringing it all together

Given my constraints, I'll only be focusing on the 🟢 must haves for next Wednesday.

One of those tasks hides is an “infinite” source of work though: Dynamically identify provider domains in case of blocklist miss.
Indeed, it's going to be hard to cover all providers by Wednesday… if ever!

So I'm going to focus first on Yopmail and other providers found through Google searches that make use of the same DNS technique to add domains to their lists.

I'll keep Emailnator as a nice to have/maybe later, as their strategy is quite different and will probably prove harder to detect.

In terms of user authentication & payment, I found iffy.com’s approach simple and efficient:

1. Just provide your email address to log in – I'm not a fan of magic links so I might try to add Google/Apple login along with it, but for an API service it feels OK to me.

2. Once logged in, you get metered access to the API (3 calls per day) for free

3. If you want to subscribe, a click on “Pay for more” will bring you to a Stripe Checkout page to start your subscription

It's good inspiration but I'll make things much simpler to start with.
For instance, I think I will initially only implement a lifetime access deal. It will make since much easier regarding API key management, as I won't have to monitor recurring payment status to invalidate keys and so on.

So! Here comes the plan :)

• Tonight:

  • Project setup

  • User registration & authentication

  • API service with API key authentication

  • Endpoints specifications

• Sunday evening:

  • Blocklist matching implementation

  • Dynamic checks & results caching

• Monday evening:

  • Payment setup & implementation

• Tuesday evening:

  • Server provisioning

  • real-emails.com domain configuration

  • Deployment preparation

• Wednesday evening:

  • Production deployment

  • Live tests

See you on Sunday!

Handling competition

A lot has happened to my perception of my Speakerine project in the past 10 days.

Some time ago, I discovered some mobile applications that I could consider to be competition.

One of them is Omnivore.
It's open source. So it's free. And it honestly looks good!

It is competition because it's a read-later app that offers text-to-speech capabilities. It's got great feature ideas, too! For example, you can create emails linked to your account to receive newsletters directly in the app.

When I discovered this app, my inner voice went all “That's it, you should quit” on me.
Somebody's already there and they're doing a great job, just leave it.

But then I figured that's not how I should think about it.

Omnivore is not competition.
What I want to build with Speakerine has a very strong focus on audio, not on reading.
It is not “for serious readers"; it is for people who don't have time to read.
It's about curating your daily reading list of articles and getting a playlist to listen to out of it.

Of course, I did not jump instantly from the first feeling to the second.
I was surprised, though, that this became my conclusion. Competition has always made me anxious, and it's hard for me to ignore it.
But here, what it really did is help me strengthen my “product vision” (let's call it that) for Speakerine.

Good for me :)

About cattle & pets

Some of you already know I'm part of the Small Bets community (hey, small betters! 👋). I should write later about the benefits of belonging to such a community.

One thing that's been repeated several times in Small Bet’s chat is:

Treat your projects like cattle, not pets

When you get too attached to a project and treat it like a pet, you might fail to see when it's time to stop it. Cattle, on the other hand, is dispensable.

Well, what Omnivore helped me realise as well is that Speakerine might be too big of a cow for me right now. Here's why:

Technically speaking, I know where to go and what I want to build.

Since Omnivore is open source, I've explored their code, and I can see they have actually solved everything I have in mind:

• Extracting an article’s main content

• Turning that content into audio thanks to text-to-speech models. They even use a secondary voice for block quotes; I love the idea!

• Handling RSS feeds

• And so on, and so forth

Reading their code, I can see how many challenges they’ve faced and overcome while building their apps and the API services to support them.

You know how we sometimes say that knowing your future will ruin your present?
That's the effect Omnivore’s code has had on me: instead of a relatively straightforward road to an MVP/prototype, all I can see now is a winding path full of bumps and brambles.

It let me see the unknown unknowns I was happy to ignore at the moment and made my task look more daunting than it had to be.

I thought about it for some time and saw two main paths in front of me:

• Continue on my current path of building Speakerine as I intended, knowing I will probably face many roadblocks.

• Use Ominvore’s code. After all, it's open source! I could ditch a good part of it and rebuild the front end to match the user experience I'm aiming for.

The thing is, in both cases, it does not really look like a “small bet” anymore.

So I'm starting to think I’m treating this project like a pet, meaning I care too much about moving it forward and finishing it, even when it gets too complicated considering my current situation: two young kids, a 9-5 job, and little bandwidth.

I might need something else.

Setting myself up for success

Let's get back to some fundamentals:

• I haven’t done any serious coding in ~3/4 years

• I haven't built & shipped a full project on my own for 10+ years

• I'm a perfectionist who tends to overthink (could you tell? 🫣)

• I am not, at the moment, particularly good at time management, organising myself for productivity, (…)

I want to build in public to get back to doing all of the above and to have fun.
Ultimately, I'd like to earn money from that, but it will take time. That's fine.

So, my definition of success right now would be:

• I found a simple idea

• I built & shipped it in a matter of days/weeks

• I publicly documented the process

I don't even care if it's earning money in the end.
I'll just kill it if it's a money pit. That's the idea of small bets.

Speakerine is too big for me right now to have this velocity, and I know I would care if it did not earn any money.

That's why I decided to pause the project and get myself back into shape by working on something much simpler.

Introducing: real-emails.com

This is the simple idea: an API to check for disposable/temp email addresses.
I already bought the domain for it: real-emails.com.

There are tons of services offering disposable/temporary email addresses to help people provide fake email addresses they'll never ever check again.

Honestly, I can see why people use them, and I do happen to use Yopmail from time to time…
But when you’re building a SaaS or trying to acquire emails legitimately, you want to make sure you're not being given crap addresses.

Some basic services use only one or a few domain names for their email generators. You could simply list those ones in a blocklist, and you'd be done with them.

However, more serious services like Yopmail.com can enrol new domains every day!

This is where a service becomes useful: you don't have to worry about keeping up-to-date with all those new domains.

So I will build that service, release it, and make it available for a tiny yearly subscription fee or a lifetime deal.

I'm giving myself a week to build it and will try to send updates every other day.

Let's see what happens!

An iPad Pro for photos & note taking ✅

A few years ago, I sold my trusty but aging Macbook Pro and bought a 12.9" iPad Pro.

At this time, my decision was driven by two main factors:

• I needed a light computer to work on my digital photos while on the go – the 12.9 inches screen, its M1 processor and the Lightroom iOS app made the iPad Pro a great candidate. The quality of the Apple Pencil comes as a bonus too, to work on precise masks.

• I wanted something to continue taking handwritten notes at work, but with a digital tool that would allow me to easily search within those notes. The fluidity of the Apple Pencil, paired with the Nebo app for note taking & handwriting recognition, are exactly what I was looking for!

  It turns out it’s also a great companion on conference calls to do some live whiteboarding.

Back then, I wasn’t working on any personal projects, so if I needed to code it was mainly for work, and I already had a MacBook Pro from my job.
I also had « inherited » a 2013 Mac Pro from a previous company, that I could use as a personal workstation at home.

An iPad Pro for coding? 🤔

When I started working more frequently on personal projects, came the question of how I’d do if I wanted to work on them remotely, i.e. while on holidays.

Evidently, I cannot code on the iPad: there’s no terminal, no way to install packages, let alone a compiler or web server of any sort. Damn you, Apple!

Already owning an iPad Pro and a Mac Pro, I did not want to purchase a MacBook Pro if I did not have to. So I thought of ways I could code from the iPad Pro on code hosted elsewhere.

Cloud editors

At the time I was looking into this, cloud editors existed but weren’t as mainstream as they are today.

Github Codespaces was only nascent and not generally available.
Available options, I believe, were mainly Cloud9 (already owned by AWS) and GitPod.

These were great solutions really, but I think several things made me want to find something else:

• I did not want to depend from a third party and end up paying for my setup

• I also had started learning Unity and game development, so I was thinking it might be useful to have access to more than just an SSH session on a virtual machine.
  If could access my actual home computer screen from afar, that would be nice!

As a result, my focus then moved to: how can I code on my Mac Pro from my iPad?

Remotely local coding

I explored different options to make this work, to finally settle on the following:

• Using Tailscale to create a Virtual Private Network between my devices

• Hosting a VSCode server with code-server on my Mac Pro

Subscribe now

On a Mac, installing code-server is just a brew install command away, and Tailscale is even easier to setup both on my Mac and my iPad.
In a few minutes, I got access to:

• My Mac Pro, from my iPad, using a convenient domain name

• A full-fledged code editor, VS Code, with access to all my files

• A terminal, thanks to VS Code, that allows me to run any command on my Mac Pro as if I was using it directly

That’s all I needed to code remotely from my iPad!

As a bonus, I also get access to my Windows machine, as a virtual desktop using Microsoft’s RD Client app. Since I’ve got a good graphics card on it, I can use it for generative AI tools such as Stable Diffusion even when I’m on the go.

The cons

I have been using this setup for the last month or so to code on Speakerine. All in all, it’s going pretty well, but there are some caveats and downsides to it:

• From the setup itself first:

  • If, for any reason, my Mac Pro shuts down or disconnects itself from my home network, I’ve got no way to reach it anymore and can’t code anymore.
    I’m unfortunately talking from experience 🥲

  • An internet connection is required at all times. Coding usually requires one anyway, but with this setup and how VS Code seems to work, you cannot even have a temporary internet-less coding session.

• From the iPad:

  • The absence of developer tooling for Safari on the iPad. I found the Web Inspector Safari extension, but it’s not as powerful as what we’re used to on desktop, and will only serve for basic DOM or requests inspection.

  • Very buggy keyboard support: I have owned a Logi Combo Touch for a long time without using the keyboard much at the beginning.
    Using it more intensively revealed many very annoying bugs: the trackpad will stop working randomly mid-action, as will some of the keys.
    Fixing required switching apps using Cmd+Tab, or sometimes even unplugging/replugging the keyboard.
    I ended up being so frustrated with this that I ordered Apple’s quite expensive Magic Keyboard. Only to realize it’s got similar issues!
    It’s not as bad, but not great either, so I really feel less productive when the first thing I have to do when switching back to my editor is to click on different form fields and back to the code so that I can type again.

In the end…

Retrospectively, in terms of setup, I think a cloud editor would suit me just fine today.
GitPod and GitHub Codespaces both have generous free plans (50 & 60 free hours per month) that would be totally fit for my holidays use case.

What I’d be closing myself to using cloud editors is:

• Development that requires visual tooling, such as Unity or XCode

  • For that matter, any macOS/iOS development since it requires a Mac

• Access to my graphics card for gen AI

It’s not things I need today.
What would remain are the issues from the iPad itself, and the need for always-on connectivity.

Two factors that might push me to buy a MacBook Pro in the end.

Maybe when I do earn money from my indie hacking!

My last post is already a bit more than 2 weeks old. Damn.
It’s not like I’ve been idle all this time though, on the contrary.

That’s why this post will probably feel like when you’ve coded for a long time without committing anything to Git 😬

In the last two weeks, I have…

Set up my Rails project for Speakerine. I had already done the very basic rails new speakerine. I went a bit deeper into the app’s configuration and setup, re-reading Rails guides when needed.

Lost myself in some front-end tech rabbit holes. I haven’t touched Ruby on Rails for like … 14 years 😅
It’s refreshing to see that the framework has remained generally the same, but of course it has evolved a lot since Rails 2.3/Rails 3.0. So there are a lot of things I have to discover and learn, especially on the front-end side where technologies have moved a lot in the past years.

Since I have a TailwindUI subscription, I wondered whether I should use React with Rails. That led me into exploring the assets pipeline options for Rails, and how to integrate React with the backend. Which almost inevitably leads to building an API-only Rails and a heavy front-end.
At some point I thought « that’s getting too complicated », and that’s when I decided to stop .

So in the end, I decided to go with Rails’ defaults: Import maps, Hotwire & Stimulus, and using TailwindCSS for styles.

I actually tweeted about this:

With regards to my usual tweets performance, this one had a decent reach!
It encouraged me to try and continue sharing on X about my building experience.

Subscribe now

I do find it complicated to identify what I should share, though.
That’s why I started journaling, also as a result of reading ’ excellent article on how he organises his work as a solo founder.

I’ve always found the journaling exercise quite complicated to integrate into my routine, and I’ve yet to manage to do it more than two days in a row.

I found I need to be much more intentional about it, instead of waiting for things to « click » and implement themselves into my life.

But more on that later.
Let’s go back to Speakerine for now.

If I’m being honest, I am once again not going in a straight line towards my objective.

I have started by working on authentication using the Devise gem. I’ve spent quite a long time on this, much more than I had anticipated.
No matter how good I was on Rails 14 years ago, I need to shake off the dust and rust on those skills to get up to speed again.

One problem I faced was also solely due to my remote working setup.
I’m using a self-hosted VSCode instance that proxies local open ports through a convoluted URL, which forces me to configure Rails with a URL prefix that messes up URL generation.

Not ideal.

I got things to work though, and continued with setting up my webapp layout.
That’s where I could have probably kept things simpler.
The designs I shared in my last post were quite simple indeed: the app title and a form.

But instead of keeping things that simple, I went on to integrate a TailwindUI application shell with a navigation bar and profile menu.

I try to rationalise by telling myself that I’ll need it and that it’s helping me walk the learning curve to re-learn what I have forgotten.
Which, to be fair, is true.

But it reminds me of an advice a friend gave me a long time ago.
It went kinda like this:

Between learning and shipping, a project can only have one goal.
If you want to learn, start a project you don’t need to ship.
If you want to ship, use tools you don’t have to learn.

It does not mean you’re not going to learn when building something you want to ship, nor that you won’t ship projects used to learn new tech.
Just that the main goal should be one or the other.

And right now, I’m kinda mixing the two.

Maybe it’s a path I have to take anyway since I haven’t developed a full web app for a long time, but I’ll try to be more mindful of this in the future.

Now the next thing I want to get done is tuning Tailwind’s configuration to use the color theme I had in mind.
I’ll try to keep it simple this time. It’s not like I need much branding for the moment.

There, you have it. Two weeks of coding and no writing.

I almost titled this post « To build or not to build, that is the question ».
What I’m realising though, is that building in public is as much about writing than it is about coding.
Striking the balance between the two isn’t simple: once I get into coding, I want to get things done.

But this post is a good illustration of what goes on if I don’t write regularly enough: topics pile on and I can’t get deep into any of them.

As I mentioned before, there are things I need to become more intentional about.

I’ll add writing to that list.

Lately I have found I have to fight against my own self, at different levels.

Life design

Like so many people out there, I just want to be happy.
Trying to build a portfolio of products for myself is one way for me to reach that goal:

• I get to work on my own ideas, from start to finish.

• I get to create again by imagining new products, coding them, writing about them… Creating has actually been missing from my life for a while and it's a real driver for me.

• Ultimately, I'm working towards financial autonomy and thus a lifestyle that I can fully control.

It's actually quite nice, and I feel privileged having the opportunity to try this out.
Yet, as I was saying, I'm having to fight against myself to get the ball rolling.

As told me the other day, I’ve done “some really cool shit in [my] career” 😅
But it also came with a price, and my professional life has kinda made me afraid of success as a result, and shaped me into looking for external validation more than my own satisfaction for a job well done.

Now that I truly want to build something for myself, I'm facing a few blockers.

Things like analysis paralysis and procrastination of course but also, in some rare cases… anxiety attacks.
Those would typically happen when thinking about proving myself or about potentiality of success.

I won't expand more on that today but it's definitely one way I have to fight against myself.

Starting my build in public journey and committing to this newsletter is my way of doing this. So, thanks for reading! 🙂

Lost in exploration

And here's another fight!

At heart, I'm a software engineer. One who hasn't coded for quite a long time, too.
So when I decided it was time to “really” start working on a Speakerine, here's what I did:

• Spent hours reading about the latest JS frameworks and serverless platforms

• Researched affordable hosting solutions and free managed database tiers

• Decided I'd go back to using Rails again

• Installed Rails on my computer & created a new project

• Installed RubyMine and opened that new project

And then I was like: “now what?!” 😅

Said differently, I spent hours looking for solutions to problems I did not have, to finally decide on a tech stack and initiate a codebase without really knowing what I wanted to do.

Duh.

Realizing my mistake, I went back to square 1 and thought about the “really cool shit” my career had taught me.

MVP design

What do I want to prove?

My first step in thinking about the MVP for a new product, is to define what I want to prove.

In the case of Speakerine, that would be:

• That, given its URL, I can extract the content of an article

  • Textual content and ideally metadata such as cover picture, author, published date, …

• That I can turn this textual content into audio, with high enough quality that it's pleasant to listen to

  • While keeping costs as low as possible

• That I can build an app that does all that

• That people are interested in using this app

  • and actually paying for it!

This, I believe, is the minimum I should build to validate anything.

I've got other feature ideas of course, but I don't think they're as essential as what's listed above.

How do I prove it?

As I said in the previous issue, I don't have all the answers.
In terms of distribution and monetisation, it's still quite a big unknown to me.

For the rest, this MVP calls for an app of course, with enough components & interactions to provide the described minimal experience.

I've got two things to design: UI/UX design, and technical design.

I'm a firm believer that to build a good product, the UX must dictate how the product is built and not the other way around.1

So I drew a few things on my iPad and used Penpot—a serious Open Source Figma alternative—to make it shareable here:

The idea is quite simple:

• Log into the app

• Paste the URL of the article you want to listen to

• Wait as the service does its job

• Hit “Play” to listen to it

This very simple design gives me entry points into the main components of my app’s system:

• A “service” to receive a URL and:

  • extract metadata from it, shown as the article list item in the UI

  • start generating the audio for the article

• An “observable” task system to track the ongoing process

  • shown as the progress indicator close to the article item

  • allowing the app to be notified of the process completion

• Somewhere to store the audio data so that it can be played in the app

• A client-side audio player

Those building blocks should be enough to get me going and (in)validate many of the points I want to prove.

I think now, I can start RubyMine again and get to coding some of this stuff!

I have started working on Speakerine: an application to turn your reading list into a personalised podcast.

This is what its landing page looks like right now: speakerine.app

The concept

The idea is quite simple:

1. Through my days, I often stumble upon articles I want to read. Since I usually don’t have the time to read them right away, I keep the tab opened “for later”… but later never comes

2. On the other hand, I have multiple occasions when I could listen to some content instead of reading it.

   While commuting to work, exercising, cooking, doing the dishes or my laundry, while cleaning, … there are actually many opportunities to be listening to content while our hands are busy with routine tasks.

So I thought: why not create a Pocket-like app that allows me to easily transform any article into its audio transcription, and organise that into a playlist?

I kept this idea in my ideas list for a while, and since it kept creeping back to me as something I felt would be nice to do and valuable, I decided to build it!

I thought about many different features that could make it a daily companion for podcast aficionados, but I guess I’ll have to do it one step at a time :)

The name

Why Speakerine?

I wanted an original name which could be directly related to the text-to-speech nature of the project. I think Speak/Speaker in “Speakerine” works well for that, even though the word Speakerine itself might not be very well known internationally.

It’s actually the word “Speaker”, turned to a feminine form using the French suffix -ine. Speakerines were continuity announcers on the French television stations, appearing between programs, during unwanted interruptions or at the end of the day.

What I already know

• My target is a mobile app – it seems to me that would be the best way to make it a daily tool that can be used on the go.

• I’ll build the MVP as a web application though, as it’ll allow me to go faster to something I can put in your (and my ^^) hands!

  • With that objective in mind, I’ll start with Ruby on Rails as a framework to get things done quickly.

• I know what the main technical challenges are, and (mostly) how to solve them:

  • Challenge #1: given a URL, extract the meaningful content

    • This is what the “reader mode” of your browser does, and some of those readers are open source. I might have to customise the output of such tools to better prepare it for Speech-to-Text processing.

    • Content behind paywalls or login/password will be a specific challenge I’ll have to figure out.

  • Challenge #2: turn this content into a quality audio transcription

    • Whisper or similar models are the most obvious approach

    • Using a language detector will probably be useful as well, to inform the model of the language it should use

What needs figuring out

There are so many things I still need to figure out, but the two most impacting areas I believe are:

• Marketing & distribution:

  • I need to find where I can reach people who would be interested in the app, and how to target them

  • I also need to figure out SEO/ASO: what keywords will bring traffic to my app’s website or App Store listing?

• Pricing:

  • Can I do something else than subscription, like credits or pay-as-you-go?

  • I’m thinking it will highly depend on:

    • Speech-to-Text performance and what kind of server I’ll need to rent to make it work efficiently

    • How varied are transcribed articles in terms of length per article and per user

Next steps

The other day I’ve installed both Ruby on Rails and RubyMine on my computer, for the first time in like… 12 years 😱

I’m pretty excited to go back to RoR honestly, but after that I was like: “now what?”. And I figured I had not yet thought through what I wanted an initial prototype or MVP to look like.

So I closed RubyMine, got a pen and paper out, and jotted down some initial wireframes of the minimal web app to get things running.

This is what I’ll work on for Techtrails’ next issue!

My build in public journey starts with technical challenges on stuff I wouldn't want to have to deal with…
I'm probably going down a rabbit hole here, but I hope I’ll be out of it soon.

The thing is, I have already invested some money in both Carrd & Substack, and I'd like the setup to work. Because I invested in it, right?
Right.

Check out the concept of sunk costs or escalation of commitment if you want to understand the dilemma I'm in 😅

Anyway.

So, I've decided to use Carrd.co to quickly build the landing page for my projects, and Substack to power my newsletter.

The issue is: since Substack has no public API, there’s no way to register subscribers on Substack from Carrd forms.

SubstackAPI.com

While searching for a potential solution, I stumbled upon SubstackAPI.com.

I've tried using their solution, but it ended up not working after a short while and I'm not sure why. The author's account is not very active, so I'm going to assume their service is broken…

Which leaves me no choice but to figure it out myself.

All by myself

Substack does have an API to register new subscribers. It's just not public.
So I'm taking my chances trying to use it myself, and I'm guessing that's just what substackapi.com did initially.

How Substack does it

Using the “splash screen” subscription form for my publication allowed me to get the details of the API call they're making to their servers to add a new subscriber. Here it is as a cURL command:

The important part is of course the JSON data at the end of the command, but interestingly Substack will not process the subscriber when I remove too much of the headers.

With trial and error, I got the request stripped down to:

Surprisingly, the user-agent header is required for the email to be sent. I guess it's one of their heuristics to prevent server-to-server signups 🤔

The origin header is also definitely used to check where the request is coming from and reject unrecognized sources. Since browsers won't let you override this header in JavaScript fetch requests, it's a good filter for blocking rogue forms from external sources.
However it does mean that I'll have to send the request from a server for things to work.

Making the call

Using Carrd’s custom form handler

It's possible, using Carrd, to directly address a remote server with a custom JSON payload. What's nice is, they make the API call from their own servers.
So I wouldn't have anything to code or host if it works!

I have dropped the accept and content-type headers as I suppose they'll be added by Carrd:

It took me 2 minutes to set this up on my Carrd form. Will it work?

👉 Hit save
👉 Open landing page
👉 Enter email & click “get updates” …
🥁
🦗🦗🦗

The call seems to have been successful, but I do not receive any subscription confirmation email from Substack.

Let's investigate!

As Carrd is sending the request from their servers, I cannot debug the API call from my browser. Using Beeceptor, I setup a mock endpoint to send the requests to, and inspect what data and headers Carrd is sending.

Here are the headers:

Both the referer and origin headers have been removed from the request. Damn.
Why would they do that I don’t know, but I'll have to use another method.

Plan B: all by myself, again

Plan B is quite simple: receive the form data from Carrd on a custom endpoint, and forward the subscription to Substack.

Since my techtrails.io domain is hosted at Cloudflare, I'm going to use their Workers feature to get this done quickly. I had never used Cloudflare as a development platform, and I'm surprised at how easy it is to get something up live!

All it takes is:

npm create cloudflare@latest

Then follow the instructions, log into my Cloudflare account and voilà! I have a running worker online.

Here’s the meaty part of what I deployed:

Deploying the new code is just a npm run deploy away, and I’m able to test the endpoint using the automated Swagger UI 👍

Aaaaand… it does not work.

I mean, the code works all right, it's pretty simple.
But Substack still completely ignores the subscriber request, even though it does respond with an HTTP 200 and returns some JSON payload response.

Using Beeceptor again as the target for this fetch request, I can see that everything is all right from a headers point of view.

Next, I just launched the node REPL from my machine and pasted the above fetch request into it.

It works! 🤯
With the exact. same. code.

So now I'm wondering whether they could be identifying that I'm calling them from a Cloudflare worker.
Another test from a VPS server led to the same result.
Could they be checking the originating IP address for well-known hosting providers?

Hard to know for sure, but it looks like the server-to-server calls are getting too complicated.

Plan C: it's all about origin

Call me stubborn, but I’ve got another trick up my sleeve.

The one thing I’m sure they won’t be filtering out is requests coming from a browser and originating from techtrails.io.

I've got one way to pull this out: iframe.

Cloudflare is an amazing tool. I can use it to re-route some traffic for my techtrails.io domain to a Worker, while letting the rest through to Substack.

I'm going to host a small HTML page on Cloudflare with some JS code that will send the subscription API call to Substack, and embed this into an iframe on my Carrd landing page.

With some cross-frame communication, I can trigger the subscription API call from my Carrd site but with Techtrails as the effective origin, and all should work.

Let's get to it!

On the Cloudflare side

I'm deploying a new Worker that will route everything to Substack normally, except a specific /substack-subscribers route that will serve my special page:

One npm run deploy later, and my domain is now serving this special page at techtrails.io/substack-subscribers.

But what does it contain?
Mainly JavaScript:

Here’s what the code does in a nutshell:

• Lines 14-64: Set up a listener for the message event and handle two different messages:

  • substack-subscribers:ack — simply to let the host page (the Carrd site) acknowledge that our iframe script is ready.

  • substack-subscribers:subscribe — to receive, from the host page, the email address that should be sent to Substack.

• Line 67: Post the substack-subscribers:init message to the host page. This will allow the host page to know which window & origin pair it should send its own messages to.

It will also post either :subscribed or :error messages to bubble up the Substack API call result to Carrd.

On Carrd side

On my Carrd landing page, I’m adding an Embed component to inject the following code into my page:

This code publishes a global Techtrails.subscribeEmail function (lines 40-50) that will be used by the Carrd custom Form to trigger the API call to Substack via the iframe.

It also handles the following messages:

• Lines 14-22: substack-subscribers:init – to auto-discover the Techtrails iframe to which messages should be sent.

• Lines 25-35: substack-subscribers:subscribed and :error — to handle subscription success or error by invoking Carrd’s callbacks. Those callbacks will in turn trigger the Carrd Form success or failure handlers, for instance to redirect to a success page after form submission.

Another Embed component allows me to inject the iframe that will load my techtrails.io/substack-subscribers page, responsible for communicating with Substack:

<iframe src="https://techtrails.io/substack-subscribers"></iframe>

Finally, I’m using a custom Carrd form set to run code upon submission:

The code calls my subscribeEmail function defined earlier, passing in the email to be subscribed and the success and failure callbacks to notify Carrd of submission completion.

Ok now. Save & publish.

The final test

Looks like my last idea was the one :)

Shortly after submitting the form on my landing page, I received the following email:

🥳

Out of the rabbit hole

Et voilà.
It was quite a journey to make this work!

Thank you for reading the whole thing.

I honestly wouldn’t have liked to rethink my whole landing page + newsletter setup, especially since I do appreciate Substack as a platform but the landing page design is quite limited.

However, I can’t help but feel that being a software engineer can sometimes be a curse in disguise: coding is a superpower I’m often tempted to use instead of looking for simpler solutions.

It’s definitely something I’ll have to be careful about on my journey to build myself a portfolio of side projects.

What about you? How often do you overdo stuff because you know you can do it?

Do let me know how you liked this deep dive into bypassing Substack’s (quite advanced) filters!

I have been a Ruby on Rails fan for a very long time.

Unfortunately, my career track did not lead me to use it professionally, so it turns out I haven't touched Rails since its … 3rd version 🥲

Now that I am back to building personal projects, I've decided to pick up Rails again.

Meaning I have to install the entire stack from scratch, so here are the notes to achieve that1:

1. Install Ruby via rbenv

Looks like the landscape hasn't changed here and it's still RVM vs. rbenv!

I'm choosing rbenv for… reasons (mainly because it doesn’t mess with the environment/standard commands so much):

$ brew install rbenv 

Once installed, I can learn that the latest stable Ruby version is now 3.3.3:

$ rbenv install -l
3.1.6
3.2.4
3.3.3
jruby-9.4.7.0
mruby-3.3.0
picoruby-3.0.0
truffleruby-24.0.1
truffleruby+graalvm-24.0.1

Only latest stable releases for each Ruby implementation are shown.
Use `rbenv install --list-all' to show all local versions.

So let’s install it!

$ rbenv install 3.3.3

And make it the global Ruby version for my system:

$ rbenv global 3.3.3

For everything to work, don't forget to add the following to ~/.zshrc:

eval "$(rbenv init - zsh)"

2. Install Rails

As easy as it gets:

$ gem install rails

And voilà ! Ready to go 👍

I feel stuck.

Even after deciding I wanted to go down the road of building in public, I feel stuck.
Stuck with an inner fear of … well, I don't know really.

Once again not finishing what I started?
Not being interesting enough?
Building a useless app?
Failing?

Probably a mix of all that.

So to maintain the illusion that I'm doing something towards my goal, I convinced myself I needed some more setup to get started:

✅ Setting up my new substack for this very publication
✅ Building a landing page for my first project (more on that soon!) on Carrd.co
✅ Automating subscribers creation from my Carrd landing page to Substack
✅ Setting up Plausible analytics on both Carrd and Substack

The last two items were technically challenging so it took me a little while to get them done.

I'm particularly satisfied with how I managed to set up Plausible on Substack, as it's not an integration Substack does offer.
But since I really needed to procrastinate, I found a way :)

Here's the gist:

• Register your domain with Cloudflare

• Pay for Substack’s custom domain option to use that domain

• Create a Cloudlare Worker that injects Plausible’s script into the document’s head

Et voilà.
I could write up a detailed tutorial if there's some interest for it – let me know in the comments or hit reply!

Now back to being stuck.

You have probably noted that all 4 items above are checked. All done.
So in the next issue, I'll stop stalling and start talking about my first project: Speakerine.

Let's fail forward!

It took me a long time to dare.

I'm finally jumping in and starting my newsletter!
I will share later about the process I went through to finally hit the “publish” button.

Right now, I want to tell you what you can expect from me and this publication.

Building in public

I have been maintaining a list of project ideas for a very long time.
To date, there are 28 ideas in this list. Some are games, others tools, SaaS services or even goofy apps…

So far I have actually worked on none of those ideas. Zero. Nada.
That's got to change.

So I've decided to start building those projects, one by one, and to build them in public to make myself accountable.

Subscribe now

Sharing is caring

My objective: personal fulfilment and financial autonomy.
But to be honest, I have no idea where this will take me.

What I do know is that it took me a long time to dare, and that I will learn many things along the way. Through failures and successes alike.

Facing this uncertain road, I want to use this newsletter to:

• share the struggles and the successes, but most importantly the learnings they bring

• find some support in exchanging with people in similar situations or with similar endeavours

• maybe help some of you to dare, too!