Your Web Side Project Doesn't Need Enterprise Infrastructure

As software engineers, the technologies we use every day inevitably shape how we think software should be built. They certainly shaped mine. At work, I'm constantly thinking about scalability, reliability, and designing systems that can support thousands—or even millions—of users. Those are the kinds of problems enterprise software needs to solve.

But when I started building my own side project, I wasn't solving an enterprise problem anymore. My goal wasn't to support millions of users—it was to validate an idea, ship quickly, and keep costs low while I figured out whether anyone actually wanted to use it.

That shift in priorities reinforced something I'd long believed:

The right technology stack isn't universal. It depends on the stage of your project and the constraints you're working within.

Building my own side project gave me the opportunity to put that idea into practice in a very different context.

Here are some of the lessons I learned along the way.

Choose the Framework That Helps You Ship

One of the biggest decisions you'll make is choosing the technology you'll build with.

At work, I spend a lot of time with technologies commonly used in enterprise environments, like Java. My first instinct was to build my project using what I already knew best.

But then I stopped and asked myself what I was actually trying to accomplish.

My goal wasn't to build a system capable of serving thousands of concurrent users. It was to get an idea in front of users as quickly as possible.

That's why I chose Ruby on Rails.

Was I already proficient with it?

No.

But AI coding assistants made the learning curve much less intimidating. They helped me understand Rails conventions while applying concepts I already knew from years of software engineering.

Choosing a framework optimized for developer productivity helped me move much faster than optimizing for theoretical scalability.

Build Infrastructure for Today's Scale

The next lesson was realizing that my infrastructure should reflect the scale of my project—not the scale of the systems I build professionally.

Don't Pay for Idle Compute

Most side projects spend the majority of their time waiting for the next user.

That's what makes a serverless database such a great fit.

Instead of paying for compute that's running 24/7, I chose Neon. Since compute only runs when the database is actually being used, costs stay incredibly low while the application is idle.

I also liked knowing that even if my project eventually outgrew the free tier, I wasn't going to be hit with a huge jump in costs. The pricing remains incredibly affordable, making it easy to grow without constantly worrying about the next bill.

Deploy Without the Complexity

Once your application is working locally, the next challenge is getting it online so other people can actually use it.

For my side project, I wasn't looking for a hosting platform with every possible feature or endless configuration options. I wanted something affordable that would let me deploy a container, share the application with users, and get back to building features.

Given those constraints, Fly.io turned out to be a great fit for my side project.

One of the things I liked most was how easy it was to deploy a container and immediately have a publicly accessible HTTPS application. TLS certificates are managed automatically, so I didn't have to configure or maintain them myself.

Another benefit was that I didn't even need to buy a domain name to get started. Fly.io provides a public HTTPS URL out of the box, making it easy to deploy and share an application while you're still validating an idea.

Once I was ready for a more polished experience, I purchased an inexpensive domain through Namecheap and pointed it to my application. I also set up a professional email address with Zoho Mail. Neither cost much, but together they made the project feel much more established when communicating with users.

In the end, hosting became something I could set up once and largely forget about, leaving me free to focus on improving the product instead of managing infrastructure.

Keep Async Processing Simple

As your application grows, you'll eventually need work to happen outside the request-response cycle. That might be sending emails, generating reports, processing uploads, or running scheduled tasks.

My application only had one background task: sending payment reminders once a day.

My first instinct was to spin up a dedicated worker for asynchronous processing. It worked, but I quickly realized I had created another always-on service that continuously interacted with my serverless database. That meant I wasn't just paying for the worker itself—I was also causing my database to wake up more frequently, increasing my overall costs.

That's when I stopped and asked myself:

Do I really need another server for this?

In my case, the answer was no.

Since I only needed a scheduled job once a day, GitHub Actions turned out to be a surprisingly good fit.

Are scheduled workflows guaranteed to run at the exact minute you specify?

No.

But if a reminder goes out at 9:18 AM instead of exactly 9:00 AM, that's perfectly acceptable for my use case.

GitHub Actions happened to be the solution I chose, but many hosting providers also offer scheduled jobs or cron-like functionality that can accomplish the same thing without introducing another always-on service.

The lesson for me was simple: not every background task needs a dedicated worker. Sometimes a scheduler is all you need.

Invest Early in Visibility

Once other people start using your application, you'll eventually face a simple question:

How will you know when something breaks?

I didn't want to rely on users to report problems before I knew about them. Even though my project was small, I wanted the same level of visibility I value when working on enterprise systems.

That's why I chose Sentry.

What surprised me wasn't the tool itself—it was the scale.

In large production systems, it's not unusual to receive hundreds of error notifications in a single day. With my side project, I might only see a handful of errors in an entire month.

At that scale, Sentry's free tier was more than enough, and the visibility it provided was invaluable. The first time an unexpected error appeared, I knew about it immediately instead of hearing about it from a user.

Error monitoring was one of those enterprise practices that turned out to be surprisingly affordable at a small scale—and one I would absolutely adopt again from day one.

Spend Money Where It Solves a Real Problem

Building on a budget doesn't necessarily mean spending nothing. It means being intentional about what you pay for.

For me, AI coding assistants fell into that category.

If you're only working on your project a few hours each week, even an entry-level paid plan can save hours of debugging, boilerplate code, and research.

I'd rather spend a small amount on a tool that helps me move faster than let the limitations of a free plan slow me down.

Unlike infrastructure, your time doesn't have a generous free tier.

Final Thoughts

Looking back, every decision came down to asking the same question:

What problem am I actually solving today?

That simple question shaped every technical decision I made:

• Choose the framework that helps you ship.
• Build infrastructure for today's scale.
• Don't pay for idle compute.
• Deploy without the complexity.
• Keep async processing simple.
• Invest early in visibility.
• Spend money where it solves a real problem.

None of these lessons are tied to a specific technology. They're about matching your engineering decisions to the problem you're actually trying to solve.

Working on enterprise systems can easily shape how we think software should be built. But side projects play by different rules. The goal is to build something useful, learn from real users, and evolve the system as it grows.

In addition, The right technology stack isn't universal. It depends on the stage of your project and the constraints you're working within. If your project eventually needs enterprise infrastructure, that's a wonderful problem to have.It means you've built something people actually want to use.

I'm curious to hear from others who have built side projects.

What lessons have you learned about choosing technologies under different constraints? Is there a tool, service, or engineering decision that worked particularly well for you?