Avoiding Technical Debt Without Slowing Down: A Product Development Journey

By Ryan Hardy, Jr. Account Lead

Six years ago, when I first started as a software developer co-op at Seven Hills Technology, I didn’t truly understand what tech debt was. I’d never seen it, felt it, or dealt with the consequences. My experience was limited to new code bases and school projects. Fast forward to today, and I’m an account lead working with clients to drive their product growth upward. I’ve seen the impacts of technical debt firsthand, dealt with its consequences, and had to take action to address it.

Working with a small but rapidly growing golf analytics company has taught me that the real challenge isn't avoiding technical debt entirely—it's making smart decisions about when to take it on and how to pay it down before it cripples your velocity. In a team of just eight people (four developers, four client team members), every technical decision has immediate business consequences. Failure to tackle these problems leads to the suffocation of growth

From Theory to Reality: What School Doesn't Teach You

In computer science classes, we learned about clean code, proper design patterns, and optimal algorithms. But nobody teaches you how to make these technical decisions when you're under pressure from the client to onboard 15 new customers this month, and your current system is already straining under the load.

The transition from developer to account lead forced me to think differently about technical debt. Instead of seeing it as a purely technical problem, I started viewing it through a business lens. Time is money, especially in the software business. Technical debt isn't just about code quality—it's about your ability to respond to market opportunities, onboard new clients, and scale your operations.

The only issue with this shift in perspective was that I needed a new approach to the technical decisions I came across. I decided to adopt the OODA loop framework: Observe, Orient, Decide, and Act. I discovered it while reading a book about decision-making within autonomous systems called Army of None by Paul Scharre. It's a continuous cycle that helps balance the need for speed of action with the requirement for quick decision-making. Created by John Boyd, who at the time was working within the US Air Force, it is an effective and simple framework for organizations to apply in rapidly changing environments.

Case Study: When Cron Jobs Become Business Bottlenecks

Let me share a real example that perfectly illustrates this balance. This golf analytics platform processes thousands of golfer score records daily, providing real-time insights that our clients' customers depend on for tournament management and player development.

Business Goal: The client needed to handle tens of thousands of score records daily with real-time accuracy while scaling to support new customer partnerships within a time-sensitive environment.

OODA Loop in Action

Observe: The system was using scheduled cron jobs to process score submissions. During peak tournament season, cracks would start to show. Processing delays were increasing. Some score updates took hours to appear, if they appeared at all. We couldn’t guarantee processing capacity, which slowed down customer onboarding. More importantly, our client was losing potential customers because we couldn’t promise real-time score processing, especially for the larger customers they wanted to land.

Orient: As the account lead, I had to help the client understand this wasn't just a technical scalability issue—it was directly blocking business growth. The client had key customer partnerships waiting for real-time capabilities. Each partnership represented significantly more monthly recurring revenue, but they wouldn't sign without processing guarantees.

We identified the core problem: our batch processing approach created artificial constraints on data throughput. The scheduled jobs meant we could only process scores at fixed intervals, and if a job failed or took too long, it created a cascade of delays and issues within other core features of the product.

Decide: We had two options. We could optimize the existing cron job system by adding more compute power, parallelizing processing, and increasing the memory size. This would be faster to implement and less risky. Or we could redesign the architecture using AWS Lambda functions for event-driven processing, eliminating the batch constraints.

The quick fix would solve the immediate problem, but wouldn't address the fundamental limitation. More importantly, it would mean taking on significant technical debt. Every new customer would add to the capacity issue, and we'd constantly be playing catch-up with processing demands.

We decided to invest in the Lambda architecture. Yes, it would take longer upfront, but it would eliminate the constraint that was blocking business growth in the long run.

Act: We implemented a webhook-based event processing system where each score submission triggered immediate processing. Instead of waiting for the next cron job, scores were processed within seconds of submission. We also built in automatic scaling and error handling, so processing capacity is adjusted dynamically to demand.

Business Resolution: The new architecture enabled our client to onboard key customer partnerships more quickly and with greater confidence, resulting in significant revenue growth for our client. More importantly, it removed processing capacity as a constraint on future growth. The client could now confidently pursue partnerships with larger and larger clubs without worrying about technical limitations slowing them down. Without a flexible and iterative decision-making process, it was unlikely that we could have accessed the problem quickly enough and pivoted to address it.

The Real Lesson: Technical Debt as a Strategic Opportunity

What this experience taught me is that technical debt isn't inherently bad—it's an opportunity. The key is being intentional about when you take it on and having a clear plan for addressing it.

In our case, we could have “tackled” the debt by band-aiding the cron job system. That would have helped our client onboard their customers faster, but would have created a maintenance burden that would slow us down long-term. Instead, we invested in eliminating existing architectural debt, which accelerated their ability to grow.

Framework for Smart Technical Decisions

Through experiences like this, I've developed a framework for tackling these problems in a fast-growing business:

Start with the business impact. Every technical decision should be evaluated based on how it affects your ability to serve customers and grow.

Understand your constraints. In a small team, your biggest constraint is often people, not technology. Choose solutions that your team can maintain and extend, even if the upfront costs of time and people are higher

Plan for the next phase of growth. Don't optimize for your current scale—optimize for where you'll be in six months. But don't over-engineer for the wrong problems.

Make debt visible. When you do take on technical debt, document it clearly and include the cost of addressing it in future planning. Hidden debt is what kills velocity.

Invest in elimination, not just management. Instead of just managing technical debt, look for opportunities to eliminate entire categories of it through architectural changes if possible.

Moving Forward: Continuous Improvement

The OODA loop doesn't end with a single decision. We're constantly observing new challenges, orienting our approach based on business needs, deciding on improvements, and acting to implement them.

Currently, we're observing new patterns in our data processing that suggest opportunities for further optimization. But now we have a framework for evaluating whether those optimizations serve business goals or just technical perfectionism.

The key insight from my journey from developer to account lead is that sustainable velocity comes from aligning technical decisions with business value. Improving your client’s life and yours. Technical debt isn't the enemy—poor decision-making is.

The Partnership Advantage

The smartest technical decisions often come from having a real understanding of the business context. Knowing the pressures your client is facing, the opportunities they’re chasing, and the friction in their day-to-day operations helps you move beyond just solving technical problems. It lets you prioritize solutions that move the business forward.

We’re always up for conversations about how to balance speed, scalability, and smart decision-making. If you’re tackling similar challenges and want to compare notes, reach out. We’re happy to share what we’ve learned.