Somewhere around project 150, I started keeping a list. Not a formal retrospective - just a running note of things I kept seeing, patterns that appeared across clients who had nothing else in common. A fintech startup in New York and a logistics company in Germany hitting the same problem at the same project phase. An edtech founder and a PropTech founder making the same architectural mistake in the same month.
The patterns that show up repeatedly across 200+ projects are worth naming. Not because they are surprising - most are obvious in retrospect - but because obvious things are still ignored constantly, and naming them with specificity is more useful than naming them as platitudes.
What Actually Determines Whether a Project Succeeds
I have worked on projects with bad technology that succeeded and projects with beautiful architecture that failed. The technology is a smaller determinant of project outcome than most engineers believe.
The single factor that most reliably predicts project success: does the person making product decisions have direct, regular access to customers?
Projects where the founders or product owners are actively talking to customers - not talking to salespeople who talk to customers, not reading NPS survey results, but having direct conversations about what problems they are trying to solve - ship better products. The adjustment cycle is shorter. The team spends less time building things that do not matter.
Projects where the product direction is set by assumption, by analogy to competitors, or by internal stakeholder preferences tend to drift. They build features that are logical on paper but not actually what customers need. They discover the mismatch after shipping.
This sounds like "talk to your customers," which is advice everyone has heard. The specific version that matters: at least one person on the founding team should have a customer conversation every week, without exception, until the product has clear product-market fit. Not a demo - a conversation about problems. The discipline of this habit is what separates the teams that figure it out from the ones that stay stuck.
The Estimate Problem Has Never Been Solved
Fifteen years ago, software projects were late. Today, software projects are late. The tools have changed dramatically, the methodologies have cycled through waterfall to agile to various flavors of both, the team sizes have varied, the technology has evolved. Projects are still late.
The fundamental reason has not changed: software is a creative work, and creative work cannot be estimated with precision. The estimate for a feature is based on your mental model of how the solution works. When the mental model encounters the actual system, it is always somewhat wrong. The delta between your model and reality is the source of most schedule slippage.
The mitigation that actually works is not better estimation - it is better planning. You do not get more accurate by trying harder to estimate. You get more accurate by:
Decomposing work into smaller units. Estimates on two-day tasks are more accurate than estimates on two-week tasks, because two-week tasks contain more unknown unknowns.
Tracking historical velocity and using it to calibrate estimates. If features at your company consistently take twice as long as estimated, your estimates are off by a factor of two. Use the historical data to correct for your team's systematic bias.
Building in buffer explicitly rather than hoping for better performance. A plan with explicit buffer that the team understands is a plan. A plan without buffer that the team knows is not realistic is fiction.
Not mistaking a date commitment for an estimate. Telling an investor that you will launch in six weeks is a commitment. The estimate for the underlying engineering work is separate from the commitment. If the estimate says ten weeks and you commit to six, you have a plan problem, not an estimate problem.
The Technical Debt Ratchet
Every project accumulates technical debt. This is not a failure - it is the cost of moving at any speed other than zero. The question is whether the debt accumulation is controlled or out of control.
The ratchet I have observed: technical debt increases fastest during the first six months after a funding event. The reason is pressure. New money creates new timelines, new feature commitments, and a new sense of urgency. Engineering teams respond by shipping faster. The shortcuts taken to ship faster are the debt.
The debt then becomes a constraint on the next period of growth. The feature that would take two weeks to build on a clean codebase takes six weeks because of the debt. The outage that happens at scale happens in the rushed code from six months ago.
The companies that escape this ratchet are the ones that treat technical debt as a budget item, not an afterthought. Twenty percent of engineering time for maintenance, refactoring, and debt reduction, every sprint, regardless of the feature backlog pressure. This is not a popular position to defend to investors who want features. It is the position that keeps engineering velocity from declining over time.
What Changes and What Stays the Same
The technology changes faster than most people track. Fifteen years ago, the infrastructure choices for a web application were: your own servers, or maybe AWS EC2 if you were early. Today the decision is: which managed services to use, because building on raw infrastructure is almost never right for a startup.
The programming languages have evolved. The deployment patterns have changed fundamentally (containers, Kubernetes, serverless). The AI capabilities available are unrecognizable compared to 15 years ago. The development tooling, the testing frameworks, the monitoring approaches - all substantially different.
What has not changed:
The importance of requirements clarity. Projects with clear, specific requirements ship more reliably than projects with vague requirements. Every methodology in the last 50 years has grappled with this. None has solved it. The teams that get clear requirements are the ones that invest time in getting them, not the ones that use the right methodology.
The importance of deployment discipline. You cannot manage what you cannot deploy reliably. Teams with a clean deployment process can fix problems quickly. Teams without one hold their breath before every release and are slow to respond when things break. Fifteen years ago this meant runbooks and SSH access. Today it means CI/CD pipelines. The principle is the same.
The importance of the team composition over the technology choice. The best technology with a team that does not communicate effectively, does not review each other's work, and does not maintain a shared understanding of the system produces worse outcomes than a mediocre technology choice with a cohesive, communicating team. Every time.
The One Thing I Would Do Differently
If I could go back and change one thing in how I approach client engagements, it would be this: I would spend more time in the first two weeks on the human dynamics of the engineering team and less time on the technical inventory.
I spent years assuming that technical problems were primary and human problems were secondary. The technical assessment comes first: find the architectural issues, the security gaps, the performance problems. Then address the team dynamics.
The pattern I eventually recognized: the worst technical problems in any engagement are almost always symptoms of human dynamics problems. The codebase with no tests has no tests because the culture does not require them. The deployment with no rollback capability has no rollback capability because nobody with authority thought it was worth the investment. The performance issues from missing indexes exist because no one was doing query performance review in code reviews.
Fix the human dynamics - the culture, the process, the communication - and the technical problems start getting better without requiring someone to fix each one individually. Fix the technical problems without addressing the human dynamics and new technical problems appear to replace the ones you fixed.
This is the lesson that took me the longest to learn and that I apply most consistently now.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr