- Sloth Bytes
- Posts
- 🦥 5 Things Tutorials Never Teach
🦥 5 Things Tutorials Never Teach
The Coding Sloth
January 07, 2026 • Estimated Reading Time: 11 minutes
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had an amazing week.
Sorry for the lack of emails! Finally finished moving, and I’m back in work mode.
Let’s start this year strong 😁
But if you want to reach 50,000+ developers, founders, and tech lovers who actually open their emails — this is the place.
5 Features That Tutorials Never Teach You
I’ve noticed something very very interesting.
A lot of tutorials teach you how to build an app, deploy it, and call it a day.
But what do you do after?
Because the second actual humans touch your app, everything changes.
How do you know when something small breaks?
How do you know when a new feature is actually being used?
How do you get more users?
Why is my bill $10,000 and why do I have to sell my liver on the black market to pay it?
When this happens, you start to realize:
Wtf building the app was the easy part. How do I keep this project alive?
Answering that question is what separates "I made a thing" and "I run a thing."
Here are 5 features that no one teaches you, but everyone who's shipped something real uses all the time.
I also tried combining this with stories, let me know if you prefer this or prefer straight information.
1. Analytics
Imagine you're running a restaurant ordering platform processing millions of orders every day for hundreds of restaurant brands.
Your customers keep asking questions:
"Why are people abandoning checkout?"
"Is that new feature actually being used?"
"Can you tell me what are the best practices?"
The problem? You don’t have data to answer their questions.
That's exactly where Olo was. They couldn't tell their customers what was working and couldn't prove which features mattered, but once they added user analytics, they now had the data they needed.
What is this: Analytics could be page views, where people click, navigation patterns, where people leave, type of browser, type of OS, etc.
Why do you need this: You're basically building blind without it. Analytics will tell you if anyone's actually using your app or using that new feature you spent weeks on. You need data to make informed decisions about what to build next, what's broken, and what's working.
Where to start:
2. Error Tracking
Disney+ runs on dozens of platforms: mobile, smart TVs, gaming consoles, streaming devices. They serve tens of millions of subscribers across the globe.
When something breaks at that scale? You need to know immediately.
An error on one device, one region, one specific combination of OS version and hardware could affect thousands of users before anyone reports it.
And most users won't report it. They'll just cancel their subscription.
Disney understands this, which is why they have error tracking.
What is it: Error tracking automatically catches every exception your app throws. Crashes, failed API calls, unexpected states, etc. It gives you the full stack trace, the user's path leading up to the error, and the context you need to actually fix it. Much more information than generic error handling.
Why do you need this: Errors happen. Always. Your app will throw exceptions you never thought possible. Without error tracking, you're relying on users to tell you something broke and most users will never tell you. They’ll just ask for a refund.
Where to start:
3. Uptime Monitoring
Ryanair has an ambitious goal: fly 300 million passengers annually by 2034. Double their current capacity in a decade.
That means their systems can't go down. Ever.
Imagine if their server stops responding at 3 AM and passengers couldn’t check their flights, bring up their boarding pass, check in, etc.
At Ryanair's scale, every minute of downtime could mean grounded flights, customer service gets flooded. refunds, long lines, etc.
What is this: A service that pings your app every few minutes and screams at you the second something breaks. Server down? You know. Database connection failed? You
Why you need it: Your app will go down. It's not if, it's when. Would you rather find out from a monitoring alert at 3 AM, or from angry users in the morning after the damage is done?
4. Rate Limiting & DDoS Protection
A developer had a simple static site on Netlify.
The site ran fine for 4 years and averaged 200 daily visitors, but one weekend in February 2024, he got an email.
Bill: $104,500.
His site got hit with a DDoS attack.
60.7 terabytes of bandwidth in a single day.
Unfortunately at the time, Netlify didn’t offer automatic DDoS protection (they do now…) so he was charged $55 per 100GB for bandwidth.
At first, support offered to "only" charge him $5,225 (5% of the bill), but after the story went viral on Reddit and Hacker News, the CEO waived it entirely.
Here's what could've stopped it: DDoS protection and rate limiting.
What is this: Systems that limit how many requests a user/IP can make in a given time period, preventing abuse and attacks.
Why do you need this: Without rate limiting, someone (or a bot) can spam your API with thousands of requests per second and your server crashes or you wake up to a $100,000 bill.
Where to start:
5. Automated Testing
Stripe processes hundreds of billions of dollars in payments every year for millions of businesses worldwide.
One broken line of code could cause millions of dollars in damage in just a few hours.
In 2023 Stripe revealed that they run over 1.4 million automated tests on every single code change. Not 1,000. or even 100,000, but 1.4 million tests.
Their system uses half a million CPU cores to execute over 6 billion test runs per day. From simple style checks to unit tests to full end-to-end integration tests that even check if code works correctly during leap seconds.
What is this: Code that automatically tests your app's critical features to catch bugs before users do.
Why do you need this: You will eventually break something when you ship new code. Maybe you'll break login. Maybe checkout. Maybe something you haven't touched in months mysteriously stops working. Tests catch this before you deploy, not after users complain.
Where to start:
E2E/Browser Testing (language agnostic):
Unit/Integration Testing:
JavaScript: Jest, Vitest, Mocha
Python: pytest, unittest
Ruby: RSpec, Minitest
Java: JUnit, TestNG
Go: testing package (built-in)
PHP: PHPUnit
Rust: cargo test (built-in)
C#/.NET: xUnit, NUnit
My suggestions
If you wanted the most value in the least amount of time, I suggest you add these:
Analytics
Error tracking
Rate limiting
That's it. Your app is now 10x more legitimate than 90% of side projects out there.
The rest you can add as you grow.
Thanks to everyone who submitted (3 weeks ago uh….)
kaushalsingh01, mkgp-dev, grcc492, giacomib, Abbey086, adnmzlz, and AspenTheRoyal!
Remove the Last Vowel
Write a function that removes the last vowel in each word in a sentence.
Examples
removeLastVowel("Those who dare to fail miserably can achieve greatly.")
output = "Thos wh dar t fal miserbly cn achiev gretly."
removeLastVowel("Love is a serious mental disease.")
output = "Lov s serios mentl diseas"
removeLastVowel("Get busy living or get busy dying.")
output = "Gt bsy livng r gt bsy dyng"
removeLastVowel("If you want to live a happy life, tie it to a goal, not to people.")
output = "f yo wnt t liv hppy lif, ti t t gol, nt t peopl."Notes
Vowels are: a, e, i, o, u (both upper and lowercase).
How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
Working with an artist for our sloth mascot!
Been thinking about how to add more custom visuals specifically MORE SLOTHS.
I’m a terrible artist, so I hired 2 artists to give 2 versions of the sloth:
Version 1
Looks good right?
Version 2
Which Sloth design do you like more? |
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email? |
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
Reply