Building Fast & Shipping Faster
Simplicity Over Complexity. In a world with millions of possibilities and technologies, many companies fall into the trap of overengineering their applications. Terms like “microservices,” “Kubernetes,” “serverless,” and a myriad of backend frameworks often dominate discussions among developers. But here’s the harsh reality: most of these technologies are solutions to problems that many products won’t even encounter - ever.
I’ve seen applications with just a thousand users running on infrastructures that would make even enterprise grade software engineers raise an eyebrow. These projects are built with complex architectures: distributed microservices, container orchestration through Kubernetes, intricate frontend frameworks, and a myriad of DevOps pipelines. All of this for an app that only a handful of users engage with daily. It’s like building a Formula 1 car when what you really need is a bicycle to test if people even want to ride. The worst part? These companies end up paying thousands of dollars just for maintenance and server costs. You end up spending more on servers, cloud services, and developer time, while a simpler solution could have validated your product-market fit much faster and at significantly lower costs.
The time spent configuring microservices could be better…
…spent listening to user feedback, iterating on features, and getting your product in front of more customers. It’s no secret that companies with simpler architectures can pivot faster, fix bugs quicker, and add new features without needing an army of engineers. By avoiding overengineering, you can deliver value directly to your customers without getting bogged down in a maze of dependencies and deployment issues.
Don’t get me wrong - these kinds of software architectures do make a lot of sense. But use Them Wisely
The core idea behind microservices is to break down a large application into smaller, independently deployable services that handle specific functionalities. Each service is self-contained, with its own codebase, and communicates with other services through lightweight APIs or messaging systems. This approach offers several advantages when dealing with the right types of challenges. For example, large enterprises with multiple engineering teams and complex software needs often benefit from microservices. They can leverage the advantages of microservices to create a more modular system. Another good use case is a company that is rapidly scaling to millions of users.
But please, don’t build for someday problems and make the uneconomical decision to build this way just because, one day, 15 years from now, you think it might be necessary. You’ll spend the remaining 14 years wondering why your developers seem inefficient or slow.
So, what should I do now?
It always depends on the business case of the product. We have built products with millions of users on a monolith running PHP on a very simple infrastructure. On the other hand, we have developed solutions where a microservice architecture made much more sense because of the many different clients (Web, Mobile, IoT), and their parallel evolution made development much easier and faster.
Make the Right Decision
Remember, you can always optimize later if you genuinely start hitting scaling problems. But you can’t make up for lost time if you spend months building a product that no one actually needs. In the early days, speed is your competitive advantage. Use it wisely by focusing on what really matters: shipping fast, gathering user feedback, and building a product that people love.
Ready to connect the dots?
Hi, I’m Emir, CEO and Co-Founder of Dotbite.
You have an interesting idea for a digital project and are looking for a sparring partner pushing the challenge through with you?
You’ve come to the right place.