# Interviewer: What is Good Technical Debt ?

**Good technical debt** is the intentional and thoughtful use of temporary shortcuts in a product's development to achieve short-term goals, like faster delivery or quick market validation. It’s taken with a clear plan to address it later and managed carefully to avoid long-term issues.

Good technical debt is most commonly used in the following scenarios:

1. **Validating an Idea or MVP:**
    
    * When building a Minimum Viable Product (MVP) to test an idea or gather user feedback, allowing rapid iteration without overengineering.
        
2. **Meeting Tight Deadlines:**
    
    * When a feature or product must be delivered quickly to meet a launch date, market opportunity, or business-critical deadline.
        

**Example: Hardcoding Pricing Rules in a B2B SaaS Platform**

**Scenario in MY Product:**  
Our B2B SaaS platform needed a pricing feature to support tiered plans (e.g., Basic, Premium, Enterprise) for a quick market launch. Instead of building a robust pricing engine that dynamically calculates charges based on configurable rules, we hardcoded the pricing tiers directly in the system.

**Why It Was Good Technical Debt:**

1. **Intentional:** We decided to hardcode the pricing logic to meet a tight deadline for the product launch, knowing it could be replaced later.
    
2. **Temporary:** The hardcoded logic was documented, and our roadmap included plans to develop a flexible, rule-based pricing engine once we validated the tier structure.
    
3. **Aligned with Goals:** This approach allowed us to focus on onboarding customers quickly and testing whether the pricing tiers resonated with our target audience.
    

**Outcome:**  
The platform launched successfully, customers adopted the pricing plans, and their feedback helped us refine the tiers. Later, we replaced the hardcoded logic with a dynamic pricing engine, ensuring scalability as our user base grew.

### **How to Explain This to an Interviewer:**

1. **Start with the Business Context:** "In our B2B SaaS platform, we needed to implement tiered pricing for our product plans to meet a critical launch deadline."
    
2. **Explain the Trade-Off:** "Instead of building a full-featured pricing engine, we hardcoded the pricing rules, saving development time. This allowed us to go live and test the market response to the pricing plans."
    
3. **Discuss the Plan for Resolution:** "We documented the limitation and planned to develop a configurable pricing system in the next two sprints, once we validated the tier structure."
    
4. **Highlight the Result:** "The quick launch helped us onboard customers early and gather feedback, which guided us in designing a scalable pricing engine later."
    

**Detailed Technical Implementation of the Hardcoded Pricing Logic Example**

#### **Phase 1: Quick Implementation (Hardcoding the Logic)**

To save time and meet the product launch deadline, your team hardcoded the pricing logic directly into the application code.

1. **Step 1: Define Pricing Rules**
    
    * The team identified three tiers (e.g., **Basic**, **Premium**, and **Enterprise**) with fixed prices and specific feature access for each plan.
        
    * { "Basic": {"price": 50, "features": \["Feature A", "Feature B"\]}, "Premium": {"price": 100, "features": \["Feature A", "Feature B", "Feature C"\]}, "Enterprise": {"price": 200, "features": \["All Features"\]} }
        
2. **Step 2: Hardcode the Rules in the Codebase**
    
    * The pricing rules were directly embedded into the application’s backend logic.
        
    * Example (in a Python-based backend)
        
    * def get\_pricing\_plan(plan\_name): pricing\_plans = { "Basic": {"price": 50, "features": \["Feature A", "Feature B"\]}, "Premium": {"price": 100, "features": \["Feature A", "Feature B", "Feature C"\]}, "Enterprise": {"price": 200, "features": \["All Features"\]}, } return pricing\_plans.get(plan\_name, {"price": 0, "features": \[\]})
        
3. **Step 3: Quick Integration**
    
    * Backend APIs used the hardcoded logic to calculate and return prices based on user-selected tiers.
        
    * @[@app](@app).route('/api/get-pricing', methods=\['GET'\]) def get\_pricing(): plan = request.args.get('plan') return jsonify(get\_pricing\_plan(plan))
        

4. **Step 4: Testing and Deployment**
    
    * * Basic test cases verified the logic, such as:
            
            * Validating pricing for each tier.
                
            * Ensuring correct feature lists were returned for selected tiers.
                

This allowed the feature to be deployed in minimal time, ensuring a successful product launch.

#### **Phase 2: Addressing the Technical Debt (Dynamic Pricing Engine)**

Once the initial product validated the pricing structure, your team worked to replace the hardcoded logic with a scalable and configurable pricing engine.

1. **Step 1: Database Design**
    
    * The team created a database schema to store pricing plans and their associated features dynamically.
        
    * CREATE TABLE PricingPlans ( id INT PRIMARY KEY, name VARCHAR(50), price DECIMAL(10, 2) );
        
        CREATE TABLE PlanFeatures ( id INT PRIMARY KEY, plan\_id INT, feature\_name VARCHAR(100), FOREIGN KEY (plan\_id) REFERENCES PricingPlans(id) );
        
2. **Step 2: Backend Refactoring**
    
    * The hardcoded logic was replaced with database queries to fetch pricing and feature data dynamically.
        
    * def get\_pricing\_plan\_from\_db(plan\_name): plan = db.session.query(PricingPlans).filter\_by(name=plan\_name).first() features = db.session.query(PlanFeatures).filter\_by(plan\_id=[**plan.id**](http://plan.id/)).all() return { "price": plan.price, "features": \[f.feature\_name for f in features\] }
        
3. **Step 3: Admin Config Panel**
    
    * Built an admin interface to allow business teams to update pricing plans and features without needing code changes.
        
    * Example:
        
        * Add/modify plans through an admin dashboard with form inputs for pricing and features.
            
4. **Step 4: Testing and Deployment**
    
    * Conducted thorough integration tests to ensure:
        
        * Pricing and features returned correctly.
            
        * The admin panel updates reflected dynamically in the frontend
            
5. #### **Technical Benefits of the Upgrade**
    
    * **Scalability:** Easily add, update, or remove pricing plans as the product evolves.
        
    * **Flexibility:** Supports region-specific pricing or promotional discounts without code changes.
        
    * **User Empowerment:** Business users manage pricing directly, reducing dependency on developers.
