Nine live products, two developers, one support inbox. The trick isn't heroics, it's refusing to let the products drift apart. Over 6 months, we've maintained a 99.8% uptime across all platforms while shipping new features regularly. Here's exactly how we do it.
What does "nine products" actually mean?
Nine products means nine separate codebases, nine domain names, nine deployment pipelines, and nine sets of user expectations. Oh and that is in addition to our usual client obligations, retainer contracts, site builds etc!
Our portfolio includes Eddi (AI content assistant), Sumlo (timesheet management), Patch (garenders project management), Printo (PDF generation), Glint (analytics), Pulse (uptime monitoring), SimpleWebsite (site builder), and our affiliate site engine and more.
The key insight: you don't need unicorn-scale products to build a sustainable software business.
One stack, nine skins: the architecture decision that changed everything
Shared infrastructure is the only reason this works. Every product runs on identical Umbraco foundations with shared authentication, payment processing, and monitoring. When we patch a security vulnerability, it deploys to all nine products within 24 hours through our templated CI pipeline.
Our shared component library includes 47 reusable UI components, from basic form inputs to complex data visualization widgets. New product development takes 60% less time because we're not rebuilding basic functionality. The constraint is brutal but effective: if a client requests a feature that would fork our shared platform, we say no.
The numbers on shared infrastructure
Shared infrastructure reduces our maintenance overhead by approximately 80% compared to independent codebases. We spend 6 hours weekly on infrastructure maintenance versus an estimated 30+ hours for separate systems. Code reuse across products sits at 73% for core functionality, 45% for UI components.
How do you prevent feature drift across nine products?
Feature drift prevention requires architectural discipline and clear decision-making frameworks. We maintain a shared feature matrix that tracks which capabilities belong to which products. Before building any new functionality, we ask: "Does this belong in the shared layer, or is it product-specific?" This is all AI driven from our central knowledgebase that we continually reference, update and refer to.
Our rule: features that benefit multiple products get built once in the shared layer. Product-specific features must justify their maintenance cost. We've rejected approximately 40% of requested features because they would increase system complexity without proportional value.
Automation: where we save the most time
Automation handles 85% of our deployment pipeline, from code commits to production releases. Our CI/CD system runs automated tests per deployment, deploys to staging environments automatically, and promotes to production with a single button click.
Our knowledge base integration and automated response system resolve common issues quickly and easily. The remaining require human attention, typically for feature requests or complex technical issues.
What we automated first
Automated testing was our first investment, saving approximately 15 hours weekly in manual QA. Deployment automation followed, reducing release time from 2 hours to less than 6 minutes per product. Invoice generation, user onboarding, and basic customer support automation collectively save 20+ hours weekly.
The art of strategic "no": why constraints enable scale
Strategic constraints prevent scope creep and maintain system coherence. We maintain a list of features and integrations that would compromise our shared infrastructure approach - these are regularly reviewed and sometimes we implement them (a concious business decision). This includes custom authentication systems, product-specific databases, and framework departures.
Saying no to 40% of feature requests sounds limiting, but it enables focus on the 60% that genuinely improve user outcomes. Our approach and feedback from users suggests that constraint-driven development doesn't hurt user experience.
Team structure: how two developers divide nine products
Developer specialization follows product categories rather than technical disciplines. One developer owns the content and productivity tools (Eddi, Sumlo, Patch), while the other manages technical utilities and infrastructure (Printo, Glint, Pulse). Both contribute to shared platform development and new product launches.
Our support alternates weekly, with the one of us handling all customer inquiries across all products, the other developing. This cross-product exposure helps identify common issues and improvement opportunities. Average response time to customer inquiries is less than 2 hours during business days.
Metrics that matter: how we measure efficiency
Key performance indicators focus on developer productivity and system reliability. We track deployment frequency (average 3.2 deployments per week per product), time to production (average 6 minutes), and incident response time (average 45 minutes to resolution).
What doesn't scale: the honest limitations
Customer support intensity varies dramatically between products. Some products will require more support time per user than others, purely down to the complexity differences.
Technical debt accumulates faster in shared systems because shortcuts affect multiple products simultaneously. We allocate 20% of development time to refactoring and technical debt reduction, but this percentage increases as the product portfolio grows.
The expansion question: when do you hire developer three?
Developer three becomes necessary when support load exceeds 30 hours weekly or when deployment frequency drops below twice weekly per product. We're currently at 12 hours weekly support load and 3.2 weekly deployments, suggesting 6-8 months of runway before expansion.
The challenge isn't just development capacity but maintaining shared architecture coherence with additional contributors. Our onboarding documentation runs 47 pages specifically covering architectural decisions and constraints that enable our multi-product approach.