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: Product/web analytics can capture events such as page views, feature usage, funnels, navigation patterns, device/browser information, and where users drop off. Good analytics starts with deciding which questions you need to answer—not collecting every possible piece of user data because you can.
Why do you need this: Without usage data, product decisions become guesswork. Analytics can show whether people reach important flows, use a feature, or abandon a process. Just remember that analytics also creates privacy/security responsibilities: minimize sensitive data, respect consent/legal requirements where applicable, and control who can access the events.
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 captures application errors/exceptions that reach its instrumentation and groups them with context such as stack traces, release/version data, device information, breadcrumbs, or request details. It can dramatically improve debugging, but it does not automatically observe every failure—coverage depends on where and how you instrument the app.
Why do you need this: Errors happen, and users often won’t file a useful bug report. Error tracking gives you a much better chance of noticing patterns and reproducing failures—but pair it with logs, metrics, traces, health checks, and user reports because no single telemetry tool sees everything.
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.
At that scale, availability matters a lot—but no realistic distributed system can promise it will literally never experience an outage.
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: Uptime/synthetic monitoring regularly checks a public endpoint, health check, or user journey from outside your application and alerts when availability or latency crosses a threshold. Deeper monitoring can also watch internal service/database health through metrics and observability systems.
Why you need it: Your app can become unavailable even when nobody is actively watching it. External checks reduce time-to-detection, but alerts should be tuned around meaningful symptoms/SLOs so you don’t wake someone up at 3 AM for one harmless packet hiccup.
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 helps against this class of problem: layered traffic controls and cost safeguards.
What is this: Rate limiting controls how frequently a client/account/IP/token can perform an action. DDoS mitigation is a broader edge/network defense that detects and absorbs or filters malicious distributed traffic before it overwhelms your origin. They can complement each other, but they are not interchangeable.
Why do you need this: App-level rate limits help prevent API abuse, runaway clients, brute force, scraping, and expensive repeated operations. Edge DDoS protection helps with attacks coming from many sources or pushing huge traffic volumes. Budget alerts, quotas, caching, authentication, and provider spending controls add another layer against surprise bills.
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: Automated tests exercise expected behavior without a human manually repeating every check. Unit, integration, contract, and end-to-end tests catch different classes of regressions.
Why do you need this: You will eventually break something when you ship new code. Tests can catch many regressions before deployment and give you confidence to change code—but tests are only as good as the cases they cover. Production monitoring still matters because no test suite proves the absence of bugs.
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 alone won’t make an app “production ready,” but it gives a side project three very useful feedback loops: what users do, what breaks, and who is abusing/overloading expensive endpoints.
As the project becomes more important, add availability monitoring, automated tests in CI, backups/recovery where data matters, logging/metrics/tracing, access controls, budget alerts, and deployment safety based on the actual risks of your system.
If you want to keep learning
Rate limiting explained — protect APIs from abuse, traffic spikes, and very expensive surprises.
Error handling explained — design failures so they’re easier to recover from and debug.
Mocks, stubs, fakes, and spies — make automated tests practical when your code depends on APIs, databases, and other services.
5 free system design resources — learn the architecture patterns that start mattering once real users show up.
What makes a good programming project in 2026? — turn these production features into proof that you can build more than tutorial clones.
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
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.
