Building a scalable, performant, and maintainable digital music e-commerce platform is no small feat. With modern frameworks, cloud platforms, and emerging technologies, we are always overwhelmed with the number of choices. But at Linespace, we believe that simplicity scales.

This blog series is a deep dive into the engineering decisions behind Only Make Waves, a digital marketplace for independent artists to sell and stream their music.

• Part 1: You Ain’t Gonna Need It (YAGNI) – Why we focused on building only the essential functionality and how that decision shaped our architecture.
• Part 2: Simplicity Scales – How a lightweight, modular system allowed us to handle growth without unnecessary complexity.
• Part 3: Make It Work, Make It Right, Make It Fast – The optimizations and refinements that fine-tuned our platform for performance, security, and scalability.

This first post explores our YAGNI-first approach, where we resisted the temptation to over-engineer and instead prioritized delivering a fully functional product with just what our customer needed to launch.

The Problem: Avoiding Over-engineering in an E-Commerce Platform

When starting development, we faced several key challenges:

• Artists needed a simple way to upload, price, and sell their music.
• Fans needed a frictionless experience to browse, preview, and purchase tracks.
• The system needed to support scalability without unnecessary complexity.
• Security, data integrity, and uptime were critical from day one.

However, we also had limited engineering resources, which meant that every feature had to be deliberate—no wasted effort, no unnecessary complexity.

Many teams fall into the trap of overengineering their systems by building for hypothetical future problems. We wanted to avoid this by following the YAGNI principle:

“You Ain’t Gonna Need It” (YAGNI) is a software development principle that suggests developers should not add functionality until it is necessary.

With this in mind, our focus was clear:
Build what we need today, not what we think we might need tomorrow.

Architecture: Keeping It Simple and Pragmatic

A well-designed system balances simplicity, scalability, and maintainability. To achieve this, we made a series of intentional decisions in our stack and architecture.

1. Monolithic First: Rails for Rapid Development

We chose Ruby on Rails as the foundation of the application.

• Why Rails? It allows for rapid prototyping, has strong conventions, and offers a powerful ecosystem of libraries (gems) that reduced development time.
• Monolithic vs. Microservices: We opted for a monolithic architecture at launch because:
  • A single codebase simplified development and deployment.
  • Microservices introduce complexity (e.g., inter-service communication, orchestration, and API contracts) that we didn’t need yet.
  • Scaling a well-structured monolith is easier than maintaining multiple poorly planned microservices.

Rails provided built-in features for authentication, database management, API design, and background processing, allowing us to focus on business logic rather than boilerplate.

2. PostgreSQL: Choosing the Right Database for E-Commerce

For data storage, we selected PostgreSQL because of its:

• ACID compliance, ensuring transactional integrity.
• JSONB support, allowing flexibility without introducing NoSQL complexity.
• Full-text search capabilities, making it easier to implement search functionality without external dependencies.
• Indexing and performance optimizations, ensuring scalability as data grows.

What we didn’t do: We avoided sharding or NoSQL databases (like MongoDB) because our relational data model was well-structured and fit within PostgreSQL’s capabilities.

3. File Storage with Active Storage and Amazon S3

Handling music file uploads was a critical part of the platform. Instead of building a custom media processing pipeline from scratch, we leveraged Active Storage and Amazon S3:

• Active Storage seamlessly integrates with Rails, handling uploads without extra dependencies.
• Amazon S3 provided reliable, scalable storage with built-in redundancy.
• Direct uploads from the client-side prevented unnecessary load on our servers.

Had we over-engineered this, we might have built a complex media pipeline too early, delaying the initial launch for our customer.

4. Stripe for Payment Processing

Rather than rolling out a custom payment solution (which would require PCI compliance and extensive security audits), we chose Stripe for handling transactions.

• Pre-built checkout flows reduced friction for buyers.
• Webhooks allowed us to trigger fulfillment actions automatically.
• Security & compliance were managed by Stripe, reducing our liability.

What we avoided:
– No in-house payment processing (too much complexity).
– No cryptocurrency integration (not essential for launch).

5. Keeping Infrastructure Lightweight with Linespace

For hosting, we chose Linespace instead of AWS.

• Why? Linespace offers simple, scalable hosting without the complexity of AWS services.
• Managed database services offloaded maintenance tasks like backups and scaling.
• Auto-scaling ensured we could handle spikes in traffic without downtime.

What we didn’t do:
– No Kubernetes—container orchestration wasn’t necessary at this stage.
– No Terraform—manual infrastructure provisioning was sufficient.

Key Lessons Learned

1. Build for Today, Not Tomorrow

Instead of speculating about what we “might” need, we focused on real user needs and iterated as required.

2. Constraints Drive Creativity

By limiting scope and avoiding unnecessary complexity, we developed efficient solutions faster than if we had built unnecessary abstractions.

3. Prioritize Simplicity and Maintainability

A simple, well-structured codebase is easier to scale than a complex, over-engineered system with unnecessary layers of abstraction.

What’s Next?

In Part 2: Simplicity Scales, we’ll explore:

• Scaling our database and infrastructure without unnecessary complexity.
• Handling increasing traffic efficiently with load balancing.
• Optimizing search and browsing speed while keeping query performance in check.