In February, I started a YouTube channel in English, which is not my first language. This was something I had planned for 2024, but I delayed it.

In April, I turned 37 years old ⏳

In June, I attended the AWS Summit Madrid.

View this post on Instagram

A post shared by David Burgos (@daburix)

In August, Ghost launched native analytics. Then Ghostboard started to decrease its MRR.

This is the lowest point it reached:

I stopped working on YouTube and decided to fully focus on Ghostboard . I added several features like broken images detection, keyword mismatch, a Ghost members report, and unlimited traffic on all plans. I also contacted hundreds (almost a thousand) of Ghost blogs to invite them to try Ghostboard.

At the end of September, I started running one day per week. I also kept walking more than 1h twice per week, as I had been doing for more than a year.

In December, I was in Barcelona with the Worldreader Barcelona team 🙂

View this post on Instagram

A post shared by David Burgos (@daburix)

On the personal side, during the year (especially before summer and before the end of the year), I worked on adding insulation material to the attic roof. I think I did a good job, even though I had no idea what I was doing before starting.

This year, I only read one book: Black Box Thinking.

When I was a teenager, I thought that having a family, my own house, and a good job would make me happy. I can say I achieved that this year, but something else is missing and something else broke. This year was not easy.

I guess life is learning, growing and keep pushing. No matter what.

Happy New Year, and thanks for reading 🥂

Yes, you’re probably overspending — here’s how to fix it FAST.

📺 Prefer video? Watch the full tutorial on YouTube → https://youtu.be/2Hbt5tgC1WA

Amazon RDS (Relational Database Service) is powerful — but let’s be honest — it's also one of the easiest ways to silently burn your budget on AWS. 🔥

Whether you're running a side project, managing client databases, or building your personal brand's tech stack, these 5 Pro Tips (plus a couple of juicy bonuses!) will help you optimize your setup and save hundreds — even thousands — of dollars every year. 💸

Let’s dive right in. 👇

✅ 1. Audit All Regions — and Delete What You Don't Need

The #1 mistake? Forgetting what's running.
AWS charges for every active RDS instance — even the ones quietly humming in regions you forgot you ever used.

👉 What to do:

• Go to the AWS Console > RDS
• Check every region, not just your default one!
• Identify and delete old test environments, forgotten clones, and dev databases that are no longer needed.

💡 Bonus tip: Create a monthly reminder to audit regions. It takes 5 minutes and can save $$$.

⚖️ 2. Right-Size Your Instances

Are you using db.m5.large when you only need db.t3.micro?
Oversized instances are one of the main culprits of waste on RDS.

👉 What to do:

• Use Performance Insights and CloudWatch metrics to check CPU, memory, and connections.
• If you’re consistently under 30% usage, downgrade your instance size.
• Use burstable instances (T classes) for low-to-medium traffic apps — they’re often 5x cheaper than general-purpose ones.
• AMD cores are more efficient than Intel.
• ARM machines are even more efficient than AMD.

📉 Right-sizing = instant cost reduction.

💳 3. Use Reserved Instances (RIs) — If You’re In It for the Long Haul

If your project or business is stable, and you know your workload won’t change dramatically for a while…

👉 Reserve those instances!

• You can save up to 69% compared to on-demand pricing.
• Choose 1-year or 3-year terms, depending on your forecast.
• Available for all RDS engines (MySQL, PostgreSQL, Aurora, etc.)

💡 Combine with right-sizing for massive savings.

🧪 4. Evaluate Your Read Replicas

Read replicas are awesome for scaling reads — but they’re not free.
Many devs enable them for testing or temporary performance boosts... and then forget to turn them off. 😬

👉 What to do:

• Go to RDS > Databases and look for any replicas you’re not actively using.
• Remove unused replicas — they’re billed like any other instance.
• Consider Aurora Serverless or caching (Redis, ElastiCache) as an alternative for certain read-heavy workloads.

🔍 Audit replicas like any other resource — and kill what's not serving you.

📸 5. Clean Up Snapshots + Shorten Backup Retention

Automated backups are amazing. But guess what?
Old snapshots = paid storage.
The longer your retention period, the more AWS charges you.

👉 What to do:

• Delete manual snapshots you no longer need.
• Set automated retention to 7 days (or less, if you’re using other backup strategies).
• Go to RDS > Snapshots and filter for manual + old dates.

💡 You’re charged per GB per month — so old snapshots can add up FAST.

🧼 BONUS: Purge Old Data to Reduce Storage Costs

RDS storage costs scale with usage. If you're storing:

• Logs from 2018
• Debug data from old projects
• Archive tables no one touches...

It’s time for a cleanup. 🧹

👉 What to do:

• Use partitioning to make deletes safer.
• Archive old data to S3 Glacier (ultra-cheap storage).
• Purge junk that no longer serves business or compliance needs.

📦 Smaller DB = cheaper snapshots, faster backups, and better performance.

TL;DR — Here’s Your Quick Checklist ✅

1️⃣ Audit Regions: Delete unused RDS in all regions
2️⃣ Right-Size: Use monitoring to reduce instance sizes
3️⃣ Reserve: Buy Reserved Instances for long-term workloads
4️⃣ Review Replicas: Delete unused read replicas
5️⃣ Clean Snapshots: Remove old snapshots + shorten retention
🔁 Bonus: Purge unnecessary data to lower storage costs

📺 Watch the Full Video Guide

Want to see this in action step-by-step?

👉 Watch the full video here
Don’t forget to like 👍 and subscribe 🔔 to stay ahead of AWS tips and personal brand growth hacks.

✍️ Final Thoughts

You don’t have to be a DevOps pro to save money on RDS.
These small tweaks can have a big impact on your monthly AWS bill — without sacrificing performance or reliability.

💬 Got questions or want more content like this? Drop a comment or tweet me.

Let’s build smart. Let’s build lean. 🚀

AWS CloudFront is fast, reliable… and can get surprisingly expensive if you’re not careful. Whether you're running a small project, a SaaS, or a blog with global traffic, CloudFront pricing can spiral quickly without the right setup.

In this post, I’ll show you 5 practical tips you can apply today to optimize your CloudFront configuration and reduce your AWS bill — without sacrificing performance.

✅ Want the video version? Watch it on YouTube

1. 🌍 Use the Right Price Class

CloudFront lets you choose which edge locations to serve your content from, using Price Classes:

• Price Class 100: US, Canada, and Europe (cheapest)

• Price Class 200: Adds Asia and Africa

• Price Class All: Global (most expensive)

If your audience is mostly in the US or Europe, choose Price Class 100 to avoid paying for edge locations your users don’t need.

💡 Go to your CloudFront distribution → Settings → Edit → Price Class

2. ⏱️ Tune Your TTL (Time to Live)

TTL controls how long your content stays cached at edge locations. If it’s too short, CloudFront fetches from your origin too often — which costs you more.

Set sensible defaults:

• Minimum TTL: 1 hour

• Default TTL: 1–6 hours

• Max TTL: 24 hours (or more, for static assets)

This reduces origin requests and saves you bandwidth costs.

🔧 Tip: Review TTLs under Behaviors > Cache Policy

3. 🗜️ Enable Gzip and Brotli Compression

Serving smaller files = lower data transfer costs. CloudFront supports both gzip and brotli compression (brotli is newer and better for text-based assets like HTML, CSS, JS).

Make sure both are enabled in your cache policy:

• Brotli (for modern browsers)

• Gzip (for older browsers)

You’ll serve lighter files and users will love the faster loads too! 🚀

4. 🌐 Use Geographic Restrictions (Smartly)

If your content doesn’t need to be accessible worldwide, restrict access by country. For example:

• Block high-cost, low-value regions

• Allow only countries where your app or service is available

This saves money and reduces unwanted traffic or abuse (like scrapers).

🛑 Set up in: CloudFront > Restrictions > Geo Restrictions

5. 🧠 Review Behaviors for Extra Costs

Sometimes forgotten, the Behaviors section is where extra costs hide:

• 🚨 Check if you’re using Lambda@Edge or Function URLs

• These add flexibility — but also cost per execution

• Also check for signed URLs or headers that require extra processing

Make sure each behavior is actually necessary. If not, simplify!

🔍 Tip: Clean up unused paths or legacy configurations

✅ Bonus: Watch the Video Version

If you prefer watching, I’ve recorded a full walkthrough on YouTube with examples and screens:

🎥 Watch the video here

Final Thoughts

Saving money on AWS CloudFront isn’t about cutting corners — it’s about being strategic. These 5 pro tips help you serve your users faster and smarter, without wasting budget.

To recap:

1. Use the right Price Class
2. Optimize your TTL settings
3. Enable gzip and brotli
4. Set geo restrictions wisely
5. Audit your Behaviors for hidden costs

🔁 Over to you:

Have you tried any of these tips? Got a trick of your own to save on AWS? Let me know on Twitter/X or leave a comment below.

🧠 Follow for more tips on AWS, performance, and smart architecture!

If you’re using AWS ECR (Elastic Container Registry) and ECS (Elastic Container Service), you probably love the scalability and flexibility. But let’s be honest—AWS can get expensive if you’re not careful. 💰

Good news! You can save a lot of money with a few smart strategies.

In this post, I’ll show you 5 practical tips to reduce your AWS costs when using ECR and ECS.
(👉 Prefer video? Watch the full breakdown here: YouTube Video)

Let’s dive in!

1️⃣ Clean Up Old Images in ECR Regularly

Problem:
Storing too many unused Docker images in ECR can quietly increase your storage costs over time. 😬

Solution:
Set up lifecycle policies to automatically delete old, untagged, or unused images.

✅ Quick Tip:
Keep only the last few versions of each image. For example, store just the last 3-5 versions.

👉 Benefit:
You’ll save on storage and keep your ECR clean and fast!

2️⃣ Use Fargate Spot for ECS Tasks

Problem:
Standard Fargate tasks can be expensive, especially for workloads that can tolerate interruptions.

Solution:
Use Fargate Spot for non-critical or batch jobs. Fargate Spot can be up to 70% cheaper than regular Fargate! 🔥

✅ Quick Tip:
Ideal for background tasks, data processing, or temporary jobs that can handle being stopped and restarted.

👉 Benefit:
Massive cost savings with minimal changes to your architecture.

3️⃣ Use EC2 Spot, Saving Plans, or Reserved Instances (If You Use EC2 in ECS)

Problem:
Running ECS services on EC2 with only On-Demand instances is one of the fastest ways to overspend. 💸

Solution:
Use Spot instances for non-critical workloads, and combine them with Savings Plans or Reserved Instances for baseline capacity.

✅ Quick Tip:

• Spot: Up to 90% cheaper
• Savings Plan: Flexible and cost-effective for consistent usage
• Reserved Instances: Great for predictable, long-term workloads

👉 Benefit:
Optimizing EC2 pricing models can dramatically reduce your AWS bill.

4️⃣ Use Auto Scaling on ECS Services

Problem:
Running fixed-size ECS services can leave resources underutilized and waste money during low-traffic periods.

Solution:
Set up Auto Scaling for your ECS services to automatically adjust the number of running tasks based on CPU, memory, or custom metrics.

✅ Quick Tip:
Use CloudWatch alarms to scale up during peak times and scale down when demand drops.

👉 Benefit:
You only pay for what you need, exactly when you need it. 💡

5️⃣ Right-Size Your ECS Services

Problem:
Over-provisioned CPU and memory settings lead to paying for resources you don’t actually need.

Solution:
Monitor your services with CloudWatch and adjust CPU/memory reservations based on real usage.

✅ Quick Tip:
Start small, track performance, and scale up only if needed.

👉 Benefit:
You only pay for the resources you truly use. Simple, but super effective. 💪

🎥 Watch the Full Video

👉 See all the details step by step here: https://youtu.be/AtOXRT7q03M

🎱 Bonus: Leverage Graviton Processors (ARM Architecture)

Many teams use x86 instances by default, missing out on cheaper, more efficient options.

You can use AWS Graviton (ARM-based) instances for your ECS tasks.

Why? Graviton processors can cut costs by up to 40% and offer better performance-per-dollar.

Thanks for reading! 👋

If this post helped you, check out more articles on my blog and don’t forget to subscribe to my YouTube channel for more easy-to-apply AWS tips! 🚀

Today I want to share with you something that maybe can help your AWS bill go a little bit down 📉 — saving money on Route 53!

I use Route 53 a lot. It is a great DNS service from AWS — fast, reliable, global. But sometimes we use more than what we need, and that means more money 💰.

So here I give you 5 tips to pay less with Route 53. Simple and straight. Let’s go! 🚀

💡 This is a text version of one of my videos on Youtube

🧼 Delete Hosted Zones You Don’t Need

Each hosted zone in Route 53 costs $0.50 per month. Maybe it looks cheap, but if you have many zones that are not in use anymore… it adds up.

So first thing: clean your zones. Go to the console, check if there are old projects or test domains you don’t use. If yes, delete them! 👋

Less zones = less cost.

📦 Consolidate Hosted Zones

If you have similar domains or subdomains like:

• mywebsite.com
• api.mywebsite.com
• shop.mywebsite.com
• qa.mywebsite.com

You maybe don’t need separate hosted zones. You can put all in one and just manage with records.

More consolidation, less zones, less $$$.

⏱ Increase TTL (Time To Live)

Every DNS record has a TTL. It tells how long the record is cached. A small TTL (like 60 seconds) means more DNS queries = more cost.

So, if your record is not changing a lot, increase the TTL. Like 1 day or more. That way, less queries go to Route 53, and that saves money 💸.

🗑 Delete Records You Don’t Use

Like with zones, check your DNS records. Do you still need that old test.example.com? Or that old mail server from a service you don’t use?

If not — delete it. Keep it clean.

Also, when pointing to AWS resources (like S3, CloudFront, etc), use Alias records. Alias records don’t charge you for queries — they are free! ✅

👀 Review Health Checks and Routing Policies

Health checks in Route 53 are useful but not free. One health check costs between $0.50 and $2 per month.

If you don’t really need them, maybe your service has monitoring already — turn them off.

Same with routing policies: geolocation, latency-based, failover, and weighted routing, these are more expensive than simple routing.

So if you can use Simple Routing, go for it. It’s cheaper and maybe you don’t need the extra features.

Bonus Tip: 📊 Check Your Bill and Usage

Every month, take 5 minutes to check your AWS bill and Route 53 usage.

Go to the Billing Dashboard, and filter by service. See if there are any surprises or charges you didn’t expect. This helps a lot.

Also, look at Cost Explorer. Maybe you see a spike in DNS queries — and then you know where to optimize.

Thanks for reading! If you have other tips, I’d love to hear them 😄

Let’s save that AWS money together! 🤑

Hey there! 👋
In today’s post, I want to walk you through a step-by-step tutorial on how to apply a major version upgrade to an existing production database in AWS RDS — with zero downtime, no issues, and no fear. 😄

This is based on this real-time video tutorial I recorded, where I performed the upgrade live.

The Safer Upgrade Approach

Let’s say you need to upgrade your production PostgreSQL database (in my case, from version 15.x to 16.9). Here’s the approach I recommend:

1. Go to your latest RDS snapshot.
2. Restore it to create a temporary test database.
3. Upgrade the test database first and see what happens.
4. If everything looks good, apply the upgrade to production.

Why take this route? Simple:
Upgrading directly in production is risky. If something goes wrong — missing custom functions, upgrade errors, incompatible extensions — your app may go down, and restoring a backup takes time.

Even if you’re using Multi-AZ, like I do for ghostboard.io, it won’t save you from performance hits or upgrade failures. Multi-AZ helps with availability, not upgrade safety.

Step-by-Step Summary

Here’s exactly what I did:

1. Restored the latest snapshot into a new test database.
2. Chose a smaller but similar instance class (no need for Multi-AZ in test).
3. Waited a few minutes for it to spin up.
4. Applied the PostgreSQL 16.9 upgrade.
5. Waited about 12 minutes for the upgrade to complete.
6. Verified everything was working.
7. Deleted the test database.
8. Upgraded the production database using the same method.

That’s it.
Simple, repeatable, and much safer than doing it blind.

What If Something Goes Wrong?

If you do find issues (which I’ve only seen in rare cases), especially with projects using:

• Custom functions
• PostgreSQL plugins or extensions

Then even restoring a snapshot may not help.
In those edge cases, I had to:

• Create a new RDS instance with the target version
• Manually migrate data and functions via SQL scripts

But again — this is rare. For most cases, upgrading on a test snapshot is enough.

Don’t Forget the Version Calendar!

Always check the version lifecycle of your database engine:

• AWS RDS Supported Versions
• PostgreSQL Release Schedule

For example, PostgreSQL v16 is supported until February 2029, so plan your upgrades ahead of time.

Final Check: Production Upgrade ✅

After confirming the test upgrade worked, I did the same in production.
It took a few minutes, and everything went smoothly.

No downtime.
Website stayed up.
Dashboard worked.
Only a small bump in response time during the upgrade — totally acceptable.

Watch the Full Live Tutorial

If you want to see how I did it in real time, you can watch the video here:
🎥 Watch on YouTube

Thanks for reading! 🙌
I hope this helps someone, somewhere, somehow.
If you liked this post, feel free to share it, and subscribe to my channel for more tutorials like this.

See you in the next one — take care! 👋

Hey there! 👋
I’m David, and today I want to share my honest opinion about a book I read sometime ago: Hello, Startup by Yevgeniy Brikman.

This book often appears in lists of “must reads” for startup founders or people who want to join a startup.

But the question is: Is it really worth reading? And who is it for?

And if you prefer video, I also made a YouTube version of this review — feel free to check it out!

It’s a Great Book — for Beginners

Yes, the book is great. It’s very professional and well-organized.
But it’s mainly targeted at beginners.

If you are new to startups, this is actually one of the best books to start with. And I’ve read quite a few over the years!

What the Book Covers

The book is divided into 3 main sections:

• Product
• Technology
• Team

And it touches on many important topics:

• MVPs
• Product-market fit
• Marketing basics
• Choosing the right tech and frameworks
• Scalability and security
• Growth and hiring
• Company culture

It’s like a complete, general overview of what launching a startup is all about.

What’s Missing?

Even though the book is solid, there are a few things it doesn’t cover much:

• How to manage senior team members
• How to deal with stress, burnout, or failure
• More detailed strategies around marketing and sales
• And I think a section on founder psychology or mindset would be super useful too

So, Who Should Read This Book?

✅ If you are new to startups
✅ If you’ve never built a product before
✅ If you are a junior developer
✅ If you want to launch your first startup
✅ Or if you are planning to join a startup for the first time

In all of these cases, I’d say yes, Hello, Startup is definitely a great place to begin.

It gives you the big picture and helps you understand how everything fits together.

But…

❌ If you’ve already worked in tech for a few years
❌ If you’ve launched a couple of products

Then honestly, you might not learn much new.

Still, sometimes a book is helpful not because it teaches you something new, but because it confirms you’re already doing the right things. That’s valuable too.

Final Thoughts

Have you read Hello, Startup? What did you think of it? Did it help you in your startup journey?

Thanks for reading, see you next time! 👋

Hey there! 👋

Today I want to show you how I purchase a Reserved Instance for my database in AWS RDS. It helps me save money on my server costs for Ghostboard. I will walk you through the exact steps I follow.

💡 If you prefer video, you can watch my video tutorial version here: https://youtu.be/X8V_snV65bk

Step 1: Go to AWS RDS

• First, log in to your AWS account and go to RDS, the Relational Database Service.
• In the left menu, click on Reserved instances.
• Then click the orange Purchase Reserved DB Instance button.

Step 2: Choose Your Database Engine

• You need to select the database engine you’re using — like MySQL, PostgreSQL, or Aurora. In my case, I use RDS PostgreSQL for Ghostboard.

Step 3: Choose the Instance Type

• Here you select the class of instance, which is the size and type of the server.
• For me, I go with t4g.small, which is a burstable instance using an ARM CPU.

Step 4: Deployment Option

• Now choose your deployment option: Single-AZ or Multi-AZ.
• I use Multi-AZ for higher availability, so Ghostboard can stay online even if one zone has a problem.

Step 5: Reservation Term

• Decide how long you want the reservation for: 1 year or 3 years.
• I usually pick 1 year, and then review if I need a bigger or smaller instance at the end.

Step 6: Payment Option

You have 3 choices here:

• All Upfront – pay everything now, get the biggest discount.
• Partial Upfront – pay a part now, rest over time.
• No Upfront – pay monthly, but smaller discount.

I choose All Upfront, so I don’t pay monthly for the instance.
(Note: You still pay for storage and backups separately.)

⚠️ Important: Even if you delete your database later, you still pay for the full reserved period.

Step 7: Instance Count (Be Careful!)

• If you use Multi-AZ, you only need to select 1 reserved instance. This already includes the failover replica in another zone.
• People often make a mistake here and select more than needed.
• This setting is not about physical servers — it’s about how many databases you want to reserve.

Step 8: Add a Name (Optional)

• You can add a name or tag to identify this reservation.
  If you don’t, AWS will assign a default name (something like R-I-20250512...).
• Final Step: Confirm & Purchase
• You will see a summary with the total price.
• Double-check everything and click the orange Purchase button.

A few seconds later, your Reserved Instance will appear in the list.
You’ll see the name (or default name) and all the details when you click on it.

And that’s it! 🥳

I hope this was helpful.
Feel free to watch the video version here on YouTube to see it in action https://youtu.be/X8V_snV65bk

Thanks for reading, see you next time! 👋

Hey there! When you build an app, one of the most important decisions is choosing the right infrastructure. If you pick the wrong one, you might face problems with cost, maintenance, or performance later.

In this post, we will compare three popular options: AWS Lambda, containers (ECS/EKS), and servers (EC2). Let's dive in! 💡

AWS Lambda: Serverless Simplicity ⚡

Lambda is a serverless option, meaning you don’t have to manage servers. Just write your function, deploy it, and AWS takes care of everything. It automatically scales based on the workload.

✅ Pros:

• Cost-effective 💰 – You only pay for execution time, no idle costs.

• Fast to deploy ⚡ – Just write the code and push it live.

• No maintenance 🛠️ – No need to update servers, just your app dependencies.

• Auto-scaling 📈 – No need to configure load balancers.

❌ Cons:

• Execution time limit ⏳ – Max 15 minutes per function.

• Cold starts 🥶 – The first execution after scaling up can be slow.

• Best for: Event-driven apps, cron jobs, unpredictable workloads.

AWS ECS/EKS (Containers): Flexibility & Portability 🐳

Containers allow you to package your app and run it anywhere. AWS offers multiple ways to run containers, such as ECS, EKS (Kubernetes), and Beanstalk.

✅ Pros:

• Portability 🚀 – Move your app between different cloud providers.

• Faster deployments ⏩ – Compared to traditional app-managed services.

• Better performance 🔥 – Suitable for both low and high CPU-intensive apps.

• More configuration options 🛠️ – Choose exactly how your app runs.

❌ Cons:

• Requires a load balancer ⚖️ – Extra cost if scaling automatically.

• More expensive than Lambda 💵 – If the app runs infrequently.

• Best for: APIs, WebSockets, and apps needing low latency or more control.

Servers (EC2, VPS) 🖥️

Full control, more work. The traditional approach: rent a server, install your OS, and manage everything yourself. AWS EC2 and Lightsail offer this option.

✅ Pros:

• Best cost-performance ratio 💸 – If you optimize it well.

• Full control 🔧 – You configure everything.

• Custom OS/hardware support 🖥️ – If your app requires special configurations.

❌ Cons:

• Complex to manage 😓 – You install and update everything manually.

• Hard to scale 📉 – Load balancing and scaling require more work.

• Security responsibility 🛡️ – You must handle updates and security.

• Best for: CPU-intensive apps, AI/ML workloads, and custom configurations.

Quick Comparison Chart 📊

📸 Screenshot taken from my video https://youtu.be/OhKSNq4gl_A

Use Case Chart 📊

📸 Screenshot taken from my video https://youtu.be/OhKSNq4gl_A

Final Thoughts

If you want the simplest and most cost-effective option, Lambda is a great choice.

If you need flexibility and fast deployments, go with containers.

If you require full control and high performance, servers might be the best.

Let me know in the comments: Which one do you use? Or do you have any questions about choosing the right infrastructure? 🤔💬

If you found this helpful, share it with your friends and team! 🚀

Hey folks! 👋 Today, I want to share 7 common mistakes that many NodeJS developers make. I’ve been working with NodeJS since 2012, and trust me, I’ve made plenty of mistakes. 😅 But that’s how we learn! So, let’s go through these mistakes and how to avoid them.

This post is a written version of my Youtube video about this topic.

Misunderstanding Async/Await

Many developers use await on every line, not realizing that this makes each task run one after another. If the tasks don’t depend on each other, you should run them in parallel using Promise.all() or Promise.allSettled(). This way, you avoid unnecessary delays and improve performance.

Poor Error Handling

A lot of developers focus only on the “happy path” and forget that things can go wrong: network failures, database timeouts, or unexpected inputs. Always catch errors, log them, and handle them properly so your app doesn’t crash unexpectedly.

No Scalability Planning

When writing code, think ahead. What happens if 1 million users request the same endpoint at once? What if a database query returns a huge number of rows? Consider caching, load balancing, queues, and making your app stateless so it can scale horizontally.

Blocking the Event Loop

Node.js is single-threaded, so CPU-heavy tasks can block the event loop, making the app slow. If you need to process large files or perform heavy computations, use streams or move the task to a worker thread or queue system.

Poor Code Organization

Building an app is one thing, but maintaining and scaling it over time is another. Writing clean code and using a solid architecture is crucial. Otherwise, you’ll struggle in the future (like I did 😅). Invest time in organizing your code properly!

No Testing

You don’t need 100% test coverage, but at least cover the core functionality. Tests save you from breaking things when updating dependencies or adding new features. Some say, “We don’t have time for tests.” But in reality, skipping tests leads to more wasted time fixing unexpected issues.

Ignoring Security

Security is not optional! Always use authentication, encrypt sensitive data, hash passwords, enable firewalls, and never hardcode credentials. Use environment variables instead. A security checklist can help you stay on track and avoid common vulnerabilities.

These are just some of the mistakes I’ve seen (and made myself). Hopefully, this helps you avoid them!

🚀 Have you faced any of these issues? Let me know in the comments 😊

Hello developers! 👋 Today, let’s talk about something super important: clean code. No matter what programming language you use, clean code makes your life easier. In this post, I’ll explain what it is, why it matters, and some simple rules to follow. Let’s go! 🚀

By the way, this is a written version of my first video on Youtube 😊

What is Clean Code?

Clean code is easy to read and understand. When you or someone else checks the code, it should be clear what each part does. No guessing, no magic numbers, no confusion. Just clear logic! ✅

Why Should You Care?

• Maintenance 🛠️ – You, your team, or another developer will need to update the code later. Clean code makes it faster and easier.

• Productivity 📈 – When your code is clear, debugging and onboarding new developers is much easier.

• Quality 🏆 – Clean code usually means fewer bugs and lower development costs.

Common excuses

Sometime we can hear:

❌ “We need to move fast!” → But messy code slows you down in the long run.

❌ “We don’t have time!” → We are always in a hurry, but quality is more important than speed.

❌ “Perfection is impossible!” → True, but we can always improve! 💪

How to Write Clean Code

Here are some simple rules to follow:

• 📝 Use Descriptive Naming – Choose names that show the real purpose of the variable or function. Avoid abbreviations or vague names.

• 🔄 Be Consistent – Use the same terms across different parts of the code. If you call something getUserData in one place, don’t call it fetchUserInfo elsewhere.

• 📏 Short Functions & Files – Avoid long functions. Break them into smaller, meaningful parts to make the code easier to read.

• 💬 Replace Comments with Self-Explanatory Code – Instead of writing comments to explain what a function does, improve the function name and structure.

• 👀 Readability Over Performance – Don’t write “smart” but unreadable code. Clear code is better than a few milliseconds of performance gain.

Examples ✍️

Naming 🔑

if (age == 18 && car && car.ok()) {
 car.drive([40.4670213, -3.8013119]);
}

You may think:

• Why 18? Magic number 👎
• What does ok() mean?
• Which are these coordinates?

Better?

const isAdult = age === ADULT_AGE;
const hasCar = car && car.isOk();
const canDrive = isAdult && hasCar;
const {lat, lng} = office;
const destionation = [lat, lng];
if (canDrive) {
  car.driveTo(destination);
}

Consistency 🔑

function getEvents() { ... }
function fetchEvents() { ... }

You may think:

• What are the differences?
• Are these functions the same?

Better?

function getEvents(filters = {}) { ... }

Avoid long code 🔑

function downloadFile(params) {
 Logger.debug(`downloadFile() starting download file: ${url}`);
 if (!url || !url.startsWith(URL_PREFIX) {
   throw new Error(`downloadFile() Invalid url ${url}`);
 } else {
   return http.get(url, params, (response) => { 
      ... 
   }
 }
}

Better?

function downloadFile(params) {
 await validateFile(params);
 try {
   return await fetchFile(params);
 } catch (error) {
   return await retryFile(params, error);
 }
}

Self-explanatory code 🔑

if (null === value[field]
  || 0 === value[field]
  || '' === value[field]
  || typeof value[field] === 'undefined') {
    isComplete = true;  
}
return isComplete;

Better?

const isValid = !!value[field];
if (isValid) {
  isComplete = isValid;
}
return isComplete;

Shorter, clean code 🔑

const isIncluded = array.indexOf(item) !== -1;

const hasStreet = user && user.address && user.address.street;

array.map((item) => {
  return item.length;
});


for (const item of array) {
  if (item.property === 'key') {
    foundItem = item;
  }
}

Better?

const isIncluded = array.includes(item);

const hasStreet = user?.address?.street;

array.map(item => item.length);

const foundItem = array.find(item => item.property === 'key');

Takeaways 📌

• Write code for humans, not just machines.
• Keep it short but readable.
• Start today! Don't wait for perfection, small improvements make a difference.

Go further ✈️

Want to learn more? Check out these books:

• Clean Code by Robert C. Martin

• Refactoring by Martin Fowler

Also, explore open-source projects like Ghost, Next.js, or Babylon.js to see clean code in action.

Let me know your thoughts in the comments! What are your favorite clean code tips? 💬😊

Once again, it's time for my annual year-in-review. You can check out the previous 2023 Year Review.

This year, I only managed to read one book: Your Next 5 Moves, but I didn’t post it on social media 🙏

On the upside, I stayed consistent with my workouts throughout the year and feel in much better shape.

View this post on Instagram

A post shared by David Burgos (@daburix)

In March, I took a course focused on marketing, sales, and personal development, which was both insightful and inspiring.

Additionally, I had the chance to visit Barcelona a few times during the year and spend quality time with the wonderful Worldreader Barcelona team. I’m proud of everything we accomplished as a team this year 👏

View this post on Instagram

A post shared by David Burgos (@daburix)

In June, I enjoyed a relaxing getaway with my family at the beautiful Playacálida Hotel in Granada, Spain.

View this post on Instagram

A post shared by David Burgos (@daburix)

After that, an unexpected opportunity came my way: developing an AI-powered web app for a friend. It wasn’t something I had planned, but I took on the challenge and worked on it since then.

Toward the end of the year, big changes happened: we moved into a new home! After renting for several years, we are now homeowners with a mortgage. The last few weeks of the year were completely dedicated to packing, moving, and settling in.

Now that things are getting back on track, I'm excited to focus on the things that I had planned for the end of 2024. Stay tuned, and Happy New Year! 🥂

Here I go again with a year review, you can read the previous 2022 Year Review

During the 1st quarter, I took the AWS Cloud Solutions Architect Professional Certificate on Coursera and on 1st April, I passed the AWS Certified Solutions Architect Exam getting the official badge.

Ver esta publicación en Instagram

Una publicación compartida por David Burgos (@daburix)

At the end of May, my 4yo son Alex had severe peritonitis taking a 2 hours life-or-death surgery and then staying 1 week in the ICU. Tough times but with learnings. Fortunately, he fully recovered and he plays and draws like never before.

In September I was in Barcelona with the Worldreader team, we visited the Chocolate Museum and I had fun like every time I go there 🙂

Ver esta publicación en Instagram

Una publicación compartida por David Burgos (@daburix)

This year I have read only 1 book: Invicto (in Spanish)

Ver esta publicación en Instagram

Una publicación compartida por David Burgos (@daburix)

In parallel, this year I dedicated more time to listening to podcasts, most of them in Youtube, especially I like Tengo un plan (in Spanish) and the Alex Hormozi channel.

In the last quarter, I started lifting weights at home, going for a walk and running a few times per week, feeling better and with more energy. Also testing waking up earlier (6AM) but give me more time to make it work 😅

About Ghostboard 🎱

💡 You can read more about the updates related to Ghostboard in the 2023 year review in the Ghostboard blog

As you may know, I work on it on some weekends and nights. Unfortunately, this year the revenue was decreased -18.7%

A few things I can mention:

• I spent a few months at the beginning of the second half of the year migrating from MongoDb to Postgres and it impacted directly: no updates during this refactor and I introduced a couple of bugs (fixed in a few days).
• There were a couple of other causes that I'm aware of, that I already introduced changes. For example, a reminders for expiring cards 🥶

Anyway, since the last quarter of the year I've been taking action, planning and even changing my personal routines described above.

Let's see what I achieve in 2024 🏋️
Thanks for reading, Happy New Year 🥂

As every year I post the books I read in the last 12 months. This time, I have only completed 1 book, another 2 are started but pending completion and I dedicated more time to listening to some podcasts.

I want to keep this tradition of sharing the books that I read per year, so here I go

The book I read in 2023 📚

• 🇪🇸 Invicto by Marcos Vázquez (Spanish)

Ver esta publicación en Instagram

Shared by David Burgos (@daburix)

Happy New Year 🥂