DEV Community: Sajjad

AWS Was Supposed to Simplify DevOps. So Why Is Everyone Looking for Alternatives?

Sajjad — Mon, 26 Oct 2026 14:37:46 +0000

How the cloud revolutionized software development, became unnecessarily complicated, and why developers are looking for simpler solutions.

The golden age of AWS

There was a time when AWS was the obvious choice.

Launching a startup? AWS. Building a scalable backend? AWS. Running enterprise infrastructure? AWS.

When Amazon launched S3 and EC2 in 2006, it fundamentally changed software development. Companies no longer needed to purchase physical servers or build data centers before launching products. Developers could rent computing power on demand and scale as their businesses grew.

AWS made infrastructure accessible to everyone. It was a revolution.

But over time, something changed.

When simplicity became a nightmare

AWS kept expanding. Every problem seemed to get another service, another configuration option, and another layer of abstraction.

Need to deploy an application? Choose between EC2, ECS, EKS, Fargate, App Runner, and Lambda.

Need a database? There are multiple options, each with different capabilities and trade-offs.

Need networking, permissions, monitoring, and security? Prepare to learn IAM policies, VPCs, subnets, security groups, load balancers, CloudWatch, and more.

These services aren't identical, but their capabilities sometimes overlap, making the right choice surprisingly difficult.

And here's the irony: the cloud was supposed to make infrastructure easier, yet developers can spend days configuring infrastructure before delivering a single product feature.

For large enterprises with dedicated DevOps teams, this flexibility can be valuable. For a solo developer building a small SaaS, it can be complete overkill.

Sometimes all you need is a server, PostgreSQL, Docker, backups, and automated deployments.

Why should that require an infrastructure engineering project?

Developers are pushing back

This frustration isn't merely theoretical.

In public developer discussions on Hacker News, engineers have described startups spending disproportionate effort managing complicated AWS architectures instead of building their products. Others have complained about IAM configuration, forgotten resources, and the difficulty of extracting useful information from CloudWatch.

Meanwhile, 37signals, the company behind Basecamp and HEY, completed a migration of its remaining legacy applications away from cloud infrastructure in 2023.

Its founder, David Heinemeier Hansson, announced the move with the words:

«"We're out."»

The company cited potential cost savings and performance benefits from running those workloads on its own hardware.

Of course, one company's experience doesn't prove that everyone should leave AWS. But it demonstrates an important point: using a hyperscaler isn't the only legitimate way to run production software.

The rise of cloud-agnostic DevOps

The alternative isn't necessarily replacing AWS with Google Cloud and repeating the same architecture.

It's choosing technologies that preserve flexibility and avoiding unnecessary dependence on any single provider.

Consider a practical stack:

Docker for packaging applications.
PostgreSQL for relational data.
GitHub Actions for CI/CD.
Terraform or OpenTofu for infrastructure automation when needed.
Standard APIs and portable application configurations.

A Dockerized NestJS application can run on multiple hosting platforms without rewriting its business logic.

That's the idea behind cloud-agnostic engineering: choose infrastructure based on actual requirements, not brand loyalty.

But don't turn portability into another over-engineered project. You don't need Kubernetes or elaborate abstraction layers for every application.

Alternatives worth considering

If you're looking for simpler infrastructure, several options are worth exploring.

DigitalOcean offers a straightforward cloud experience with virtual machines, managed databases, and application hosting. It's a practical choice for conventional web applications and APIs.

Hetzner provides affordable servers, making it attractive for developers who want to run Docker containers and manage their own infrastructure without the cost and complexity of a large cloud ecosystem.

Render simplifies deploying applications, background workers, and databases. It's useful when you want to focus on your code instead of configuring infrastructure.

Railway provides a developer-friendly way to deploy APIs, databases, and background services, particularly for prototypes and early-stage SaaS products.

Google Cloud remains a powerful option for applications that need managed infrastructure, Kubernetes, analytics, and enterprise-scale capabilities. However, switching to another hyperscaler won't automatically solve infrastructure complexity.

The right choice depends on your needs. VPS providers offer more control but require more maintenance. Managed platforms reduce operational work but may introduce platform-specific limitations.

You don't need the biggest platform. You need the right one.

Is AWS actually ending?

No. AWS remains a major cloud platform, and many businesses benefit enormously from its ecosystem.

What's changing is the assumption that AWS must be the default choice for every project.

Developers increasingly have alternatives that let them deploy software without assembling and managing a huge collection of infrastructure services.

A small SaaS doesn't need the same architecture as a global financial platform. A startup doesn't automatically need Kubernetes. And a complicated architecture isn't necessarily a better one.

The future of DevOps isn't about using more infrastructure. It's about delivering reliable software with less unnecessary complexity.

AWS helped create the cloud revolution. But developers don't owe any platform their loyalty.

Choose the simplest architecture that meets your requirements, keep your options open where it makes sense, and spend more time building products than managing infrastructure.

What about you? Are you sticking with AWS, moving to another provider, or choosing simpler infrastructure from the beginning?

I Built a Neomorphic UI Library for Next.js Because Interfaces Deserve More Personality

Sajjad — Sun, 25 Oct 2026 22:27:07 +0000

Most modern interfaces are built from familiar pieces.

Buttons, cards, inputs, dropdowns, dialogs. We have excellent libraries for all of them. Yet when you browse enough products, you start noticing something: many interfaces feel remarkably similar.

I wanted to explore a different visual direction.

That's why I built "baloot-neomorphic-ui" (https://github.com/sajjadcodes/baloot-neomorphic-ui), a reusable neomorphic UI component library for Next.js App Router and Tailwind CSS v4.

The idea was simple: take the soft depth of neomorphism and turn it into a practical component system developers can use in real applications.

Why neomorphism?

Neomorphism, sometimes called Soft UI, creates depth through subtle highlights and shadows. Instead of relying on strong borders or dramatic contrast, components appear to rise from or press into their surrounding surfaces.

Done well, the result feels calm, tactile, and distinctive.

But a visual concept is only the beginning. A design that looks beautiful in a mockup still needs to work as an actual interface.

Buttons need clear states. Forms need useful validation. Components need to behave consistently. And the design needs to work in both light and dark themes.

A design system should make consistency easier, not turn every new component into another styling problem.

From visual idea to reusable components

I built the library around that principle.

Rather than recreating the same styles and behaviors across projects, the library provides reusable components with a shared visual language.

It includes:

Form controls: inputs, textareas, selects, checkboxes, radio groups, switches, and sliders.
Navigation and layout: cards, tabs, breadcrumbs, sidebars, pagination, and tables.
Feedback components: alerts, snackbars, dialogs, progress indicators, and skeletons.

The library also includes theme tokens, allowing developers to customize the visual system instead of treating every component as an isolated design.

It is built for Next.js App Router projects using Tailwind CSS v4, with TypeScript support.

Design is more than shadows

Neomorphism has a weakness: subtle visual depth can become a usability problem when it makes interactive elements difficult to distinguish.

That trade-off matters.

A component library cannot focus exclusively on appearance. It also needs to consider accessible markup, keyboard interactions, visible focus feedback, disabled states, and reduced-motion preferences where relevant.

The goal isn't to make every element look beautiful at the expense of usability. It's to make the visual identity and the interaction design work together.

That's the difference between a collection of styled components and a library intended for real applications.

Try it in your next project

You can install the package with npm:

npm install baloot-neomorphic-ui

Explore the source code, installation instructions, component examples, and theme customization options in the repository:

GitHub: https://github.com/sajjadcodes/baloot-neomorphic-ui

npm: https://www.npmjs.com/package/baloot-neomorphic-ui

The library is an evolving project, and I'm interested in making it more useful as it grows.

One question for frontend developers

We have no shortage of component libraries. What we need isn't necessarily another library with more components.

Sometimes, we need a different design perspective.

When choosing a UI library, what matters most to you: visual identity, accessibility, customization, developer experience, or the speed of building an interface?

I'd be interested to hear what other developers prioritize — and what you think neomorphism gets right or wrong.

The Developers Who Thrive in the AI Era Won't Necessarily Be the Ones Who Code the Fastest

Sajjad — Tue, 20 Oct 2026 16:11:52 +0000

There was a time when being a good developer often meant being the person who could solve a problem in code faster than everyone else.

You knew the language, understood the framework, remembered the syntax, and could turn a requirement into a working feature. Those skills still matter. But something is changing.

AI can now generate code, explain unfamiliar libraries, suggest implementations, and help developers move through tasks that once took hours. The tools are improving, and pretending otherwise won't help anyone.

The question is no longer just how fast you can write code. It's what you can do with the time AI gives you back.

Writing code was never the whole job

Consider two developers.

One can generate a working implementation in minutes but struggles to recognize a flawed design. The other takes longer to understand the problem, questions the requirements, evaluates the trade-offs, and builds a solution that can survive real-world use.

Which one would you trust with a critical system?

Generating code is not the same as engineering software. Production systems need more than implementations that work in a demonstration. They need security, reliability, maintainability, observability, and decisions that make sense in context.

AI can help with these things, too. But someone still needs to evaluate the results and take responsibility for the system.

When producing code becomes easier, engineering judgment becomes harder to ignore.

The value of knowing what to build

One of the most underrated skills in software engineering is identifying the right problem.

It's possible to spend weeks building something technically impressive that solves a problem nobody has. It's also possible to solve a meaningful problem with a relatively simple implementation.

AI makes it easier to explore possible solutions. That is useful, but it doesn't automatically tell us which problem deserves our attention.

Understanding users, recognizing constraints, choosing trade-offs, and deciding what not to build remain essential.

The developer who asks better questions may produce more value than the developer who generates more code.

The danger of becoming dependent

There is another side to this transformation.

If we accept every AI suggestion without understanding it, we risk becoming operators of tools rather than engineers capable of making independent decisions.

A generated implementation might look convincing while containing a subtle security flaw, an unnecessary abstraction, or a concurrency bug that only appears under production load.

The danger isn't using AI. The danger is losing the ability to evaluate what it produces.

Use AI to accelerate your thinking, not to replace it.

Ask it to challenge your architecture. Compare alternative designs. Investigate edge cases. Review its assumptions. And when something fails, make sure you understand why.

The goal should be to become a stronger engineer with AI, not a less capable engineer without it.

What should developers focus on now?

I don't think the answer is to abandon programming fundamentals or chase every new AI tool.

Instead, developers should deepen the skills that help them make better decisions:

System design: Understand how components interact and where failures occur.
Problem-solving: Separate the actual problem from the first proposed solution.
Critical thinking: Verify generated code instead of trusting confident explanations.
Communication: Understand requirements, explain trade-offs, and work effectively with people.
Ownership: Take responsibility for what reaches production, regardless of who or what wrote the code.

These skills aren't new. What is changing is how valuable they become when implementation gets cheaper and faster.

The real competition is changing

I don't believe AI will make every developer obsolete. I also don't believe that simply knowing how to use an AI coding assistant will guarantee a successful career.

The more realistic possibility is that the expectations of software engineering will change. Some tasks will become easier, some roles will evolve, and some developers will need to rethink how they create value.

The developers who adapt won't necessarily be the ones who type the fastest or use the most tools. They'll be the ones who combine technical ability with sound judgment, curiosity, and a willingness to keep learning.

The future belongs neither to developers who reject AI nor to those who blindly depend on it. It belongs to developers who know how to use it without giving up the ability to think for themselves.

And that raises a question worth discussing.

If AI can already write a significant amount of our code, what do you believe will distinguish an excellent software engineer from an average one five years from now?

5 Mistakes That Make Background Jobs Unreliable

Sajjad — Mon, 19 Oct 2026 15:48:33 +0000

Background jobs are easy to underestimate.

You enqueue a task, a worker picks it up, and the work gets done. At least, that's how it looks when everything works.

In production, jobs can fail halfway through, run more than once, get stuck, or overwhelm a dependency. The problem isn't just that a job fails. It's what happens next.

Here are five mistakes that can make background processing unreliable — and how to avoid them.

1. Retrying Without Backoff

Retries are necessary, but retrying immediately after every failure can make an outage worse.

Imagine a worker calling a payment provider that's temporarily unavailable. If hundreds of jobs retry continuously, they add even more pressure to an already struggling service.

Use exponential backoff with jitter. Increase the delay between attempts and add randomness to prevent many jobs from retrying simultaneously.

Retries should help a system recover, not amplify its failures.

2. Assuming Every Job Runs Only Once

A worker might complete an operation but crash before acknowledging the message. The queue can then deliver that message again.

This is normal behavior in many distributed systems, not an exceptional edge case.

Design jobs to be idempotent whenever possible. Processing the same job twice should not create duplicate payments, send repeated notifications unnecessarily, or corrupt data.

For critical operations, use stable operation identifiers and database constraints or deduplication records where appropriate.

3. Ignoring Failed and Stuck Jobs

A job can fail repeatedly without anyone noticing. Another might remain in progress because a worker crashed or a dependency never responded.

A queue can appear healthy while important business operations are silently falling behind.

Track job failures, queue depth, processing time, and the age of the oldest pending job. Define alerts for conditions that actually affect users or business operations.

A reliable system doesn't just process jobs. It makes failures visible.

4. Processing Jobs Without Clear Failure Boundaries

Some jobs perform several operations: update a database, call an external API, and publish an event.

If the third step fails, the first two might already have succeeded. Retrying the entire job blindly can repeat side effects.

Break work into clear, recoverable steps. Use transactions for operations within a single database where appropriate, and use idempotency, durable state, or compensating actions when coordinating external systems.

Don't assume that one failed step means everything else was rolled back.

5. Having No Recovery Strategy

Eventually, some jobs will exhaust their retries. If they simply disappear from the normal workflow, you can lose important work or spend hours investigating what happened.

A dead-letter queue can isolate jobs that cannot be processed successfully, but it isn't a complete recovery strategy by itself.

Decide what happens after the final retry. Preserve enough context to investigate the failure, provide a safe way to replay eligible jobs, and prevent replaying a job from repeating irreversible side effects.

Recovery should be designed before the first production incident, not during one.

Reliability Is About What Happens After Failure

Background jobs don't become reliable simply because a queue and a worker are running.

They become reliable when duplicate delivery is expected, failures are observable, retries are controlled, and unfinished work can be recovered safely.

The goal isn't to prevent every failure. It's to make failures predictable, contained, and recoverable.

That's the difference between a background worker that usually works and a background processing system you can trust.

I'm Building Balootix: My Journey Toward Building Real-World Software

Sajjad — Wed, 14 Oct 2026 16:23:13 +0000

Launching a website is an exciting milestone, but for me, it's only the beginning.

I've officially launched the Balootix website, and I'm excited to share more about what I'm building, the engineering challenges I encounter, and the lessons I learn along the way.

My goal is to build real-world software products and share the engineering decisions behind them.

Here's what I'm working on.

🚀 Balootix

Balootix is the brand behind the software products I'm building.

Rather than treating a website launch as the finish line, I see it as the starting point for a much bigger journey: developing useful software, solving real engineering problems, and sharing what I learn with the developer community.

🏗️ Baloot Org: My Current Project

Baloot Org is a multi-tenant SaaS project focused on organizational management.

The idea is to provide a structured way to manage organizations, departments, organizational units, and roles.

I've developed the backend and made the project publicly available on GitHub. The frontend is still in development, so Baloot Org isn't yet a finished, publicly available application.

Working on this project has given me an opportunity to explore several important software engineering concepts:

Database design: Modeling organizational structures and relationships.
Backend architecture: Designing APIs and organizing application logic.
Multi-tenancy: Building an application designed to serve multiple organizations.
Hierarchical data: Working with organizational units and their relationships.
Maintainability: Making design decisions that allow a project to evolve as it grows.

I'm particularly interested in the engineering decisions behind these systems: how to model the data, how to retrieve organizational hierarchies efficiently, and how to build a backend that remains maintainable as the application grows.

You can explore the project here:

🔗 https://github.com/sajjadcodes/baloot-org

🔮 What's Next?

Baloot Org is my current focus, but I have other ideas for the Balootix ecosystem.

Two projects I'd like to explore next are:

Baloot Pay

A planned payment-service project focused on payment infrastructure and the engineering challenges involved in building reliable payment systems.

Baloot Signal

A planned messaging infrastructure project built around event-driven architecture, with a focus on how systems communicate and process events.

Both are future projects. I'll share more about them as development progresses.

💡 Why I'm Sharing My Journey

I believe one of the best ways to demonstrate software engineering skills is to build real things and explain the thinking behind them.

That's what I want to do here on DEV.to.

I plan to share practical articles about backend development, databases, system architecture, and the challenges I encounter while building my projects.

Rather than focusing only on theory, I want to explore how technologies work in real applications, why particular approaches make sense, and what I learn from implementing them.

Hopefully, these articles will be useful to other developers who are building their own applications and exploring similar engineering challenges.

🤝 Let's Connect

If you're interested in backend engineering, SaaS architecture, databases, or event-driven systems, I'd love to connect and exchange ideas.

You can learn more about Balootix here:

🌐 https://balootix.com

This is just the beginning. More projects, more engineering challenges, and more lessons to share.

Thanks for reading!