Beyond Outsized Ambitions

When I started working on MockFast, I had no intention of creating the next Silicon Valley unicorn. It was just me being fed up with reinventing the wheel for every new project. Something I was tinkering with in the evenings after work, or for a few hours on weekends when my girlfriend would leave me alone for a bit.

Between a job that already takes 40-50 hours per week, the usual chores, and wanting to actually have some kind of social life, you gotta be realistic about what you can accomplish. I had maybe 5-10 hours a week to dedicate to this personal project. Under these conditions, you really need to focus on the essentials.

After some times of development (with plenty of breaks, let's be honest), the main lesson I learned: the difference between a finished project and an abandoned one is often just staying pragmatic. Nobody has ever used a perfectly designed project that was never completed.

Seriously, we all start with big dreams, but we need to come back down to earth. If you have 100 users after a year, that's already an incredible success for a side project. So why bother with an architecture that could handle 100,000 users if it means you'll never actually finish?

Don't get me wrong - microservices are awesome even if you don't have tons of users. They're fantastic if your primary goal is learning the ins and outs of modern distributed architectures. I've got colleagues who've built incredibly complex systems just to learn how Kubernetes orchestration works or to master event-driven architecture patterns. Thats a perfectly valid reason to go that route. But for me, this project wasn't primarily about learning new tech - it was about solving a real problem and actually shipping something useful.

Simplicity as a Deliberate Strategy

My goals were pretty straightforward:

• Solve a real problem that was frustrating me daily
• Learn some interesting things and actually enjoy the building process
• Create something useful without burning myself out
• Avoid unecessary complexity that would just slow me down

A monolithic architecture let me:

• Build quickly without drowning in infrastructure setup
• Focus on solving the actual problem instead of architecting endlessly
• Reduce the mental overhead of tracking too many components
• Keep the project enjoyable and doable (because who needs more stress?)
• Iterate faster and see actual results rather than just planning

Simplicity wasn't a comprimise – it was my strategy for making measurable progress with the limited time and energy I had.

The Hidden Burden of Premature Optimization

Microservices sound impressive in tech talks, but for a side project, they're often just adding complexity that you don't need. Breaking down an application into microservices requires:

• Significant time upfront just designing everything
• Setting up complex infastructure that will cause headaches at midnight
• Mental energy that could be used for more important aspects
• Time taken away from building features users might actually care about

I've seen several promising side projects (including some of my own) get stuck in a swamp of permature optimizations, only to be abandoned before they ever reached users. Even the most elegant architecture is useless if your project never sees the light of day.

When you're coding in those limited evening hours after work, every hour is precious. I'd rather spend my energy building something that solves problems than configuring systems that nobody asked for.

Resources Are Limited (Especially Time)

Let's be realistic: side projects happen in those small slices of time you find between other committments. Every hour spent:

• Dealing with complex architectures and getting lost in configuration files
• Trying to make distributed systems work together properly
• Troubleshooting communication issues between services
• Researching solutions to problems that only exist because of your architecture choice

is an hour not spent:

• Building features that make your project actually useful
• Solving interesting technical challenges that matter to your project
• Using and enjoying your own creation (which is a big part of motivation)
• Getting feedback to see if you're even on the right track

Time is the scarcest resource in a side project – and never seems to be enough of it. I've never once found myself with too much free time for my side projects, and I doubt you have either.

User Experience Trumps Technical Excellence

An interesting thing I discovered while building MockFast – not a single user has ever asked me about my architecture decisions. No one really cares if I'm using microservices, a monolith, or any other technical approach. What actually matters to them:

• Does the service work reliably when they need it?
• How quickly can issues be fixed when something goes wrong?
• Can they figure out how to use it without extensive documentation?
• Does it actually improve their workflow in some meaningful way?

A reliable monolith that works consistantly is far more valuable than a perfectly designed distributed system that's perpetually "almost ready" or breaks in unpredictable ways.

When Will Microservices Make Sense?

I'm not saying microservices are wrong or that I'll never consider them. The transition isn't off the table – it's just postponed until it actually becomes necessary. I'll consider breaking things up when:

• The project has actual users who depend on it
• Certain components need to scale independently because of usage patterns
• Performance becomes a genuine problem rather than a theoritical concern
• I have more consistent time to invest in development
• The benefits clearly outweigh the additional complexity of managing multiple services

The key is being honest about whether your addressing real problems or just following tech trends. Most side projects are built for dozens or hundreds of users, not millions, and our architecture choices should reflect that reality.

The Progressive Migration Strategy

My approach isn't completely without planning though. My current strategy involves:

1. Writing modular code where possible (without sacrificing progress)
2. Following clean architecture principals where it makes sense
3. Keeping components loosly coupled to avoid creating a maintainance nightmare
4. Keeping potential future decomposition in mind as I develop
5. Noticing which parts of the system naturally want to be seperate

Nothing fancy or over-engineered, but it keeps development moving forward without creating to many technical constraints for the future.

It's Not Technical Debt – It's Strategic Simplicity

This isn't about being lazy or taking shortcuts. It's about being realistic and making pragmatic choices that maintain momentum.

Real technical debt isn't choosing a monolithic approach – it's writing poorly structured code, avoiding tests for critical functions, or having insufficient documentation. A well-designed monolith can be much easier to maintain than a collection of microservices that were implemented hastily because they seemed more sophisticated.

Lessons from the Trenches: What I've Learned Along the Way

After working on MockFast for about a year (with plenty of breaks and distractions), I've learned some valuable lessons:

• Unexpected Evolution: The features users value most weren't the ones on my initial roadmap.
• Quick Feedback Loops Matter: Being able to implement changes quickly meant I could respond to user feedback rapidly, which made a huge difference.
• Motivation Needs Reinforcement: It's much easier to stay motivated when you're shipping actual features rather than spending weeks on invisible infrastructure work.
• Finding Balance is Hard: Navigating the space between "good enough" and "perfect" is a constant challenge, but leaning toward "functional now" has generally been the right choice.

Conclusion: Enjoy the Journey

When it comes to side projects, the best architecture isn't necessarily the most sophisticated or trendy - it's the one that enables you to:

• Build something meaningful without overwhelming yourself
• Learn valuable new skills along the way
• Solve actual problems that bother you or others
• Find enjoyment in the process rather than creating another source of stress

For MockFast, that means maintaining simplicity, staying adaptable, and avoiding the trap of over-engineering that has killed so many promising side projects.

Key Takeaways:

• Side projects succeed when you keep them managably simple
• Monoliths are often the smart strategic choice for individual developers
• Your architecture should support your project goals, not impress other developers
• If the project stops being enjoyable, re-evaluate your approach
• The best architecture is whatever helps you complete your project and get it to users

Remember: The goal is to build something useful that actually makes it to production, not to create the most technically impressive system that forever remains a work in progress.