Simplepage runs nine live software products with two developers by keeping every product on one shared stack, automating 85% of the deployment pipeline, and refusing features that would fork the platform. 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 (gardeners' 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.
How does one stack power nine products?
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.
What do the numbers say about shared infrastructure?
The numbers are stark: 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 means 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.
Why does saying no enable scale?
Saying no is a scaling strategy: 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 conscious 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.
Where does automation save the most time?
Deployment is where automation saves the most: it handles 85% of our 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 did we automate 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.
How do two developers divide nine products?
Developer specialization is organised around 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 rota alternates weekly, with one of us handling all customer inquiries across all products while the other develops. 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.
Which metrics actually matter?
The metrics that matter are 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 limitation is 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.
When do you hire developer three?
The trigger for developer three is support load exceeding 30 hours weekly, or deployment frequency dropping 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.