You open a modern SaaS dashboard to do one simple thing. You click a button. A spinner appears. You wait. Three seconds later, the UI updates. It feels sluggish, heavy. Then you remember using an app from 2004, maybe Winamp or a desktop accounting tool, that felt instantaneous. It's a common feeling, and it points to a deep problem in our industry.
A recent post popular on Hacker News, titled "We should be more ambitious with the software we build," (https://danluu.com/ambitious/) captures this frustration perfectly. The author argues that we've lowered our expectations for software performance and capability. But I think the problem isn't a lack of ambition. It's that our ambition is pointed in the wrong direction.
We're ambitious about using the hottest new framework, adopting the most complex architectural pattern, and adding another tool to our CI pipeline. We aren't ambitious enough about the things that actually matter: core performance, user experience, and developer productivity. For engineering leaders and CTOs, this misdirection isn't just an academic problem. It's a direct tax on your budget, your timeline, and your team's morale.
Chasing Complexity, Calling it Ambition
Too many engineering teams define ambition by the novelty of their tech stack. It's a trap we've seen many clients fall into before they start working with us at AgileStack. A team building a simple CRUD app decides they need a full microservices architecture orchestrated with Kubernetes, a GraphQL federation layer, and three different types of databases. Why? Because that's what a 'modern' or 'ambitious' stack looks like.
This is resume-driven development masquerading as technical strategy. The real cost is staggering.
Instead of shipping features, your best engineers spend months wrestling with YAML files and network policies. The cognitive overhead skyrockets. A simple bug fix now requires a developer to understand the interactions between three different services, each with its own deployment pipeline. Your developer onboarding process, which used to take a day, now takes two weeks.
We worked with a mid-stage startup whose platform was buckling under its own weight. Their dev cycle was over a month long for minor features. The original architecture was a reasonably clean monolith. But a previous leader, in a quest to be 'ambitious', decreed a move to micro-frontends and a serverless backend. The result? A system so complex that no single person understood it. They had ambition, but it was aimed at architectural purity instead of business results.
True ambition isn't about using every new tool in the CNCF landscape. It's about having the discipline to choose the simplest possible solution that solves the business problem effectively. Sometimes that's a 'boring' monolith running on a single server. And that's okay.
The Real Metrics for Ambitious Software
If chasing the latest tech isn't ambition, what is? It's setting and relentlessly pursuing aggressive goals for the things users and developers actually feel.
It's about having the ambition to say:
- "Our p99 API response time will not exceed 100ms."
- "Our largest contentful paint (LCP) will be under 1.5 seconds on a 3G connection."
- "A developer will be able to go from cloning the repo to seeing a running local environment in under 5 minutes."
- "Our test suite will run in less than 60 seconds."
These are not glamorous goals. You won't see them trending on Hacker News. But achieving them has a far greater impact on your business than adopting the latest JavaScript framework. When your application is fast, users are happier and convert better. When your development loop is tight, your team ships more value, faster.
On one project, we helped a client move from a complex, multi-repo setup with a 20-minute build time to a simplified monorepo with a CI process that took less than three minutes. We didn't add any cutting-edge technology. In fact, we removed some. We focused on the developer experience. The team's velocity nearly doubled in the following quarter. That's the result of well-placed ambition.
This requires a shift in thinking. Performance and developer experience aren't 'nice-to-haves' you sprinkle on at the end. They are core features. They need to be defined, ticketed, and tracked with the same rigor as any user-facing functionality.
Your Dev Tooling is Holding You Back
It's not just the production architecture. The tools we use to build software are often a major source of this complexity tax. We've become accustomed to slow IDEs, bloated dependencies, and flaky local environments. We accept that running npm install on a new project might take five minutes and download half a gigabyte of node_modules.
This is a huge, hidden drain on productivity. Let's do some quick math. Say you have a team of 20 engineers. Their average build, test, and lint cycle takes 8 minutes. They run this cycle, conservatively, 15 times a day. That's 2 hours per engineer per day spent waiting. For the whole team, that's 40 hours a day, or 200 hours a week. That's the equivalent of having five of your engineers do nothing but watch progress bars all week.
Would you consider it ambitious to hire five engineers and pay them to do nothing? Of course not. Yet we tolerate this from our tooling.
This is a place where ambition is desperately needed. At DevStack, we build tools focused on this problem because we've lived this pain. Ambitious tooling means:
- Blazing fast feedback loops: Builds should be incremental and near-instantaneous. Tests should run in parallel and finish in seconds, not minutes.
- Simple, reproducible environments: A new developer should be able to get a working environment with a single command.
- Intelligent defaults: The toolchain should guide you toward best practices, not force you to spend hours configuring linters and bundlers.
Investing in developer experience isn't about pampering your team. It's a direct investment in your company's ability to execute. Every minute you shave off a build cycle is a minute an engineer can spend solving a customer's problem.
A Practical Framework for Reclaiming Ambition
So how do you shift your team's focus from chasing complexity to delivering real value? It starts with changing the conversations and the incentives.
1. Define 'Done' Differently
Your definition of 'done' for a feature ticket must include non-functional requirements. Don't let a pull request get merged if it degrades performance. Add these to your PR templates:
- Have you tested the performance impact of your change?
- Does this change increase the complexity of the local development setup?
- Are the new dependencies justified and audited?
Make performance budgets and developer experience metrics part of the core acceptance criteria. This makes the invisible work visible and valued.
2. Create a 'Boring' Backlog
Technical debt and tooling improvements often get pushed aside for 'more important' feature work. The solution is to institutionalize it. Formally allocate a percentage of every sprint, maybe 20%, to this 'boring' backlog. This isn't side work; it's scheduled, planned, and prioritized work.
This backlog should include tasks like:
- Reducing the
node_modulessize. - Improving CI/CD caching to speed up builds.
- Refactoring a confusing module to make it easier to test.
- Removing an unused dependency.
This consistent investment pays massive dividends in long-term velocity and system stability.
3. Audit Your Stack's 'Why'
For every major component in your stack, from the database to the frontend framework, you should be able to answer one question: "How does this specific technology help us achieve our ambitious goals for performance and user experience?"
If the answer is vague, or worse, "Because it's what everyone else is using," it's a red flag. This exercise isn't about chasing a minimalist stack for its own sake. It's about ensuring every piece of your architecture is pulling its weight and is consciously chosen. You should be able to defend your use of React 19 over Preact, or Postgres over a NoSQL database, with concrete data tied to your specific product needs.
What This Means for Your Team
Moving from false ambition to real ambition is a cultural shift. It requires leadership to champion different values.
- Reward simplicity and deletion: Celebrate the engineer who removes 1,000 lines of code, not just the one who adds a fancy new feature.
- Focus on outcomes, not outputs: The goal isn't to ship more pull requests. It's to move key metrics like user satisfaction, system performance, and developer velocity.
- Question the hype: Create a culture where it's safe to challenge the adoption of a new technology and ask for the data to back up the decision.
- Invest in your tools: Treat your internal developer platform and CI/CD pipeline as a first-class product with its own roadmap and dedicated resources.
The next time your team talks about building something ambitious, ask them what they mean. If they start talking about a new distributed database or a service mesh, press them. Ask how it will make the product faster for the user. Ask how it will make the development process simpler and faster for the team.
True software ambition isn't found in the complexity of a system diagram. It's found in the snappy response of a UI, the simplicity of a codebase, and the productivity of a happy, focused engineering team. That's a goal worth chasing.
Building something in this space? AgileStack helps teams ship enterprise-grade software without the consulting-firm overhead. Book a 30-minute call and tell us what you're working on.