During client onboarding and partner discussions, we frequently encounter varying perspectives on technical implementation. Some teams advocate for highly sophisticated architectures that may be overkill, while others propose simpler solutions that could limit future growth.
In this article, I'll share our pragmatic approach to software development - guidelines we've refined through years of experience that help us make balanced decisions without being overly prescriptive.
Disclaimer
This article primarily addresses software development for business applications and services. For systems directly impacting human safety, health, or critical financial operations, established industry standards and regulatory requirements typically dictate development practices.
If you're working in such regulated domains, this article's flexibility-focused approach may not align with your compliance requirements.
3 Case Examples
Throughout this article, we'll reference three project examples to illustrate our points:
- Hospital Suite Software (6000 base hours) A comprehensive patient management system with critical health data handling Base hours cover: Core feature development, basic UI/UX, initial deployment setup Typical overhead:
- Automated Testing: +40% of feature development time
- Infrastructure/DevOps: +25% of total project time
- Ongoing maintenance: ~15-20% of initial development cost annually
- Booking.com Replica (3000 base hours) A full-featured hotel booking platform with payment processing Base hours cover: Core booking features, user management, payment integration Typical overhead:
- Automated Testing: +30% of feature development time
- Infrastructure/DevOps: +15% of total project time
- Ongoing maintenance: ~10-15% of initial development cost annually
- Real Estate Platform (250 base hours) A property showing scheduler with basic booking features Base hours cover: Basic scheduling system, user accounts, simple deployment Typical overhead:
- Manual Testing: +20% of feature development time
- Basic Infrastructure: +10% of total project time
- Ongoing maintenance: ~5-10% of initial development cost annually
These base estimates represent the core development work before adding quality assurance, testing, and infrastructure considerations. The overhead percentages reflect typical additional time needed for proper implementation and maintenance of each feature.
The Real Cost of Software
Software development represents a significant investment, both financially and in terms of trust. When engaging developers, you're relying on their judgment to deliver solutions that maximize value while meeting your business objectives. While most development teams have established best practices and quality standards, rigidly applying these across all projects, regardless of context, can lead to inefficient resource allocation.
Estimates
While the time estimates provided are not from specific projects, they are based on relative real-world experience and are designed to effectively illustrate the concepts discussed in this article.
The Ripple Effect of Early Decisions
Technical decisions made in a project's early stages can have far-reaching implications. For fixed-price projects especially, overengineering or underengineering can severely impact delivery timelines and profit margins. Finding the right balance is crucial for both client satisfaction and project sustainability.
Guidelines for Determining Project Approach
We've adopted a framework that helps us tailor our development approach to each project's specific needs. This framework considers multiple factors to determine the appropriate level of technical sophistication.
System Criticality Assessment
Many project teams have a strict "Definition of Done" that requires certain tooling, testing benchmarks and quality checks regardless of complexity or commercial goals. While there are many articles emphasizing code quality and testing, we believe quality measures should align with your market needs and commercial objectives.
Consideration 1) Architecture Complexity The reason this is important is because you'll want consider things in for: redundancy, you'll also want monitoring, analytics, logging and automated testing and safeguards to name a few. These are all complexities that need to be considered from the start, or atleast we think so. We want to first build our protective shell and than build the software that runs inside of it, similar to how you would with other sensitively handled industries.
If the project is not fitting into these, then these types of measure have less priority, weather they get additional priority falls to the following other steps.
Consideration 2) External Dependencies Likewise, if we're deploying this software to sensitive areas - we'll also assess which NPM / external packages we'll use (if any) to solve a specific problem. We do not want to be using too-many packages as it increases the risks if something goes wrong, we'll also want to version lock the packages and lastly we'll check to see how likely those packages will be maintained long-term.
For now, let's add some examples:
- Software for a hospitals internal system - Critical : Advise Implementing all of above
- Software that is used for manage hotel bookings - High : Advise Implementing Redundancy, Monitoring, Logging (as examples)
- Software for a real-estate agent to manage bookings - minor : Check next steps
Please note: Although in case 3 we're marking it as minor, it's still someones business, reputation and interests at risk, however, also for the sake of mental health, it's not life and death - but the uptime and reliability of the product are still important
Examples and Cost Impact
Let's examine what happens when we attempt to implement the same enterprise-level architecture across projects of different scales:
Hospital Internal System Software (6000 base hours) Requires comprehensive enterprise architecture from day one:
- High-availability redundant infrastructure: 400 hours
- Real-time monitoring and alerting: 250 hours
- Detailed audit logging and compliance tracking: 300 hours
- Comprehensive automated testing: 400 hours
- Scalable microservices architecture: 350 hours
Total enterprise architecture overhead: ~1700 hours (28% increase) This overhead is justified and required given the critical nature of healthcare systems.
Hotel Booking Management System (3000 base hours) Trying to implement the same enterprise-grade measures:
- High-availability redundant infrastructure: 250 hours
- Real-time monitoring and alerting: 180 hours
- Detailed audit logging: 200 hours
- Comprehensive automated testing: 250 hours
- Scalable microservices architecture: 220 hours
Total overhead: 1100 hours (37% increase!) This represents a significant portion of the budget that could instead fund core booking features and iterations. The enterprise architecture still heavily impacts the project's feasibility.
Real Estate Agent Booking System (250 base hours) Attempting to implement the same enterprise-grade measures:
- High-availability redundant infrastructure: 120 hours
- Real-time monitoring and alerting: 80 hours
- Detailed audit logging: 90 hours
- Comprehensive automated testing: 120 hours
- Scalable microservices architecture: 100 hours
Total overhead: 510 hours (204% increase!!) This would still completely overwhelm the original scope and budget. Even with scaled-down implementation hours, applying enterprise architecture would triple the project's scope!
The key takeaway is that implementing enterprise-grade architecture in smaller projects remains catastrophically inefficient, even when the implementation hours are proportionally scaled. For early-stage products or smaller businesses, you provide more value by implementing appropriate-scale solutions. Enterprise infrastructure that's essential for a hospital system would still kill the viability of a small real estate project, even with reduced implementation hours. Save the enterprise-grade infrastructure for when it's truly needed - you'll build better client relationships by being pragmatic rather than dogmatic about implementation standards.
Step 2 - Project Phase
Projects evolve through distinct phases, each with different priorities:
Proof of Concept -> MVP -> Growth -> Maturity -> Maintenance
This progression significantly influences technical decisions. For instance, our real estate platform (250 hours) might prioritize rapid market validation over comprehensive test coverage. During the growth phase, focus shifts to scalability, monitoring, and automated testing to support increased usage and feature complexity.
Our Approach to Development
We've seen projects where premature optimization led to challenges. One notable example was a non-critical MVP that implemented extensive test coverage (90%+) and complex deployment pipelines before validating market fit. While technically impressive, this consumed valuable resources that could have been better used for rapid iteration and market validation.
Development Strategy
Our Refined Approach:
- Develop core features as isolated, customer testable components (Storybook) while gathering continuous feedback
- Implement robust safeguards around critical workflows (payments, data persistence, user authentication)
- Focus on delivering a stable V1 that meets core business requirements
This methodology maintains quality where it matters most while enabling rapid iteration. By carefully targeting our quality assurance efforts, we've helped clients reduce initial development costs by 25-35% without compromising essential functionality.
Scaling and Maintenance
Post-Launch Evolution: Once product-market fit is established, we systematically enhance the technical infrastructure. This includes introducing comprehensive testing, monitoring solutions, and scalability improvements alongside new feature development.
This phased approach ensures that technical investments align with validated business value and actual usage patterns.
Strategic Recommendations
Embrace Contextual Quality Standards
- Differentiate between critical and non-critical features to optimize resource allocation - typically saving 30-40% on initial development
- Align quality measures with actual business risk and impact levels
- Focus on practical outcomes rather than theoretical best practices
- Consider implementing feature flags to gradually roll out complex functionality
Adapt to Your Product's Evolution
- Prioritize speed and flexibility during early stages over comprehensive testing
- Implement quality measures progressively as your product proves its market value
- Regularly reassess technical debt against business growth needs
- We've observed that premature optimization often consumes 20-30% of early budgets that could better serve core feature development
Balance Technical and Business Priorities
- Seek equilibrium between engineering excellence and business constraints
- Invest heavily in protecting revenue-critical features like payment processing
- Scale your quality assurance efforts with your product's success
- Maintain flexible quality standards that evolve with your product's maturity and market position
Want to reach out?
Did you find the article interesting, want to discuss it or ways that Goldmund might be able to help you? Please feel free to reach out using one of the methods below.
Phone
+31 6 301 818 89Other Articles
